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

[Vladimir Ivanov]

>> 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.
> 
> is it still affect perf ? I think a guy from elastic search mention that they use method handles in their proxy class with no perf issue.

I don't remember what exactly elastic search did, but yes, it does (due 
to type profiling pollution). Current scheme produces a class-per-lambda 
and profile info allows to disambiguate lambda body.

In case lambda body is represented as a method handle and stored is a 
field (class-per-shape), type profile becomes useless.

(There's another problem - constant folding loads from final fields - 
but it's quite easy to fix inside jdk by marking corresponding classes 
as trusted.)

> We may also be able to create parameterized class with a method handle hole as part of Valhalla.

Interesting. A class parameterized by a method handle instance?

JVM support for reified dependent types? :-)

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
>>>
>