[Exp] Experimenting with "value-based" classes and oop testing

[Remi Forax]

On January 19, 2018 10:00:36 PM UTC, John Rose <john.r.rose at oracle.com> wrote:
>+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 ?
>>> 
>>> Rémi
>> 
>> 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… 

https://gist.github.com/forax/38935d18aaedc08a32610a7cbc68885e

I use an internal version of ASM 7, but it should work with the internal version of the ask by replacing ASM7 by ASM6 in the source code.

I just check if the class is final, the super class is Object and all fields are final, is it enough ?

>
>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 [1].  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!
>
>— John

Remi

>
>[1] https://blogs.oracle.com/jrose/larval-objects-in-the-vm

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.