On Thu, 28 Jul 2022 14:33:40 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>
> > It then basically tests just that newly constructed SoftReference is not
> > cleared in the next moment after construction.
>
> Yes, but not really. There is still a 100ms sleep and reference processing
> involved, which somewhat verifies that the cache is not blown away
> immediately/accidentally.
Just a 100ms sleep means hardly any chance that reference processing will be
involved as VM practically does nothing at that time to trigger GC. If you are
referring to this:
// to trigger any ReferenceQueue processing...
lookupObjectStreamClass(AnotherTestClass.class);
...then the comment is perhaps misleading. Looking up another class just caches
another entry and at the same time processes any enqueued References to remove
stale cache entries. But for a Reference to be enqueued into a ReferenceQueue,
GC threads must 1st clear it and link it into a "pending" list,
ReferenceHandler java thread must then unlink it from the "pending" list and
enqueue it into Reference's associated ReferenceQueue and only then can the
request for another class process it from that ReferenceQueue. But the test is
not observing that 3rd part (cleanup of stale cache entries). It observes the
1st part (atomic clearing of all XxxReferences that refer to the same referent)
which is performed by GC. So this is hardly going to happen as the sole trigger
for that (since System.gc() was removed) remains allocation of new objects and
not enough may be allocated to trigger GC.
But if your purpose was to shut up the failing test, then this is one way to do
it.
>
> > Who is responsible to select the GC algorithm?
>
> CIs routinely test existing suites with different GCs. The PR body contains a
> sample reproducer how that happens. If you are doing the separate `@run`
> statements, you need to also check for `@requires vm.gc.XXX`, etc.
Thanks for the hint. I'll add that.
-------------
PR: https://git.openjdk.org/jdk/pull/9533
