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] | |
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] |