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


Andrew Haley writes:
> Patrik Reali writes:
>  >
>  >  [proposal http://gcc.gnu.org/ml/java/2003-10/msg00169.html]
>
> I don't see the point of this.
>
> If we can show at compile time that an object does not escape the
> context (either a method or a thread) where it was created, we can
> automagically stack assign that object.  Escape analysis for Java is
> quite well understood;
>
> 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
>


This is true, but works only for static compilers. As soon as classes jitted
or dynamically loaded, this gets more difficult to achieve. The paper
doesn't mention the cost of the algorithm, but often escape analysis is
expensive and thus not appropriate for jitters.


>
> In any case, I'm not sure that stack allocation of large structs is a
> good idea.  We sometimes have fairly small stacks when using thread
> libraries.
>

This is one reason why should structs compiled as classes should have the
same semantic. The compiler may know the available stack size and choose to
allocate them on the heap.

-Patrik

--------
Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos


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