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

Rezaei, Mohammad A. Mohammad.Rezaei at gs.com
Wed Dec 2 03:11:43 UTC 2015


That makes sense (and it's consistent with my layman's interpretation that List<T> as a value-based is weird). In this particular case, I believe Stuart does want to make explicit claims for immutability and serializability.

In the case of the empty methods, I don't see why a strong claim about identity can't be made. The same claim exists today in Collections.empty*. As a user of the API, the more clarity/guarantees I can get, the better I feel about using the method. If I know a method is garbage-free, for example, I will use it, but if I don't have that guarantee, I might as well do my own "static final List EMPTY = ...".

Thanks
Moh

>-----Original Message-----
>From: Brian Goetz [mailto:brian.goetz at oracle.com]
>Sent: Tuesday, December 01, 2015 10:03 PM
>To: Stuart Marks; Rezaei, Mohammad A. [Tech]
>Cc: 'core-libs-dev'
>Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-
>8139232)
>
>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



More information about the core-libs-dev mailing list