Reducing Garbage Generated by URLClassLoader

[Max Kanat-Alexander]

My recollection is that on a binary that does nothing but start up with a
long classpath and try to load most of the classes in it, I saw a 20%
decrease in allocations as well as a noticeable, if small CPU improvement
(but I forget the number for that).

On Mon, Dec 5, 2016 at 12:27 PM, Scott Palmer <swpalmer at gmail.com> wrote:

>
> > On Dec 5, 2016, at 1:31 AM, Max Kanat-Alexander <mkanat at google.com>
> wrote:
> >
> > Yeah, I have implemented a fast-path byte-only ZipCoder in a customized
> JDK
> > and it makes a big difference for allocations in long classpaths.
>
> I expected to see an improvement, but haven’t made any attempt at solving
> the problem yet.  I was just gauging how much interest there was in such a
> change.  It is nice to see that some work has already been done.  Do you
> have numbers?
>
> Regards,
>
> Scott
>
>
> > The basic
> > code to do just that isn't very complex. I could possibly dig that up and
> > upstream it if there's interest. My recollection is that my solution
> isn't
> > the cleanest, but it doesn't regress the "needs encoding" path.
> >
> > It also is possible to optimize URLClassLoader itself to do a better job
> of
> > caching zip entries, which significantly reduces the String allocation
> load
> > if you're doing a lot of lookups on the classpath. I have also
> implemented
> > something like this, but it's hard to get right and my changes aren't in
> a
> > state where they could be easily upstreamed.
> >
> > -Max
>
>