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

[Vladimir Ivanov]

On 11/23/17 3:59 PM, Claes Redestad wrote:
> Hi,
> 
> while non-intrusive and easily attainable improvements to reduce class 
> loader metadata is surely welcome, I think the high-level idea is to 
> remove the overhead entirely  Isolated Methods, see draft JEP: 
> https://bugs.openjdk.java.net/browse/JDK-8158765

Just a note: though Isolated Methods cover most of the current use cases 
of VM anonymous classes, they aren't a complete replacement.

For example, lambdas can't switch to isolated methods: there should be a 
class implementing functional interface to instantiate from. There are 
other VMAC replacement strategies (e.g., caching those classes on 
per-function interface & captured values base), but right now it affects 
performance.

Best regards,
Vladimir Ivanov

> On 2017-11-23 12:56, Thomas Stüfe wrote:
>> Hi Zhengyu and Andrew,
>>
>> Have you had any new ideas on how to deal with
>> https://bugs.openjdk.java.net/browse/JDK-8187338?
>>
>> I also see this in my tests and I think this will be an issue with our
>> customers.
>>
>> My thoughts are
>>
>> 1) as a first workaround to provide a threshold switch to change the
>> small-chunk-limit - the number of bytes a class loader has to allocate 
>> from
>> metaspace and classpace to qualify for medium sized chunks. With such a
>> switch, one could at least tune a system which shows a pathological
>> allocation pattern. E.g., using Zhengyu's new NMT per-classloader 
>> trace, if
>> I see that the majority of all class loaders stop allocating after 500K,
>> I'd set the threshold to 500K.
>>
>> 2) Future better solutions could involve some kind of self-regulating
>> mechanism: Somehow automatically identifying which are "tiny" class 
>> loaders
>> - loaders which have with a certain probability stopped allocoating while
>> still gnawing at their first or second medium chunk. And then, using that
>> number, dynamically adjusting the small-chunk-limit for future class
>> loaders.
>>
>> (1) could be quite easily implemented. What do you think?
>>
>> Kind Regards, Thomas
>