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


Patrik Reali writes:
 > 
 > Hi,I completely agree with you on the need for structs in Java,having the
 > programmer specifying them allows to have theirbenefits without having to
 > pay for expensive compiler optimizations.I will gently disagree with your
 > proposal. 
 > 
 > Structures usually are characterized by stack-allocation (or embedding
 > intoother data types) and cloning on copy-operations. You set the
 > accent on the cloning, whereas I think that stack-allocationis the
 > most important point.  As an obvious constraint, compilers and
 > interpreters without support for structs should be able to compile
 > them as classe sand obtain exactly the same results.
 > 
 > My (rather pragmatic) approach is as follows: I want to mark some
 > classes as potential structs (allowing the compiler to allocate them
 > on the stack or inline them into other types),and I rule out all the
 > operations on struct that would break the Java semantic.  The compiler
 > could then check that no semantic-breaking operation is taken; this
 > would also ensure that compilers without support for static allocation
 > would still generate working code.

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

I would like to add this to gcj.

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.

Andrew.



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