RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles

[coleen.phillimore at oracle.com]

On 2/14/17 11:26 AM, Mikael Gerdin wrote:
> Hi Kim,
>
> On 2017-02-13 05:25, Kim Barrett wrote:
>> Here's the updated webrevs, incorporating feedback received so far.
>>
>> full: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05/
>> incr: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.05.inc/
>
> I think your change is ready to go, consider it Reviewed by me.
>
> I can't really say that I think this looks good due to the fact that 
> I'm still traumatized by JavaCallArguments and how it uses something 
> I've come to think of as "alternative code" to handle oop parameters 
> but that is something that I hope we can clean up at some point in the 
> future.

I agree.  Also, I'm traumatized by the external_guard template parameter 
in jniHandles.hpp.

Kim, thank you for making the changes I suggested, especially in the x86 
code.

It looks good to me.

Coleen

>
> Thanks for fixing this!
> /Mikael
>
>>
>> For x86 and ARM I added resolve_jobject functions to their respective
>> macroAssembler files, and call those to generate the return object
>> handling code.  Merging the two cases for Sparc is harder and I'm
>> going to leave it to someone else.  I'm also leaving any such merging
>> for other (non-Oracle) ports to their respective maintainers.
>>
>> Rewrote the error checking in SignatureChekker::check_obj to simplify
>> the control flow and provide more information.  Rather than
>> conditionally selecting between ReportJNIFatalError or assert to
>> report problems, instead just always use guarantee.  Recall that we
>> only get here if CheckJNICalls or in a debug build.  This made
>> SignatureChekker::_thread unused, so removed it.
>>