[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