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

[Remi Forax]

On November 23, 2017 2:12:37 PM GMT+01:00, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>
>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.

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.

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

>
>Best regards,
>Vladimir Ivanov

regards,
Rémi 

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.