Re: values types for Java [message reformatted]

["Patrik Reali" <reali at acm dot org>]

[message resent to correct the bad formatting]

Hi.

I completely agree with you on the need for structs in Java, having the
programmer specifying them allows to have their benefits without having to
pay for expensive compiler optimizations. I will gently disagree with your
proposal. Structures usually are characterized by stack-allocation (or
embedding into other 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 classes and 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 to be 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 to compare the contents
(field by field), but this would cause legacy compilers to generate more
restrictive tests (reference comparison) 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 the object 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 quicklypost an answer to your
message).

Many thanks for raising the issue!

Patrik

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