Testing no memory leak occurs via references

[Philip Race]

Having just a very few sources of wisdom on this in the JDK test suites 
is a good idea because
then any tests that might be affected by policy changes would be easily 
spotted.
I say this despite an instinctive reticence to rely on "frameworks" and 
"utilities" in jtreg tests.
As resources allow we should look into that (across all areas).

I don't know if tests which expect to run with the default GC would be 
wise setting a specific GC.
Testing "out of the box" is more important to (eg) client tests.

I also think native code is a problem because a lot of tests are run 
using jtreg *outside* of a build.
ie add jtreg and a build to your path and then run jtreg. This is 
actually normal not an aberration.
It has come to me as a surprise in the past that folks who work on VM 
etc were surprised at this :-)
So its not easy to build the native code then.

The observations about the fragility of the VM in OOME situations is noted.
Also othervm mode just seems a lot safer for all the above tests.

-phil.

PS someone

On 3/6/23 7:11 AM, Aleksei Ivanov wrote:
> On 06/03/2023 13:51, Albert Yang wrote:
>> Upon a cursory inspection of ForceGC.java, it seems that the 
>> fundamental logic involves waiting for a certain duration and relying 
>> on chance. However, I am of the opinion that utilizing the WhiteBox 
>> API can provide greater determinism and potentially strengthen some 
>> of the assertions.
>
> Yes, it calls System.gc in a loop and waits for a reference to become 
> cleared.
>
> (It looks as if the body of ForceGC duplicates what one would have in 
> the passed BooleanSupplier which again tests if a reference is cleared.)
>
>>> I decided ForceGC is simpler and easier to use
>> I was not aware of your specific requirements, so I cannot say for 
>> certain which approach is best. (However, it is worth noting that the 
>> WhiteBox API can be utilized to implement ForceGC if necessary.)
>
> My test is written to ensure awt.List gets garbage-collected when 
> there are no strong references to it. Before JDK-8040076 had been 
> fixed it wasn't.
>
> So the test creates awt.List, adds it to a frame, calls 
> setMultipleMode(true) to enable multi-selection in the list component, 
> removes it from the frame. At this point, I want to confirm the 
> awt.List can be garbage-collected.
>
> The original test created a very long String to cause OutOfMemoryError 
> and then verified whether the WeakReference to awt.List is cleared or 
> not.
>
> In my first fix, I replaced generating OutOfMemoryError with a call to 
> System.gc() in a loop and waited for the reference object to be 
> cleared. Usually, the reference is cleared in the second iteration if 
> not in the first one.
>
> Essentially, ForceGC does the same thing. So, it replaced my custom 
> code with ForceGC.
>