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: values types for Java


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.


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