RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)
stuart.marks at oracle.com
Thu Nov 26 00:37:28 UTC 2015
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.
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?
>> -----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-
>> 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.
>> 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