RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Brian Goetz]

Value-based is a property of types, not of instances.

For disclaimers regarding the result of factory methods, it seems 
clearer to go to the traditional "make no assumptions about the type, 
mutability, serializability, or identity..." sort of language.



On 11/25/2015 7:37 PM, Stuart Marks wrote:
> I think the main point of including the "value-based" admonition is to 
> warn developers not to depend on identity semantics of these things. 
> This should help preserve flexibility when/if we decide to convert 
> them to value types in the future. It might be that there's no 
> advantage in doing so, in which case we presumably won't do it. :-)
>
> I'm somewhat distant from the current state of the value types work, 
> but I can imagine that it would provide some advantage even for the 
> empty List. Clearly the overall heap savings wouldn't be large, since 
> as you point out, there's only ever a single instance. But if it were 
> a value type, it could live entirely on the stack, avoiding a memory 
> dereference, a cache miss, etc.
>
> s'marks
>
> On 11/24/15 7:52 PM, Rezaei, Mohammad A. wrote:
>> Value based things make a lot of sense for types that don't belong to 
>> well established reference hierarchies. I can even see great uses for 
>> a value based List implementation, so long as it's preferentially 
>> referenced as the exact type (e.g. private ValueBasedList someList = 
>> ...) and rarely cast to the interface type (List).
>>
>> But I've been scratching my head about the empty collections (of()) 
>> and I can't figure out why value based would be a good idea. 
>> Currently, there is only one instance in the entire VM, so it's 
>> unlikely to get any memory benefits. The most likely use for the 
>> return value is either a variable/member of type List or something 
>> that can hold a List (like a Map<K, List>), which will likely cause 
>> an immediate boxing. In some cases this can be elided (lots of 
>> inlining and optimization), but that's the less likely case.
>>
>> What's the rationale for the value based spec for the empty 
>> implementations?
>>
>> Thanks
>> Moh
>>
>>> -----Original Message-----
>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] 
>>> On Behalf
>>> Of John Rose
>>> Sent: Tuesday, November 24, 2015 9:08 PM
>>> To: Stuart Marks
>>> Cc: core-libs-dev
>>> Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation 
>>> (JDK-
>>> 8139232)
>>>
>>> On Nov 23, 2015, at 10:26 PM, Stuart Marks <stuart.marks at oracle.com> 
>>> wrote:
>>>>
>>>> Please review these API and implementation changes that comprise 
>>>> the first
>>> integration of JEP 269. I intend to push this under the "initial API 
>>> and
>>> skeleton implementation" subtask, JDK-8139232.
>>>
>>> Please strengthen the specification to assert that the new 
>>> immutables are in
>>> fact value-based.
>>>
>>> http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html 
>>>
>>> <http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html> 
>>>
>>>
>>> This will prevent people from relying on their identity (acmp) and
>>> synchronization (monitorenter).
>>> It will allow optimizations more freedom to use flatter storage 
>>> formats and to
>>> reuse list values.
>>>
>>> If we don't do this now, then we will not be able to retroactively 
>>> make or
>>> enforce the claim,
>>> and the optimizations will be impossible.
>>>
>>> — John