Skip to main content

performance: escape analysis

5 replies [Last post]
jtr
Offline
Joined: 2003-06-10

If C++ objects are allocated on the stack, C++ still beats Java's current garbage collection. Java new-ed objects (even those only used within a single method) are allocated in the heap, which will obviously be slower to free than poping a stack frame. Granted, with generational GC, that's much better than it used to be, but some simple escape analysis could go a long way to giving Java parity here.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
spiff
Offline
Joined: 2003-06-10

Could escape analysis be used to alleviate the small object memory problem that HotSpot currently has? Currently, the 8-byte per-object plus 8-byte padding can double the amount of memory used by a small object (e.g. an object with just 3 int fields uses 24 bytes under HotSpot, 12 bytes in C). Could you embed those fields within their grandparent object or stack frame once it is discovered that a reference to the parent object never escapes?

opinali
Offline
Joined: 2003-06-17

I wouldn't make any difference in footprint, because escape analysis replaces heap allocation only for short-lived local variables, not for long-lived objects that are kept in the heap by root references.

Java's headers arw two words in size mostly due to the ubiquitous monitors. Some bits from the second word are used for GC flags too, but if we could get rid of the monitors, these bits could be moved to the first word (the class pointer) with a small cost of forcing the JVM to mask out a few bits when reading the class pointer.

The problem is that java.lang.Object's spec demands that all Java objects have monitors, but there are some alternatives:

1) Dropping the monitor word from the header anyway, because this is only required as an optimization. The JVM could still locate the monitor by lookups in global and/or thread-local hashtables indexed by the object's address.

This solution has a high cost in performance, but it may be possible in the future after everybody moves to java.util.concurrent's Lock objects for any perf-critical code :) But I think this is a very distant future, because monitors are too easy to use, they'll always be popular.

2) Use advanced techniques to use single-word headers without significant performance drops.

See this research paper: http://citeseer.ist.psu.edu/bacon02space.html but I don't know of any production JVM to use this yet (looks good remarkably for J2ME).

3) Invent some new trick in the language or type system. For example, annotations could do the trick:

@Lightweight public class Point { int x; int y; }

The JVM would use a single-word headers for classes marked as "lightweight" -- you could still use monitors on these classes, because they're still inheriting java.lang.Object and must obey its contracts; but for these classes, the JVM would use less efficient, hashtable lookups like in (1)... but of course programmers would avoid using the monitors from "lightweight" classes. That's a great trick because it can even be applied to existing APIs, as it doesn't alter any semantics, only performance.

This proposal is also similar to one of the tricks in (2) except that the programmer manually chooses classes that can use single-word headers. And it could also be part of a more ambitious spec for lightweight objects / value objects, including other annotations to specify memory packing and alignment, by-value containment of fields etc. so we could save much more memory.

kbr
Offline
Joined: 2003-06-16

Generational scavenging combined with thread-local object allocation (both present in HotSpot) appears to yield many of the advantages of stack allocation of objects, at least from a conceptual standpoint. However, there are definitely code quality improvements that can be had from performing escape analysis, including register allocating objects' contents and performing lock elision and coalescing. These areas are under active investigation in HotSpot for Mustang.

mthornton
Offline
Joined: 2003-06-10

Estimating the performance gains of escape analysis by testing existing code seems problematic. The code will have been written knowing that JVM's don't currently do escape analysis. So by implementing escape analysis, the end result may be better structured programs that run only slightly faster. This would still be a big gain for Java.

opinali
Offline
Joined: 2003-06-17

This estimation is possible because there are some Java implementations that do this -- for example, the JET static compiler definitely does it (see its compilation logs), and I think IBM JDK does it too. We only need some carefully writen benchmarks (code that allows, and benefits, from automatic escape analysis) to check whether such enhancements are worth the trouble.