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-boun...@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.ma...@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
