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

[David Simms]

"ValueBasedClassFinder.java" Nice Remi, will play with this next week


On 24/01/2018 7:45 p.m., Remi Forax wrote:
>
> 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