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

[Maurizio Cimadamore]

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
>>
>>