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

[Erik Österlund]

Hi,

The code cache can be occupied by vtable stubs on SPARC. One of the 
potential scenarios are continuous creation and unloading of class loaders.
It causes excessive allocation and deallocation of nmethods for classes 
in said class loaders. If call patterns are megamorphic, those nmethods 
will allocate corresponding vtable stubs for megamorphic inline cache 
transitions. While the nmethods are recycled, their corresponding vtable 
stubs are never released.

Normally, it is not a problem that vtable stubs are not cleaned up 
during code cache unloading, because they are shared. There is one for 
each VM-level signature, and the number of signatures does not grow out 
of control.

However, on SPARC, the vtable stubs are not shared, and are instead 
continuously allocated, causing a nasty leak that is considerable.

SPARC is the only architecture where we do not share vtable stubs. The 
switch for opting in to vtable stub sharing is the developer flag 
ShareVtableStubs. The description of the flag makes it seem like turning 
sharing off is a sweet optimization you can use if your branch 
prediction is bad and you would rather use a bit more memory, without 
mentioning that you get a nasty memory leak. It's mentioned that two 
benchmarks ran faster with sharing turned off. The flag was introduced 
longer ago than I can track back (Niagara?!), and since then SPARC 
machines have *much* better branch prediction. This flag doesn't seem to 
make sense today.

The obvious solution is to remove the flag and have all architectures 
consistently use vtable stub sharing, and hence not leak memory 
uncontrollably. So that is what I propose to do about this.

Webrev:
http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8229345

Thanks,
/Erik