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
