Hi Daniil,
Couple minor notes:
- Debugee.DEFAULT_MAIN_THREAD_NAME makes sense only for
HeapwalkingDebuggee-inherited tests, so it would be better to move the
constant to the class (and make it protected);
- HeapwalkingDebuggee.useStrictCheck can be simplified to something like
switch (className) {
case "java.lang.String":
case "char[]":
case "byte[]":
case "boolean[]":
case "float[]":
case "long[]":
case "int[]":
case "double[]":
return false;
case "java.lang.Thread":
if (otherThreadPresent) {
return false;
}
break;
}
return true;
--alex
On 06/22/2018 19:13, Daniil Titov wrote:
Please review the changes that fix 15 tests failures when running with Graal.
The main problem here is that the tests assume that no garbage collection
happens before the tests complete their checks. The other problem is that the
tests could not strictly distinguish the objects created by the debuggee on the
request from the test from the objects of the same class created by the
debuggee VM on its own. In case when java.lang.String or arrays of primitives
are used in the tests the number of objects the test operates could
significantly exceeds the number of the objects the test actually created and
iterating over all of them results in the timeout.
The fix ensures that the object references created in the tests are protected
from garbage collection or modifies the test to expect an
ObjectCollectedException where necessary. In some cases, the fix ensures that
only the main thread of the debuggee is running to prevent the garbage
collector thread to create objects of the same class the test is working with
and avoid timeouts.
Webrev: http://cr.openjdk.java.net/~dtitov/8203174/webrev.01
Bug: https://bugs.openjdk.java.net/browse/JDK-8203174
Thanks,
Daniil
