On Thu, 4 Dec 2025 16:07:50 GMT, Chris Plummer <[email protected]> wrote:

>> Hello,
>> 
>>  If the initial heap size is set too low in the following tests a GC might 
>> run, which will interfere with the tests and migh cause them to fail. To 
>> solve this, we should run the tests with a bumped initial heap size so that 
>> the GC does not interfere.
>>  
>> Test originally failed when run with `-XX:InitialRAMPercentage=0`. We now 
>> explicitly set `-XX:InitialHeapSize=100M` and they now always pass.
>> 
>> Testing:
>> * Rerun 10 times with Serial and Parallel for each test and they all pass
>
> test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java line 32:
> 
>> 30:  * @run build TestScaffold VMConnection TargetListener TargetAdapter
>> 31:  * @run compile -g MethodInvokeWithTraceOnTest.java
>> 32:  * @run driver MethodInvokeWithTraceOnTest -XX:InitialHeapSize=100M
> 
> Are you seeing failures due to an ObjectCollectionException? If so, avoiding 
> GC is not the proper way to fix it. Even with a larger initial heap, there 
> can still be an object collected with ZGC. We shouldn't have any debugger 
> tests that rely on a GC not happening in the debugee. The proper fix is 
> usually calling ObjectReference.disableCollection(), although sometimes even 
> that is not enough (the call can happen too late if the debugee is not 
> suspended).

Yes, we're seeing a failure due to ObjectCollectionException. This is because 
the heap size is now much smaller, causing more frequent GCs. "Reverting" to a 
larger initial heap size is a straightforward fix so that we can continue 
running this test.

I think a more "robust" approach is better, which we could do in a follow-up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28637#discussion_r2589716575

Reply via email to