RFR: 8301737: java/rmi/server/UnicastRemoteObject/serialFilter/FilterUROTest.java fail with -Xcomp [v3]

[SUN Guoyun]

On Tue, 7 Feb 2023 20:47:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'm going to backup a bit; so another question... This test is a fairly simple test that should not be taxing on GC or any other resource so I'm surprised the the default configuration is not sufficient. It might be worth looking a bit deeper into the GC vs Xcomp conditions and the interplay with "looongaarch64". I can't help much there, not being familiar with details of GC or the compiler.

Using `-Xcomp` necessarily results in more methods being compiled. And in hotspot, the codecache does not trigger the GC after it is full, but triggers the GC when it reaches a certain threshold with `SweeperThreshold`. 

<pre><code class="cpp">
// ./src/hotspot/share/code/codeCache.cpp
 818   if (allocated_since_last_ratio > threshold) {        // threshold  = SweeperThreshold / 100.0;                  
 819     // In case the GC is concurrent, we make sure only one thread requests the GC.
 820     if (Atomic::cmpxchg(&_unloading_threshold_gc_requested, false, true) == false) {
 821       log_info(codecache)("Triggering threshold (%.3f%%) GC due to allocating %.3f%% since last unloading (%.3f%% used -> %.3f%% used)",
 822                           threshold * 100.0, allocated_since_last_ratio * 100.0, last_used_ratio * 100.0, used_ratio * 100.0);
 823       Universe::heap()->collect(GCCause::_codecache_GC_threshold);              
 824     }                                                                           
 825   }   
</code></pre>

So, when I adjust `-XX:SweeperThreshold=30`, the test passes also.

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

PR: https://git.openjdk.org/jdk/pull/12399