Testing no memory leak occurs via references

[Aleksei Ivanov]

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.

-- 
Alexey