segments and confinement

Andrew Haley aph at redhat.com
Fri Jul 3 10:35:48 UTC 2020


On 13/05/2020 12:51, Maurizio Cimadamore wrote:
> *Other (experimental) solutions*
>
> Other approaches we're considering are a variation of a scheme proposed
> originally by Andrew Haley [2] which uses GC safepoints as a way to
> prove that no thread is accessing memory when the close operation
> happens. What we are investigating is as to whether the cost of this
> solution (which would requite a stop-the-world pause) can be ameliorated
> by using thread-local GC handshakes ([3]). If this could be pulled off,
> that would of course provide the most natural extension for the memory
> access API in the multi-threaded case: safety and efficiency would be
> preserved, and a small price would be paid in terms of the performances
> of the close() operation (which is something we can live with).

I don't think that the cost of the safepoint is so very important.

Firstly, as you note, all we need to do is null the (unique) pointer
to the segment and then briefly safepoint all of the mutator threads
in turn: the safepoint doesn't have to do anything, we just need to
make sure that every thread has reached one. With an efficient
safepoint mechanism this could be a very low-cost option. Then we
close any memory map underlying the segment.

Secondly, you don't have to wait for the safepointing to happen.
Instead, null the pointer to the segment, send a message to the VM
thread and then carry on with something else; when a safepoint or a
thread-local handshake happens for some other reason, the VM thread
itself can close the memory map.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the panama-dev mailing list