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

[Erik Osterlund]

Hi Martin,

Thanks for reviewing, and for sharing your experience on your SPARC machines.

/Erik

> On 15 Aug 2019, at 17:16, Doerr, Martin <martin.doerr at sap.com> wrote:
> 
> Hi Erik,
> 
> nice change! I like it.
> 
> We already switched this flag on in SAP JVM on SPARC.
> We're also convinced that "improves performance markedly for mtrt and compress" is no longer true on recent hardware.
> 
> Best regards,
> Martin
> 
> 
>> -----Original Message-----
>> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
>> Erik Österlund
>> Sent: Donnerstag, 15. August 2019 17:01
>> To: hotspot-dev developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on
>> SPARC
>> 
>> 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