This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: values types for Java
- From: Andrew Haley <aph at redhat dot com>
- To: "Patrik Reali" <reali at acm dot org>
- Cc: <java at gcc dot gnu dot org>, <per at bothner dot com>
- Date: Mon, 20 Oct 2003 16:01:49 +0100
- Subject: Re: values types for Java
- References: <001301c3963f$21ff9590$0301a8c0@pcprr>
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.