jamesfredley commented on code in PR #2374:
URL: https://github.com/apache/groovy/pull/2374#discussion_r2752174308
##########
src/main/java/org/codehaus/groovy/vmplugin/v8/CacheableCallSite.java:
##########
@@ -124,4 +124,22 @@ public MethodHandle getFallbackTarget() {
public void setFallbackTarget(MethodHandle fallbackTarget) {
this.fallbackTarget = fallbackTarget;
}
+
+ /**
+ * Clear the cache entirely. Called when metaclass changes to ensure
+ * stale method handles are discarded.
+ * <p>
+ * This method synchronizes on the lruCache to ensure atomicity with
+ * concurrent {@link #getAndPut} operations.
+ */
+ public void clearCache() {
+ // Clear the latest hit reference and the LRU cache atomically
+ synchronized (lruCache) {
+ latestHitMethodHandleWrapperSoftReference = null;
+ lruCache.clear();
+ }
+
Review Comment:
**Update:** This contradicts your previous comment (#5) which suggested
moving it **inside** the synchronized block. After analysis, we concluded that
**neither position affects correctness** because:
1. The volatile field is a best-effort heuristic, not a correctness mechanism
2. `getAndPut()` accesses it outside the lock anyway, so no atomicity is
achievable
3. The race is benign (worst case: slightly skewed hit count statistics)
We're keeping it **outside** the synchronized block (as you suggested here)
for consistency with `getAndPut()`, with documentation explaining the design
intent. See commit 8c05bd5f46.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
