[foreign] RFR: avoid use of ids for upcall handlers

[Maurizio Cimadamore]

Updated webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/upcall_cleanup_v2/

This one copletely avoids the jump business - by saving the JNI handle 
in a different segment (the one for constants), which can also be more 
easily retrieved given the blob.

Note that the routine that saves the address into the constant segment 
takes alignment into account.

Cheers
Maurizio


On 25/06/18 21:04, Maurizio Cimadamore wrote:
> Thanks for the comment - I thought about alignment too - tomorrow I'll 
> do some experiments; it is also possible that we can just store the 
> jobject pointer in the data segment of the code blob, which will get 
> rid of most of the issues.
>
> Maurizio
>
>
> On 25/06/18 20:51, John Rose wrote:
>> Good improvement.
>>
>> Please add something like this to ensure that the OOP_OFFSET value
>> doesn't bit-rot:
>>
>>     // stub code
>> ++ address entry_pc = __ pc();
>>     __ enter();
>> +
>> +  Label target;
>> +  __ jmp(target, true);
>> +
>> ++ __ align(wordSize)
>> ++ guarantee(__ pc() - entry_pc == OOP_OFFSET, "correct constant");
>> +  Address rec_adr = __ as_Address(InternalAddress(__ pc()));
>> +
>> +  __ code_section() -> emit_address((address)rec);
>>
>> Since the rec jobject is a constant, there is no need on x86 for 
>> alignment,
>> but it still seems untidy to me not to align the pointer.  So I also 
>> suggested
>> the alignment op above.
>>
>> — John
>>
>>
>> On Jun 25, 2018, at 11:09 AM, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com> wrote:
>>> Hi,
>>> I've attempted to replace the use of integer ids to represent the 
>>> upcall handler we wish to call from native code. Instead, this patch 
>>> stores the address of the upcall handler object _inside_ the 
>>> generate stub (and has the stub jump over it). Since the GC can move 
>>> objects around, what is saved in the code buffer is a global jni 
>>> handle. I also added logic to deallocate both the stub and the 
>>> global handle when the associated UpcallStub Java object is no 
>>> longer used - this never happened before since all the UpcallHandler 
>>> instances were kept alive inside a static array list (which is now 
>>> removed).
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/panama/upcall_cleanup/
>>>
>>> Maurizio
>>>
>>>
>