[
https://issues.apache.org/jira/browse/GROOVY-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105749#comment-18105749
]
ASF GitHub Bot commented on GROOVY-12280:
-----------------------------------------
paulk-asert opened a new pull request, #2818:
URL: https://github.com/apache/groovy/pull/2818
A ClassValue association lives as long as its key class, and the common keys
here are platform classes such as CompletableFuture, so the cached
Groovy-loaded adapter pinned Groovy's class loader for the lifetime of the JVM
(JDK-8136353 behavior, working as intended). The value is now held through a
SoftReference: the association strongly reaches only java.base objects. A
cleared reference is removed and recomputed once; should the fresh reference
already be cleared, the answer comes from an uncached scan, so lookups
terminate under any memory pressure. A NO_ADAPTER sentinel keeps unsupported
types distinguishable from cleared references.
The site deliberately stays on java.lang.ClassValue rather than routing
through GroovyClassValueFactory: with soft values nothing strongly
Groovy-loaded remains in the association, so there is nothing left for the
groovy.use.classvalue escape hatch to release here.
> AwaitableAdapterRegistry.awaitableCache pins the Groovy class loader via
> ClassValue associations on platform-class keys
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12280
> URL: https://issues.apache.org/jira/browse/GROOVY-12280
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> {{AwaitableAdapterRegistry}} caches adapter lookups in a raw
> {{java.lang.ClassValue}} keyed by the awaited object's class. The common keys
> are platform classes — {{CompletableFuture}}, {{CompletionStage}},
> {{Flow.Publisher}} implementations — while the cached value (the adapter
> instance) is loaded by Groovy's class loader. A {{ClassValue}} association
> lives as long as its key class
> ([JDK-8136353|https://bugs.openjdk.org/browse/JDK-8136353], working as
> intended), so an association on an effectively immortal platform class holds
> the adapter, and through it the entire Groovy class loader, for the lifetime
> of the JVM. In the per-webapp deployment topology this re-creates exactly the
> pinning GROOVY-12142 removed elsewhere: metaspace growth on every
> redeployment once any {{await}} has executed.
> Note this site is not covered by the {{groovy.use.classvalue=false}} escape
> hatch restored in GROOVY-12142 — it does not go through
> {{GroovyClassValueFactory}} (which is package-private in
> {{org.codehaus.groovy.reflection}} and not reachable from
> {{groovy.concurrent}}).
> Unlike the general {{ClassInfo}} problem (see the companion investigation
> ticket), the preconditions for the {{SoftReference}} strategy are already
> satisfied here by construction: recomputation is a cheap, pure scan over the
> adapter list, and the registry already rebuilds the cache on mutation.
> Proposed fix: wrap values in {{SoftReference}} with the
> check-remove-recompute discipline (on a cleared reference, {{remove(...)}}
> the association and recompute), optionally also widening
> {{GroovyClassValueFactory}} so this site honors the escape hatch for
> consistency.
> Follow-up from review discussion on [PR
> #2798|https://github.com/apache/groovy/pull/2798] (GROOVY-12142).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
