[Exp] Experimenting with "value-based" classes and oop testing
john.r.rose at oracle.com
Fri Jan 19 22:00:36 UTC 2018
+100 to this experiment; as a whole it's the right thing to try.
It might give us the fast acmp hack we need for L-world.
A couple of comments:
> On Jan 19, 2018, at 12:25 AM, David Simms <david.simms at oracle.com> wrote:
>> my other question is what is the purpose to have a value based class with mutable fields ?
> Hehe, yeah ValueBased test itself doesn't follow the rules, will adjust.
> Also thinking of adding some form of auto-value classification to class file parser, identify value type candidates in existing benchmarks, so we can see L-World costs
Another way to slice it would be to have a classfile scanner which
spits out the names of value-able candidate classes. That could
be eyeballed and then plugged into -XX:ValueBasedClasses=…
I'll bet it could be hacked up in an afternoon in ASM. Remi…
About mutable immutables, there is actually something worth
saying: We sometimes think about designing a _larval typestate_
for immutables (of both object and value types) which would
be mutable. It would be a private container for field values.
Once it is loaded, it get promoted to the publishable _adult
typestate_. See . We would need to figure out rules for
keeping the typestates separate, so that larval objects
are not accidentally published (leading to races) and
so that adult objects are not accidentally mutated as if
they were still under construction.
That last requirement is best solved, I claim, by
introducing a mechanism for single-thread confinement,
enforced by the JVM.
These ideas are worth mulling over from time to time,
as a better way to organize immutables than the standard
technique of manually written builder objects like
StringBuilder (and various collection builders).
Anyway, if a value type has a larval object state, its
fields *would* be writable, but in that state *only*.
Of course, as it pupates to the adult state it would
shed its object identity as well as its mutability.
If it were a true object class it would shed only
its mutability. It might *change* its identity, as
in the case of StringBuilder.toString. Note that
a StringBuilder *does* change identity when
promoting to the "adult" String.
Maybe we can do something about typestate
with template classes—if a template could expand
to both objects and value species!
More information about the valhalla-dev