This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: need to focus on java performance?


David Daney wrote:
I imagine that most of the stack traces are needed for security checks, and not exceptions.

Most applications (excluding applets) do not use security managers, and thus do not perform many security checks (there's also some runtime access checking that occurs as part of reflection). Beyond EH/stack traces, most of the stack inspection that occurs in regular applications is actually to determine the calling class to maintain classloader semantics when loading classes and resources. Andrew recently made an improvement here that should reduce these checks significantly: the compiler now passes the calling class directly to certain common functions that need it.
If stack traces are really done so much, would it make any sense to compile all code with a frame pointer, and walking those instead of using the DWARF unwinder? In the recent past that was done on many archetectures. Perhaps changing it was a mistake.

That is certainly something to consider. Currently the DWARF data is the only way to properly map an IP address to a function, however if the compiler also produced a length-of-function field as part of the metadata, we could maintain our own data structure for this mapping and avoid the need to call into the unwinder to determine the function start address.


Whether this would be worth it, compared to the loss of code optimization from losing a register to the stack pointer, is unclear. I suspect it varies a lot by application, and platform.

Bryce


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]