This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: values types for Java [message reformatted]
- From: "Patrik Reali" <reali at acm dot org>
- To: "Jeff Sturm" <jsturm at one-point dot com>
- Cc: <java at gcc dot gnu dot org>, <per at bothner dot com>
- Date: Wed, 22 Oct 2003 21:15:59 +0200
- Subject: Re: values types for Java [message reformatted]
- References: <Pine.LNX.4.44.0310211521520.30891-100000@ops2.one-point.com>
Jeff Sturm wrote:
> > Such types should be marked with some additional attributes in the
> > classfile.
>
> Perhaps. For gcj's purposes it may be sufficient to generate compatible
> bytecode, and leverage struct optimizations when compiling from source.
>
> A simple example:
>
> struct S {
> int a,b;
> }
>
> class C {
> int x,y;
> S s;
> }
>
> might produce bytecode equivalent to:
>
> class C {
> int x,y,s$a,s$b;
> }
>
> I can imagine something similar for method parameters. Struct return
> values are a little trickier; they could be wrapped in some other object
> perhaps.
>
Maybe you could pass each struct field as out parameters (in practice as
reference parameter) automagically added by the compiler. Thus:
S M(T x) { .... return s;...}
would be compiled as
void M(T x, int* s$a, int* s$b) { ... s$a = s.a; s$b = s.b; return;....}
(I'm not sure whether this is possible in gcj, but I would try a solution
along these lines)
>
> > Anyway, this restriction would be formulated in the language report as
> > "value types are final subclasses of Object". This restriction is often
> > mentioned and could make sense (Per proposed it). This would
automatically
> > remove the need for virtual dispatch.
>
> But even Object has a vtable. I feel making value types a subclass of
> Object undermines the value of this proposal, having simple, lightweight
> stack-allocated structs.
>
> You could disallow these types from having Object semantics, but that
> seems awkward to me.
This is why (in both proposals) structs cannot be casted to Object.
-Patrik