RFR (S): 8229345: Memory leak due to vtable stubs not being shared on SPARC

[Hohensee, Paul]

Thanks for the review, Andrew.

The jdk14 patch is from 2019, so I updated the copyright dates to then. They'd already been updated in jdk14 by then.

The jdk14 vtableStubs.cpp patch is

@@ -213,7 +213,7 @@
   VtableStub* s;
   {
     MutexLocker ml(VtableStubs_lock, Mutex::_no_safepoint_check_flag);
-    s = ShareVtableStubs ? lookup(is_vtable_stub, vtable_index) : NULL;
+    s = lookup(is_vtable_stub, vtable_index);
     if (s == NULL) {
       if (is_vtable_stub) {
         s = create_vtable_stub(vtable_index);

whereas the backported patch is

@@ -108,11 +108,11 @@
 

 address VtableStubs::find_stub(bool is_vtable_stub, int vtable_index) {
   assert(vtable_index >= 0, "must be positive");
 
-  VtableStub* s = ShareVtableStubs ? lookup(is_vtable_stub, vtable_index) : NULL;
+  VtableStub* s = lookup(is_vtable_stub, vtable_index);
   if (s == NULL) {
     if (is_vtable_stub) {
       s = create_vtable_stub(vtable_index);
     } else {
       s = create_itable_stub(vtable_index);

The jdk14 patch includes locking the VtableStubs_lock, which latter isn't present in the 8u version. There's a syntax-only difference in that the local variable "s" is initialized as part of its declaration in the backported patch, but not in the jdk14 patch because of the lock.

The test wasn't part of the original patch, so it's not in the backport either. Looking at test2.log (the sample bad log output), you have to run it "long enough" to produce a pattern of "higher lows" and then recognize that that's what's happening. That'd be a pain to write so that it works in a test harness. I ran the test on x64 with -XX:ReservedCodeCacheSize=16m and got

0 getUsage():init=2496K,commit=3968K,used=3964K,max=16384K,max=16777216
3133 getUsage():init=2496K,commit=9024K,used=8994K,max=16384K,max=16777216
6134 getUsage():init=2496K,commit=10496K,used=10455K,max=16384K,max=16777216
9135 getUsage():init=2496K,commit=11904K,used=11835K,max=16384K,max=16777216
12135 getUsage():init=2496K,commit=12800K,used=12764K,max=16384K,max=16777216
15136 getUsage():init=2496K,commit=13696K,used=13584K,max=16384K,max=16777216
18136 getUsage():init=2496K,commit=14336K,used=13681K,max=16384K,max=16777216
21137 getUsage():init=2496K,commit=14720K,used=14609K,max=16384K,max=16777216
24137 getUsage():init=2496K,commit=15616K,used=15500K,max=16384K,max=16777216
OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
CodeCache: size=16384Kb used=15814Kb max_used=15814Kb free=569Kb
 bounds [0x00007f5cc249d000, 0x00007f5cc349d000, 0x00007f5cc349d000]
 total_blobs=10852 nmethods=10339 adapters=430
 compilation: disabled (not enough contiguous free space left)
27137 getUsage():init=2496K,commit=16384K,used=12701K,max=16384K,max=16777216
30138 getUsage():init=2496K,commit=16384K,used=13607K,max=16384K,max=16777216
33138 getUsage():init=2496K,commit=16384K,used=14470K,max=16384K,max=16777216
36138 getUsage():init=2496K,commit=16384K,used=15329K,max=16384K,max=16777216
39138 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
42139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
45139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
48139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
51139 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
54140 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
57140 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
60140 getUsage():init=2496K,commit=16384K,used=15803K,max=16384K,max=16777216
63140 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216
66141 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216
69141 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216
72141 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216
75142 getUsage():init=2496K,commit=16384K,used=15521K,max=16384K,max=16777216

Code cache occupancy ends up static, which I suppose would be detectable. Going strictly by the rules, if we want a test, we'd have to produce one for tip and backport it.

Paul

On 1/24/20, 11:58 PM, "jdk8u-dev on behalf of Andrew John Hughes" <jdk8u-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:

    
    
    On 23/01/2020 20:40, Hohensee, Paul wrote:
    > Please review this backport to 8u.
    > 
    > Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8229345
    > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/0a8407a78a2f
    > Webrev: http://cr.openjdk.java.net/~phh/8229345/webrev.8u.00/
    > 
    > The backport applied somewhat cleanly. The exceptions were adding 2019 copyright dates, the removal of the unsupported-in-8u globals_aarch64/arm/s390.hpp patches, and a slight difference in the vtableStubs.cpp patch due to 8u not acquiring the VtableStubs_lock.
    > 
    > Thanks,
    > Paul
    > 
    
    Generally looks ok, though if we must add these copyright header
    changes, should it not be to 2020 now?
    
    Neither I nor diff see any change between the two vtableStubs.cpp
    patches. Is there really something different there?
    
    I agree it would be good to check the testcase on SPARC. Any idea why
    the test is not part of the backported changeset?
    
    Thanks,
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
    https://keybase.io/gnu_andrew