[8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option

[Konstantin Shefov]

There is one more bug associated with this problem: 
https://bugs.openjdk.java.net/browse/JDK-8067005
I can change all 4 tests.

Your idea sounds good, because we may expect more iterations to run 
before code cache overflows.

-Konstantin

On 06/09/2015 01:28 PM, Vladimir Ivanov wrote:
> Konstantin, thanks for figuring that out.
>
> I had a private discussion with Igor and we agreed that catching 
> "expected" exceptions (NSME and VME) is more robust than hand tuning 
> test limits to particular configurations.
>
> The idea is to gracefully finish the test once code cache is full, 
> instead of trying to avoid code cache overflow at all costs in all 
> test configurations.
>
> In order to lower the risk of missing product issues, exception 
> messages can be checked as well:
>   NSME: "no such method: java.lang.invoke.MethodHandle.linkTo.*"
>   VME: "out of space in CodeCache for adapters"
>
> Though checking error messages is fragile as well, IMO in lesser 
> extent than hardcoded limits. Do you have any objections to such 
> approach?
>
> As a strawman proposal, you can introduce a helper in test library:
>   ignoreException(Runnable test, Function<Throwable, Boolean> filter)
>
> Also, please, find and adjust other tests where hard coded limits are 
> set.
>
> Best regards,
> Vladimir Ivanov
>
> On 6/8/15 7:22 PM, Konstantin Shefov wrote:
>> Vladimir,
>>
>> You were right when you said that problem is not in JDK 8u.
>> I have examined the test code once more and found the following.
>>
>> In JDK 9 because of the Segmented code cache feature I have modified the
>> tests to support it, and in JDK 9 the number of iterations is limited by
>> the size of "NonProfiledCodeHeapSize", while in JDK 8u the number of
>> iterations is limited by "ReservedCodeCacheSize".
>>
>> But "ReservedCodeCacheSize" is usually about 256 MB, while
>> "NonProfiledCodeHeapSize" is about 128 MB. So in JDK 8u there are twice
>> more iterations happen when in JDK 9.
>>
>> If we run JDK 8u tests against JDK 9 with the same "-Dseed", we will
>> have VirtualMachineError on JDK 9.
>>
>> So there is NO product issue.
>>
>> In the file "test/java/lang/invoke/LFCaching/LambdaFormTestCase.java"
>> there is a constant defined called 
>> "ITERATIONS_TO_CODE_CACHE_SIZE_RATIO".
>> This constant has been measured with respect to -Xmixed mode only.
>>
>> So my suggestion to fix this test is to define one more constant for
>> "-Xcomp" mode and use it in "-Xcomp" mode.
>>
>> -Konstantin
>>
>> On 06/05/2015 09:04 PM, Vladimir Ivanov wrote:
>>> Konstantin,
>>>
>>>>> I'd like to get an answer to my previous question:
>>>>> "How reliable the test is if it ignores NoSuchMethodException &
>>>>> VirtualMachineError? Are there other manifestations of the problem?"
>>>>>
>>>>> Most notably, have you seen VM crashes w/ -Xcomp running that test?
>>>> I have seen no crashes with -Xcomp in our tests results base, only
>>>> NoSuchMethodException and VirtualMachineError.
>>> Good. Thanks for the info.
>>>
>>>> This failure does not occur with JDK 9 on -Xcomp, I used the same 
>>>> random
>>>> seeds (-Dseed), and the problem exists only with JDK 8u, not JDK 9.
>>>>
>>>> Because there is no failure with JDK 9 I can suppose there could be a
>>>> product issue in JDK 8u.
>>> That's strange. There should be no difference in MethodHandle stub
>>> management between 8u & 9 now (once allocated they stay forever). 9
>>> has segmented code cache feature and it can lead to observable
>>> differences in behavior.
>>>
>>> How many iterations does the test perform on 8u & 9? What if you
>>> increase the number? Also, I'd suggest you to monitor code cache usage
>>> during the run and when the test finishes.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>