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

[Stuart Marks]

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