[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8203174: [Graal] JDI tests fail with Unexpected exception: com.sun.jdi.ObjectCollectedExcept
From:       Alex Menkov <alexey.menkov () oracle ! com>
Date:       2018-06-25 18:15:41
Message-ID: 211a436c-c1af-2dca-11e2-f75185888b57 () oracle ! com
[Download RAW message or body]

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
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]