[lworld] RFR: object methods in VM for lworld value type

[John Rose]

On May 9, 2018, at 3:41 AM, David Simms <david.simms at oracle.com> wrote:
> ...
>> 
>> Did you try to put an "already locked" pattern in the header?  That will
>> push many tests related to synchronization down onto the slow path.
>> 
> 
> I did play with already locked, but did not like it much. That was before we decided hashCode could be an BSM story, I thought we might need mark word for caching hash, not so anymore. However, having a sentinel fat monitor or biased to fake thread coupled with seems like it might collide with "buffered oops" if we need mark word for state there...although we need to rework buffering somewhat, last time we need the whole word for buffer relocation (forget if this was actually visible)...perhaps "fat locked" or "bias locked" together with monitor/thread reference high bit is compatible.

To be clear, I really like the klass address bit hack!  I'm just wondering if
we can do the special funny mark in addition.

The funny mark word would only be in heap buffers, not thread-local buffers.
TLBs would still be free to use it for their own purposes.

I have two purposes for hacking the mark word:
1. Make it clear to clients of the mark word (sync, OIHC) not to touch it.
2. Later on, maybe use the same mark for special frozen/value arrays.

The value of #1 is marginal:  It means there are fewer places in the code
where you check the klass word for the value bit.  But I think it does have
some benefit, since all the fast paths that check the mark word are hard
to find (and vary over time!).  Better to have a neutral-mark-word-for-values
which all the fast paths know about and agree to skip (as a side effect of
other checks already being made); then we handle the value check
on the slow path.

> I digress, the real thing that got me to avoid this, was GC "should preserve mark word" leading to mark word stack usage (GC needs the mark for it's own evil purposes, and needs preserve the value for anything "special", which I suspect is uncommon case)...I was concerned what extra work this would be, both for implementation and runtime performance.

As you pointed out when we just talked, the GC might need to be in on
the trick, since it doesn't want to store all of those funny marks in a side
table like it does for truly locked (or OIHC-ed) objects.  That takes time
and space.  But if the GC can look at the klass pointer, check the value
bit, and put in a neutral-mark-word-for-values state, then all is well.

> But I guess I could revisit, since the monitorenter number of comparison ops can be reduced.

Yep.  If there is a standard neutral-mark-word-for-values bit pattern,
then all the various mark-sniffers can be tuned up to watch for it
and go slow path.  Without extra checks, naturally.
>> …
>> # klass.cpp
>> 
>> Yeah!
>> 
> 
> I've forgotten something, probably array klasses, and AppCDS probably can't be completely ignored, like we had been.

Probably.  But it still feels worth it.  Putting the check only in the
mark word means it's on the same cache line as the object header,
but it's still a separate load.  And most codes which will want to
check value-ness will also want to see the klass word, at about
the same time. This saves a load.

> ...
> I removed a dead code path, then "FastHashCode" is what remained, it could be renamed, perhaps in main-line (not a Valhalla specific).

Yes.  I'm just kvetching about somebody's choice of names.

>> P.S. Is there a path to make frozen arrays be just plain arrays,
>> but somehow also values?  And also other kinds of instances.
>> This is doable if we lean heavily on the mark word to tell us
>> when identity and mutability are disabled.  Doesn't work as
>> well if we put all the burden on the klass field, unless we split
>> array classes internally into array-value and array-object.
>> 
>> 
> 
> Yes, a frozen array could be an "array-value", VM implementation would be pretty trival, use the same mechanism for aastore / klass encoding / "already locked".

Yep.  This is my sneaky plan for making arrays safer.  Making them
(some of them!) into true value types seems almost within reach, and
worth thinking more about.

— John