values types for Java [message reformatted]
Mon Oct 20 01:56:00 GMT 2003
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.
> 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.
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
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
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.
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.)
Instance methods could be inlined by the compiler, even when compiling to
bytecode, so they can examine and modify member variables while avoiding
referencing the address of the value object directly.
More information about the Java