RFR(M): 8190430 [MVT] Fixing GC support for Thread-local value buffers

[bdelsart work]

Hi Fred,

Just a side comment on the publishing, which might be more of interest for
the GC team.


> [ I also had some doubts  about the need in vwithfield to systematically
>> copy in the heap a vtBuffer allocated value 'voop' when stored in a non
>> flattened field in a 'new_value' since voop is always older than new_value.
>> However, this is really a design choice. Allowing a non flattened field to
>> point to an older value in a vtBuffer would require to be more careful for
>> instance when walking the value or copying it on frame return and may not
>> be worth the added complexity (particularly for the copy on frame return).
>> Hence, the proposed design where a non flattened field always points
>> towards the heap may indeed be better ]
>>
>
> The problem is that writing a value to a field is equivalent to
> publishing it, it is not thread-local anymore because any thread
> can access it. We want to keep the management of the TLVB local
> to its thread, so to prevent threads to refer to values buffered
> in other threads' TLVBs, we have to make this copy then writing
> to a field or an array.
>
> Best regards,
>
> Fred
>

By systematically, I meant that it is not required when the new_value is
also in a TLVB. In that case, this is not a publish. This is why I reacted
to the second 'must' in this comment in interpreterRuntime.cpp:

 280         // new value field is currently allocated in a TLVB, a
heap allocated 281         // copy must be created because a field
must never point to a TLVB allocated value


With the current proposal, heap allocations are needed as soon as we have
values embedding non-flattened values, even if none of these values escapes
from the creating thread. Now, as stated above, this is really a design
choice. Going further, this is very likely the right default choice in the
short term for Valhalla.

FYI, there are recurrent discussions in various JVM teams around the use of
Thread Local GCs. The balance between the allocation/recycling gains and
the cost of the barriers is hard to find (there are different approaches
depending on how complex are the operations supported before an object is
moved to the Heap). TLVB is a special case, limiting the scope to Values.
This lowers the cost of the barriers but also the gains. In fact, TLVB is
already a very good step towards TLGC goals... in the flattened case. Your
eager Heap allocation only concerns non-flattened values, which are not
critical to the success of Valhalla. Now, preventing this Heap escape might
be another path worth exploring later for the GC experts who were
interested in Thread Local GCs. Non flattened values could be a way to
create temporary read-only big data structures that would remain thread
local in some JVMs. In the short term, as stated above, it is clearly not
worth the added complexity.

Hence, back to your comment, it 'must' be so only because of your (right)
design choice. Something like "a heap allocated copy must be created
because non-flattened value fields are considered as escape points" might
be truer but this is a minor detail. Feel free to ignore it.

Regards,

Bertrand.
--
Freelance - Bertrand Delsart Software Solutions
Remote Research, Development and Troubleshooting
JVM, Real-Time and Concurrency expert
http://www.bdelsart.com