[foreign-abi] Intrinsify down calls

[Jorn Vernee]

Hi,

For now I've reimplemented the stub lifetime management without using a 
cleaner. As mentioned, the stubs are now attached to the nmethod, and 
cleaned up when the nmethod is. This also means we can defer the stub 
generation until intrinsification happens, which in itself reduces 
pressure on the code cache.

The diff can still be found here: 
https://github.com/openjdk/panama-foreign/compare/foreign-abi...JornVernee:Call_Intrinsics_Stubs

This gets all tests passing again, and performance numbers still look good.

Jorn

On 29/04/2020 13:58, Maurizio Cimadamore wrote:
>
> 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
>