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

[Thomas Stüfe]

On Thu, Nov 23, 2017 at 5:50 PM, Andrew Dinn <adinn at redhat.com> wrote:

> On 23/11/17 11: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?
>
> Zhengyu developed a prototype patch against jdk8u which extends the time
> an anonymous loader is willing to hand out SpecializedChunks after the
> initial one is exhausted (it will use up to 4 1K chunks before scaling
> up to a 4K chunk). In his tests this brought the average waste down from
> ~60%$ to ~30%. This will be a help for lambdas but in the long term I
> guess the real solution needs to be a solution like the one in M
> Cimadamore's JEP (JDK-8158765).
>
> I have already reviewed this patch privately and found it to be ok. I'll
> leave Zhengyu to reply as to whether he thinks it is ready to push to
> jdk10 and/or down to jdk8.
>
> > My thoughts are
> > . . .
> > (1) could be quite easily implemented. What do you think?
> Well, I guess option (1) might be useful for apps which have a lot of
> normal (non-anon) classloaders that define only small numbers of
> classes. However, the really bad waste %ges we saw with anon loaders
> were because they had just one class and so always had one partial
> chunk. That left a high potential for waste to be in the ~50% range
> (well, actually, it was two partial chunks with CompressedClassPointers
> -- one for the class object and one for the related non-class objects).
> If you have enough classes to start biting into a 2nd chunk (i.e just
> 2-3) then your waste is going to be in the 0-50% range. 3 Chunks puts it
> in the 0-34% range. So, 'small' loaders is not quite such an issue as
> 1-shot 'anon' loaders.
>
> That said, I think (1) could still be helpful for some (unusual?) apps.
> I don't think it is too difficult to implement or as you say to come up
> with a workable default -- the hardest bit will probably be getting the
> new product flag accepted. Zhengyu may have something to say here as well?
>
> regards,
>
>
>
Sounds reasonable. Trying to understand: you estimate that the
"half-eaten-medium-chunk"
problem is only really a bad problem for anonymous class loaders, because
they only ever load
one class, yes? Which is known beforehand, and we do not have to guess at
their future
loading behaviour, which is 0?

Well, this sounds both simpler and more to the point than my proposal (2).

How did Zhengyu arrive at the 4K limit? Why not just always use
SpecializedChunks for
 anon class loaders?

..Thomas


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