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

[John Rose]

Yes, that's better.

On Jun 26, 2018, at 3:35 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 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
>>>> 
>>>> 
>> 
>