Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)?

[Karen Kinnear]

First, many thanks for all the work in this area - it is a very important one. 
Zhengyu’s fix seems like a good first step here.

Coleen asked David Holmes and I how this relates to the future of nestmates.

The nestmate relationship here is a the plan in jdk 11 to evolve away from Unsafe.DefineAnonymousClass. In jdk 10 Alan added Lookup.defineClass(byte[]) which operates in Package Mode to allow you to create a findable class in the same package/class loader/protection domain as the caller in the Lookup object.

The intention is to extend Lookup.defineClass() in two dimensions. The first is to allow dynamic creation of nestmates of the Lookup’s caller, based on the authority granted by having a Lookup with lookup mode private. This nest mate would not only be in the same package/class loader/protection domain, it would be granted nest mate access to private members declared in the nest of the Lookup’s caller.

The second dimension we want to expand is the evolution of Unsafe.DefineAnonymousClass by added a boolean that can allow creating non-findable, temporary classes - which can therefore be unloaded independently of any other references to a given class loader. When customers adopt this, we will see an increase in the need to unload individual classes for existing class loaders.

In terms of the isolated methods question - I do not know exactly what John Rose’s vision is here. I do know that in discussions with Michael Haupt, in feedback from the JVMLS 2016 at which he introduced it, that there is interest in information regarding isolated methods (sorry, I really think independent method might be a better name) such as
   - constant pool constants for the byte codes
   - debug information such as line number tables
   - ability to invoke bootstrap methods, so attributes of some form
   …
   My understanding is that the lifecycle of these methods would be temporary, controlled by the lifecycle of the MethodHandle representing them.

My point here is - that these methods will require some set of temporary metadata, much of which is similar to the metadata we currently need to execute a method, so we will need a place to store it. At this point it is not clear to me that this would obviate the need for a good way to store/free temporary metadata.

thanks,
Karen

> On Nov 27, 2017, at 8:57 AM, Zhengyu Gu <zgu at redhat.com> wrote:
> 
> Hi,
> 
> Sorry, I was out for Thanksgiving holiday.
> 
> The prototype was done under JDK-8190729 (https://bugs.openjdk.java.net/browse/JDK-8190729).
> 
> The patch uses up to 4 SpecializeChunks for anonymous metadata space, then switches to SmallChunks. It covers well with my testcases, where about 98.5% metadata space size is under 4K. For occasional big anonymous metadata spaces, it starts to allocation SmallChunks after 4K.
> 
> The reason that it is on hold, is that, it appears to have missed jdk10 train (see comments in bug). Under this circumstance, I would love to test more applications to see size distributions still in neighborhood of the assumption, or should make it another VM parameter (?).
> 
> Thomas, have you seen the similar size distribution pattern, or otherwise?
> 
> 
> Thanks,
> 
> -Zhengyu
> 
> 
> 
> On 11/24/2017 12:23 PM, Thomas Stüfe wrote:
>> On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn <adinn at redhat.com> wrote:
>>> One small additional comment:
>>> 
>>> On 24/11/17 09:18, Andrew Dinn wrote:
>>>> On 23/11/17 20:43, Thomas Stüfe wrote:
>>>>> ...
>>>>> Well, this sounds both simpler and more to the point than my proposal
>>> (2).
>>>> 
>>>> Not quite. We know that the "half-eaten-medium-chunk" problem is really
>>>> a bad problem for anonymous class loaders and Zhengyu's patch improves
>>>> that case. We don't know it is that is the only problem case. Other
>>>> loaders may only load a small number of classes -- perhaps 1, maybe 2 --
>>>> and also end up wasting a lot of space. If an app hits that case a lot
>>>> then your proposal would allow the user to configure round it.
>>> n.b. I'm not sure we need to worry much about any such apps as this
>>> scenario is, arguably, very unlikely? I know, for example, that JBoss
>>> Modules uses many classloaders but they rarely load just one or two
>>> classes. Once you get to 3 or 4 classes I think the current behaviour
>>> will be unlikely to increase waste because larger chunks means less
>>> fragmentation. Are OSGi loaders likely to load just one or two classes
>>> for a significant number of loaders?
>>> 
>>> 
>> I do not think so. I think you are right, this is less pressing once we get
>> Zhengyus patch.
>> I will add the switch when there is some time, I still think it may be good
>> to have.
>> Kind Regards, Thomas
>>> regards,
>>> 
>>> 
>>> Andrew Dinn
>>> -----------
>>> Senior Principal Software Engineer
>>> Red Hat UK Ltd
>>> Registered in England and Wales under Company Registration No. 03798903
>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>>