RFR: 8271008: appcds/*/MethodHandlesAsCollectorTest.java tests time out because of excessive GC (CodeCache GC Threshold) in loom

Tobias Hartmann thartmann at openjdk.java.net
Mon Feb 21 09:20:53 UTC 2022


On Thu, 17 Feb 2022 13:34:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> In Loom there's a full heap walk when the sweeper is triggered.  Many of the triggers in this test case are for the adapters created by the test, which are not deallocated.  Since there is a fall back to other code cache heap areas for NonNMethod and for NMethodProfiled, made the function CodeCache::reverse_free_ratio() examine the total code cache available rather than the specific area that it is allocating into.  The compilation policy also uses this to increase the C1 compile threshold so also uses the entire free code cache size to calculate new threshold (ask @TobiHartmann about this).  Thanks to Tobias for the discussion for this fix.
> Tested with tier1-4.

Looks good to me. Thanks for fixing this.

src/hotspot/share/code/codeCache.cpp line 897:

> 895: // Since code heap for each type of code blobs falls forward to the next
> 896: // type of code heap, return the reverse free ratio for the entire
> 897: // code heap.

Suggestion:

// Returns the reverse free ratio. E.g., if 25% (1/4) of the code cache
// is free, reverse_free_ratio() returns 4.
// Since code heap for each type of code blobs falls forward to the next
// type of code heap, return the reverse free ratio for the entire
// code cache.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7514


More information about the hotspot-dev mailing list