[foreign-memaccess] on confinement

[Maurizio Cimadamore]

Hi Andrew,
the essence of what we are exploring is very similar to what you 
proposed; on segment closure, the following things should happen:

* segment should be marked as closed
* GC safepoint should be initiated
* after the safepoint terminates correctly, go ahead and cleanup the 
segment's memory

Instead of using a full stop the world handshake, we are experimenting 
with the new thread-local handshakes (which stop one thread at a time), 
courtesy of JEP 312 (Thanks Erik O. !).

There are two main issues in getting there:

1) the approach relies on the fact that you can prove that there is no 
intervening safepoint between the liveness check and the memory access; 
(that is, the thread will be stopped either before memory access, or after)
2) C2 should play nice with respect to memory state and safepoints (e.g. 
a load should not be carried over a safepoint)

Now, addressing (1) is very problematic. Either we have a way to 
completely disable safepoints in certain region (seems risky?) or we 
have a way to add new Unsafe memory access routine which perform an 
atomic check + access. We started experimenting with the latter 
approach; while it seems doable it is also a very large undertaking.

As an interim measure, to address (1), I recently come up with an 
approximation which will allow us to play more with this; the idea is to 
leverage the handshake support in JEP 312, which allows a closure to be 
executed for each blocked thread. We could, in this closure check as to 
whether the thread is in some well-known critical region (e.g. memory 
access var handle code, or some other code annotated accordingly, or 
maybe there's an unsafe method to enter/leave a critical region). If, 
during the handshake, we see that one or more threads are in one of the 
critical regions, we just try again, until we succeed. This approach if 
of course an approximation, but is very general, and doesn't require 
complex surgery on Unsafe.

Solving (2) is, however, a prerequisite - we have already seen cases 
where playing with handshakes and shared segments leads to crashes, due 
to values being cached across safepoints. To avoid the crashes the only 
solution, at the time being, is to make the liveness check stricter, so 
as to use the opaque access mode - which then kills performances (e.g. 
hot loops are 12x slower, not too dissimilar to just using volatiles and 
CAS).

We'll keep playing in this area, I'll share a patch or something once we 
manage to get something working :-)

Cheers
Maurizio

On 30/07/2020 13:13, Andrew Haley wrote:
> On 01/07/2020 19:13, Maurizio Cimadamore wrote:
>> We're currently keeping open both the thread-local GC handshake (a
>> variation on an idea you had at some point in the past)
> Can you share any thoughts you may have had about this? I'm very curious,
> as I'm sure you'd expect.
>