values types for Java

Tue Oct 21 07:04:00 GMT 2003

On Oct 21, 2003, at 1:20 PM, Adam Megacz wrote:
> Andrew Haley <aph@redhat.com> writes:
>> J.-D. Choi, M. Gupta, M. Serrano, V. C. Sreedhar, and S. Midki.
>> Escape analysis for Java. In Object-Oriented Programming, Systems,
>> Languages, and Applications (OOPSLA), 1999. Languages (POPL), 2002.
>> http://www.research.ibm.com/jalapeno/publication.html#oopsla99_escape
>>> I would like to add this to gcj.
>> Two problems for use with GCJ:
>> 1. They use interprocedural analysis, which is not compatible with
> separate compilation.

Not true at all. In fact the techniques in this paper were developed 
and implemented in the context of a static compiler, much like GCJ. It 
is true however that complete thread-level escape analysis requires 
whole-program optimization, so the presence of dynamic linking & 
loading restricts the optimizations that are able to be made - ie you 
can't assume that an object doesnt escape foo.bar if foo.bar is in 
another shared library (like libgcj.so) since the implementation in 
that library could change. Also, in many cases you can't assume that a 
reference doesn't escape a virtual method if a class in another binary 
could override that method. As pointed out in the paper, the presence 
of dynamic loading in java complicates escape analysis greatly, so if 
anything it is easier to do in a static compiler (at least for static, 
whole program compilations) than in a JVM.
> 2. This is overly conservative compared to Per's suggestion (I'm not
> sure if you're proposing it as a replacement for stack allocation
> or just an intermediate step).

Personally I would be in favour of an extension to Java - something 
along the lines of C# structs - which a VM/compiler implementation 
could easily choose to stack-allocate. I like Per's idea of all struct 
fields being final since, aside from the fact that it simplifies 
implementation, it makes a clear distinction from the programmer's 
perspective as to when its appropriate to use a struct as opposed to a 
class. However I'm not keen on the idea of implementing this as a GCJ 
extension with some kind of hacked-up syntax. The benefits of something 
only supported by GCJ would be limited and the syntax would not make 
them elegant to use. As Per suggested, the way forward would be to 
propose this as a JSR and take it from there.
Regards
Bryce.