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

[Erik Osterlund]

Hi Vladimir,

Thanks for the review!

/Erik

> On 15 Aug 2019, at 19:35, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Agree. Changes are good.
> 
> Thanks,
> Vladimir
> 
>> On 8/15/19 8:16 AM, Doerr, Martin 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