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.
