values types for Java

Patrik Reali reali@acm.org
Mon Oct 20 14:43:00 GMT 2003


[ Reformatted by aph as a public service ]

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.

Rule 1: the programmer can mark a class as "struct", the compiler will
optimize those classes for efficient allocation.  Marking can be done as
you proposed using a special field.  First, the structs are not allowed
to "escape", i.e. referencesto a struct should be shorter-lived than
the struct itself.Method calls are fine, but assignements can cause a
reference tobe set outside the current call-stack, thus:

Rule 2: structs cannot be assigned with "=" This is an important step:
assignment can have two semantic: setting a reference or copy the
whole struct.  Both are unacceptable: setting a reference allows the
struct to escape,whereas cloning is against the usual Java rules.
Note that this rule implicitly prevents from returning astruct from a
function (the reference cannot be assigned).  Structs can still be
passed as parameters, like classes are, using the usual reference
semantic.  

Exception to rule 2: it is allowed to invoke a constructor
(Point p = new Point(....)); but the static type and the dynamic type
must be the same.

Rule 3: structs cannot be coerced to a non-struct type (inparticular
Object)  This rule avoids using Object as a way to circumvent the rule
2.There is no need to restrict inheritance nor
methods.   Legacy compilers will implement struct as classes; newer
compilers are aware of them and can pass a vtable along with the struct
reference when they are passed as parameters.

There is one problem raising with "==" and "!=". I think they should
be disallowed, because the correct behaviour would be tocompare the
contents (field by field), but this would cause legacy compilers to
generate more restrictive tests (referencecomparison) compared to the
newer compilers (field tests).  Another problem is that the compared
structs may be of different type (unless struct cannot be
subclassed).

There may be some limitations due to the garbage collector (GC), in
particular with structs embedded into a class.  A GC must be quite
clever or conservative to decide that a pointer on the stack pointing
to the middle of an heap-object must keep theobject alive. (I guess
this may be more difficult in a type-aware GC than in a conservative
one).  I think this proposal is simpler than yours, and at the same
time compatible to the Java semantic.  Your example with "Point" would
fit into the above rules but for the returning of a struct in a
function; furthermore, Point wouldn't be forced to be static nor its
fields final.  This proposal is still not complete: the default values
are not specified, and I'm sure that more is missing (I wanted to
quickly post an answer to your message).

Many thanks for raising the issue!

Patrik-----------Patrik
Realihttp://www.reali.ch/~patrik/http://www.oberon.ethz.ch/jaos/
Patrik
Realihttp://www.reali.ch/~patrik/http://www.oberon.ethz.ch/jaos/



More information about the Java mailing list