Alternatives to Value Types?

[Maurizio Cimadamore]

Hi,
note that locality of fields is just one of the many problems. A perhaps 
bigger one is how instances of V (where V is a value class) are laid out 
in an array, as that tremendously affects performances; if every cell of 
the array is merely a pointer to some other heap location (where the 
instance is actually stored), then locality is thrown out of the window. 
The idea behind current proposal is that, as instances of value classes 
are kind of ephemeral, they can be 'inlined' directly inside the array - 
which means no long jump to reach the array elements. If I understand 
your proposal correctly, being @Value a property of the field rather 
than one of the class, means that it won't be possible i.e. to store 
instances of 'Foo' as mere blobs of bytes inside an array. Of course, if 
you put in place the right set of restriction, you might be able to get 
there - but it seems to be that those restrictions (most notably, the 
fact that 'Foo' must be monomorphic) apply more to the concept of class 
than that of the field.

Maurizio

On 07/01/15 06:42, Krystal Mok wrote:
> Hi Ming-Yee,
>
> The idea of annotation on a field for "embedding objects" or "colocating
> objects" has cropped up once in a while.
>
> A similar idea goes like:
>
> class Foo {
>    @Value private AtomicLong val = new AtomicLong(0); // "embed" the
> AtomicLong in Foo
> }
>
> Anyway, I'd like to point out that the ObjectLayout [1] project actually
> takes care of a concept similar to yours, but retains full object semantics.
>
> - Kris
>
> [1]: http://objectlayout.org/
>
> On Tue, Jan 6, 2015 at 8:35 PM, Ming-Yee Iu <valhalla at jinq.org> wrote:
>
>> Stephen Colbourne might have a point about these value types. Are there
>> alternatives to value types that give fewer benefits but don't require such
>> large Java changes?
>>
>> I'm sure you've considered it before and dismissed it, but maybe instead of
>> value types, we could have value "fields"? I have no idea what I'm saying,
>> but maybe instead of "No Identity" being an annotation on types, "No
>> Identity" could be an annotation added to fields?
>>
>> class NoIdentityContainer<T> {
>>    @NoIdentity_CopyByValue_HaveGoodLocality T field;
>> }
>>
>> Creating an instance of the class will also create an instance of the T
>> object with locality near to the container instance. Assigning to the field
>> will actually result in a copy of the contents over the existing instance
>> instead of just changing the pointer. Maybe the annotation could be applied
>> to method parameters and return values as well. Objects stay as objects.
>> Primitives stay as primitives. The only classes that have to deal with new
>> "value" semantics are those classes that explicitly use the annotation.
>> Things still break, but in a different way that might be more palatable.
>>