Testing no memory leak occurs via references
Aleksei Ivanov
alexey.ivanov at oracle.com
Mon Mar 6 15:11:23 UTC 2023
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
More information about the core-libs-dev
mailing list