Reducing Garbage Generated by URLClassLoader
mkanat at google.com
Tue Dec 6 07:11:09 UTC 2016
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>
> > Yeah, I have implemented a fast-path byte-only ZipCoder in a customized
> > 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?
> > 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
> > the cleanest, but it doesn't regress the "needs encoding" path.
> > It also is possible to optimize URLClassLoader itself to do a better job
> > caching zip entries, which significantly reduces the String allocation
> > if you're doing a lot of lookups on the classpath. I have also
> > something like this, but it's hard to get right and my changes aren't in
> > state where they could be easily upstreamed.
> > -Max
More information about the core-libs-dev