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 [message reformatted]


On Monday, October 20, Jeff Sturm wrote:

> On Sun, 19 Oct 2003, Patrik Reali wrote:
> > As an obvious constraint, compilers and interpreters without support for
> > structs should be able to compile them as classes and obtain exactly the
> > same results.
>
> Hmm... why is this obvious?  Extending Java bytecodes would indeed be
> problematic, but language extensions less so since all you'd need is a
> bytecode compiler supporting value types.

I think no additional bytecodes are needed to support value types. Such
types should be marked with some additional attributes in the classfile.
Legacy compilers would ignore the "unknown" (to them) attribute and compile
those types as classes. Compilers supporting this feature would instead know
(from the metadata) that these are value types and should be handled
differently.


>
> > 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.
>
> Or you could define new semantics.

This is needed. But I would favor an approach which would be compatible with
the existing JVMs. A good solution (I'm not sure whether one exists) should
generate bytecode that runs on legacy VMs.

>
> You can take the following with a grain of salt, since I haven't thought
> it through as much as you or Per, but here's what I'd like to see from
> value types:
>
> 1) The address of a value object is never taken (as with Java primitives).
> 2) No runtime type information for value types.
> 3) No virtual dispatch--if instance methods are allowed they must be
> final.
> 4) A value object cannot be cast to/from another type.
>
> The rationale for 2) and 3) is to eliminate the header word of value
> instances.  Many architectures permit passing small struct arguments in
> registers, but these are often limited to 2 words.  If one of those words
> must be a class or vtable pointer, the optimization is far less useful.

I not sure whether designing a language with some specific compiler
optimizations for a specific processor and calling convention in mind is a
good thing.

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.

>
> 1) mandates pass-by-value and guarantees safety of stack allocation.
> (Actually even stack allocation may be overkill; many small instances
> could be allocated in registers for their entire lifetime.)
>

Yes, using a pass-by-reference strategy as I proposed would force to push
the structs on the stack to be able to take their address. On the other
hand, it would be coherent with the actual Java semantic and be compatible
with legacy VMs.

A problem you encounter with pass-by-value and the copy-on-assignment
semantic is whether to perform a shallow or a deep copy (I guess the answer
would be "shallow", but this has to be decided).


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