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

[Vladimir Ivanov]

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
>