Re:GC Tuning Confessions of a Performance Engineer
by pron on Saturday May 30, 2015 @12:46AM
(#9629015)
> I think he means that if you have object references, then those references are interesting for the application itself, and not just for the GC tracer.
What I mean is that either those refs are permanent -- in which case they won't be traced -- or arbitrary -- in which case it's really more of an "arbitrary" problem than a "permanent" one.
> The "arbitrary" scope better not be really arbitrary since even GCs are typically tuned for the generational hypothesis
By arbitrary I mean long-lived (old-gen) but not permanent. In short: database data.
> For things like databases where object lifetime is in the hands of the user, arena/slab allocators work just fine.
What you are saying is that you never truly have arbitrary-lifetime objects, and I strongly disagree with that.
> the time spent there may end up exceeding arena impl costs.
Even if you're right about arenas (which I don't agree with), you believe that a runtime designed to target the vast majority of server software should force developers to figure out lifetimes and that that may be beneficial to them? I mean, I even mentioned arena just to get that much closer to 100% performance. Even without them Java gets to at least 90%. Are you suggesting that the vast majority of projects in the world are interested in doing more work that is likely error prone just to get that 10% at best?
What I mean is that either those refs are permanent -- in which case they won't be traced -- or arbitrary -- in which case it's really more of an "arbitrary" problem than a "permanent" one.
> The "arbitrary" scope better not be really arbitrary since even GCs are typically tuned for the generational hypothesis
By arbitrary I mean long-lived (old-gen) but not permanent. In short: database data.
> For things like databases where object lifetime is in the hands of the user, arena/slab allocators work just fine.
What you are saying is that you never truly have arbitrary-lifetime objects, and I strongly disagree with that.
> the time spent there may end up exceeding arena impl costs.
Even if you're right about arenas (which I don't agree with), you believe that a runtime designed to target the vast majority of server software should force developers to figure out lifetimes and that that may be beneficial to them? I mean, I even mentioned arena just to get that much closer to 100% performance. Even without them Java gets to at least 90%. Are you suggesting that the vast majority of projects in the world are interested in doing more work that is likely error prone just to get that 10% at best?