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

[Frederic Parain]

Bertrand,

You’re right, this us a design choice to always non-flattened values in the heap.
This choice has been made considering two aspects:
  1 - allowing buffered values to reference other buffered values would have
    re-introduce the issue faced by TLGC you described (cost of barriers and
    copies when a value escapes)
  2 - it would have made the recycling of the TLVB more complex and, more
    critical, it would have made the root processing more costly.

The second point might be the most important. All references from the TLVB
to the Java heap must be processed as roots. With the increasing importance
of concurrent GCs, our colleagues from the GC team have become more and
more concerned about the root processing time, because it still represent a
pause time for the mutators. The current design of the TLVB tries to keep the
root processing as linear as possible (proportional to the number of local
variables and the size of the expression stack). Allowing intra-TLVB references
would require to introduce recursivity in the TLVB root processing, which could
lead to significant impacts on the GC pause times.

The bottom line is that intra-TLVB references could be supported, but the
complexity cost to support them would be significant, and the impact on the
GCs could be very negative. As you stated, intra-TLVB references are a corner
case, so as of today, we have no plan to allow them.

If in the future, it appears that if we could get some significant gains by supporting
them, we would revisit this decision.

I’ll try to update the comment, making the design choice more explicit, on my
next push.

Thank you,

Fred


> On Nov 29, 2017, at 03:57, bdelsart work <bdelsart.work at gmail.com> wrote:
> 
> 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 
>