[10] JBS: 8167408: Invalid critical JNI function lookup

dean.long at oracle.com dean.long at oracle.com
Wed Nov 1 18:08:58 UTC 2017


OK, somehow I missed the part about JavaCritical methods only being 
called from compiled code.  So -Xcomp makes sense.

dl


On 11/1/17 5:46 AM, Vladimir Ivanov wrote:
> No magic here: the test isn't designed to be executed in interpreter 
> and always expect LookUp::test() to be compiled first.
>
> Normal JNI entries are empty, but the test checks that the first 
> element is written to on the first invocation.
>
> I agree that the bug is specific to JIT-compilers, since critical 
> entry points (JavaCritical_) are called only from compiled code. 
> Interpreter always goes through ordinary native counterparts (Java_).
>
> IMO using -Xcomp is fine to force the methods to be compiled. -Xbatch 
> is redundant in that case.
>
> Best regards,
> Vladimir Ivanov
>
> On 11/1/17 7:46 AM, David Holmes wrote:
>> On 1/11/2017 1:11 PM, David Holmes wrote:
>>> On 1/11/2017 1:03 PM, dean.long at oracle.com wrote:
>>>> Much better.  But why does the test need -Xbatch -Xcomp?  To me 
>>>> this doesn't look like a compiler-only issue.  The test should give 
>>>> the same result with -Xint right?  Adding runtime alias for their 
>>>> input...
>>>
>>> AFAICS this should be a completely compiler and platform agnostic 
>>> issue. 
>>
>> Platform agnostic yes, but the test fails without -Xcomp (doesn't 
>> seem to need -Xbatch). So there's something about this critical 
>> function mechanism that I don't understand.
>>
>> That said the test needs more logging so that if it does fail you can 
>> see what, if anything got executed. So the non-critical versions of 
>> the methods should print that they were called, and for good measure 
>> also the critical versions.
>>
>> Thanks,
>> David
>>



More information about the hotspot-runtime-dev mailing list