On 08/03/2023 10:36, David Holmes wrote:
On 7/03/2023 8:16 pm, Kim Barrett wrote:
On Mar 6, 2023, at 10: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 duratio
On 7/03/2023 8:16 pm, Kim Barrett wrote:
On Mar 6, 2023, at 10: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
t
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
> On Mar 6, 2023, at 10: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
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 str
Hi Albert,
The only downside of the WhiteBox API is the need to link and run with
native code.
It make adhoc testing more difficult.
I would not say ForceGC relies on chance, since it is testing the
specific condition as requested by the caller.
It uses mechanisms available to normal applica
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.
> I decid
Thank you, Stuart and Roger, for the suggestion.
I didn't know about ForceGC class. We should use the common library, I
have updated my PR [7] with ForceGC.
Albert and Thomas suggested using WhiteBox API. It would probably work
too, however, I decided ForceGC is simpler and easier to use, so
Hi,
On 03.03.23 19:02, Aleksei Ivanov wrote:
> Hello,
>
> In clientlibs, there's occasionally a need to verify an object isn't
> leaked. For this purpose, WeakReference or PhantomReference is used.
>
> Then, we need to make the reference object be cleared, so a GC cycle
> need to be triggered. Th
As Roger mentioned, there is a ForceGC utility in the test library:
test/lib/jdk/test/lib/util/ForceGC.java
and it's used in a variety of places in the core libs tests. Essentially it sets up
a PhantomReference and a ReferenceQueue and runs System.gc() in a loop. I'd strongly
recommend usi
I wonder if `WhiteBoxAPI` can be used if the goal is to trigger a (Full) GC
cycle. An example is `whitebox.fullGC()` in
`test/jdk/java/lang/ref/CleanerTest.java`.
/Albert
Hi,
There is test library class jdk.test.lib.util.ForceGC that is useful for
that case.
It uses a PhantomReference to detect that gc has been run.
And it can be called with a function that can test for another condition.
For an example, look at the tests that use ForceGC in test/jdk/...
Regar
Hello,
In clientlibs, there's occasionally a need to verify an object isn't
leaked. For this purpose, WeakReference or PhantomReference is used.
Then, we need to make the reference object be cleared, so a GC cycle
need to be triggered. The common approach is generating
OutOfMemoryError, catc
13 matches
Mail list logo
