JEP 173: Remove Rarely-Used Combinations of Garbage Collectors

[Srinivas Ramakrishna]

Hello Kirk --

On Thu, Dec 6, 2012 at 2:38 PM, Kirk Pepperdine <kirk at kodewerk.com> wrote:

>
> I started punching out a mind-map for GC just a few days ago... it's no
> where near complete and it's no where near the depth that it needs to be at
> but even at the high level it currently sits at, I've gone beyond the
> capability of the mind map software that Im currently using. Plus, I just
> spent the better part of the day going over some advanced GC concepts with
> a group of developers and testers. I would dearly love to reduce complexity
> and judging by the looks on their faces as we ripped through materials, my
> guess is they'd like to see some simplifications also.
>
> I think there are some possible simplifications. As I mentioned earlier,
> fixing adaptive sizing could be a great first step. I have a GC log that
> I'm happy to send to anyone that illustrates my point.
> >
>
>
Please do.

I'll use this email as a segue into something that has been batted about
casually by the HotSpot GC folks in the past,
but which I now as a consumer of HotSpot GC see as possibly having some
value.

The rationale/motivation is really quite easy to illustrate and will be
easily understood and appreciated by both
GC developers and by GC users. May applications behave differently during
boot-up time and then during actual
operation. A perfect, perhaps oracular (pun not intended! ;-) adaptive size
policy would hit optimal settings in both
phases quickly and yield good behaviour throughout. But as we all know
there's a tradeoff between agility and
over-reaction, so we carefully try and tread a middle ground that tries to
react in an agile fashion to changes in
the application behaviour, but does not oscillate unnecessarily by reacting
to small amounts of noise or spikes
in sensor data.

Now, we have a number of knobs, many of them associated with adaptive
sizing policy, that are available as
product flags for tweaking via the JVM command-line. Some of these,
however, are such that one might benefit by
being able to dynamically tweak them, based on the application's
domain-specific knowledge of its environment
or seasonality or diurnality of its load etc. As an illustration, there may
be useful things that a collection of
servers in a data-centric environment might do, based on their collective
view of the load at the application level,
which a single JVM might not be able to do because it lacks this kind of
more globally distributed information.
Also, one might be able to drive interesting data-centric control of server
gangs via being able to externally and
dynamically tweaking their individual and, by composition, their collective
behaviour. In other words, if we were to
expose external APIs for dynamically tuning some of these settings, we
might be able to perhaps (and note, I say, perhaps)
more optimally control GC behaviour. But it seems as though if a JVM option
flag is "manageable", one can already
use the GC mxbean interfaces to change these values. The limitation may be
our ability to synchronously change
an entire vector of control parameters or, even better, to provide an
advance schedule or, even better, an intelligent
schedule (aka a control program) for their synchronous management. This is
just another way of saying that
if we had the means of being able to externally and programmatically
control GC policy, or to compose it with existing
GC policies available from the JVM (by means of "stitching"), we may be
able to tune GC to fit more diverse needs.

Anyway that is the rather grandiose and perhaps a tad quixotic proposal.
Comments, flames, feedback etc. welcome.

I'll have a smaller, more concrete and small bug report to call in, wrt
what seems to be a case where the
adaptive sizing policy seems to get stuck in a highly suboptimal state. I
think it has a fix that is small and
simple, and should be generally useful everywhere. In the interests of not
putting too many different
things into the same email, I will defer that to another email that I will
send after a while.

thanks.
-- ramki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121219/bb4aab34/attachment.htm>