[foreign-abi] Intrinsify down calls
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Apr 29 11:58:49 UTC 2020
On 29/04/2020 12:43, Jorn Vernee wrote:
> There might be some options for attaching the stub to the nmethod
> itself, and then freeing it when the nmethod is freed. But maybe for
> now we should go back to emitting the thread state transition inline,
> and then improve upon this later.
+1
After chatting with Jorn I'm not overly convinced of the wider
advantages to split the nmethod from the thread transition code. They
will have to be co-generated anyway, so I don't see an advantage in
terms of reduce the amount of generated code; I also don't see an
(obvious) performance edge, since in the common case the nmethod will
have to call the transition stub code.
Using a Cleaner to do this seems like the wrong tool for the job - since
the Cleaner is tuned for heap allocations - and here we have to rely on
it to manage the code cache, whose size is typically much smaller, and
totally opaque to the cleaner anyway. So this presents all the thorny
problems that direct ByteBuffer deallocation via Cleaner also presents:
objects that are not deemed "very important" by the cleaner are left
around hanging, and you eventually run out of space. ByteBuffers did
some heroic attempts to try to kick Cleaner, and add retries with
exponential backoff - but I don't think we wanna go there for such a low
level API as this one?
Cheers
Maurizio
More information about the panama-dev
mailing list