<br>Hello Kirk --<br><br><div class="gmail_quote">On Thu, Dec 6, 2012 at 2:38 PM, Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br></div>
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.<br>

<br>
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.<br>
><br><br></blockquote><div><br>Please do.<br><br>I'll use this email as a segue into something that has been batted about casually by the HotSpot GC folks in the past,<br>but which I now as a consumer of HotSpot GC see as possibly having some value.<br>
<br>The rationale/motivation is really quite easy to illustrate and will be easily understood and appreciated by both<br>GC developers and by GC users. May applications behave differently during boot-up time and then during actual<br>
operation. A perfect, perhaps oracular (pun not intended! ;-) adaptive size policy would hit optimal settings in both<br>phases quickly and yield good behaviour throughout. But as we all know there's a tradeoff between agility and<br>
over-reaction, so we carefully try and tread a middle ground that tries to react in an agile fashion to changes in<br>the application behaviour, but does not oscillate unnecessarily by reacting to small amounts of noise or spikes<br>
in sensor data.<br><br>Now, we have a number of knobs, many of them associated with adaptive sizing policy, that are available as<br>product flags for tweaking via the JVM command-line. Some of these, however, are such that one might benefit by<br>
being able to dynamically tweak them, based on the application's domain-specific knowledge of its environment<br>or seasonality or diurnality of its load etc. As an illustration, there may be useful things that a collection of<br>
servers in a data-centric environment might do, based on their collective view of the load at the application level,<br>which a single JVM might not be able to do because it lacks this kind of more globally distributed information.<br>
Also, one might be able to drive interesting data-centric control of server gangs via being able to externally and<br>dynamically tweaking their individual and, by composition, their collective behaviour. In other words, if we were to<br>
expose external APIs for dynamically tuning some of these settings, we might be able to perhaps (and note, I say, perhaps)<br>more optimally control GC behaviour. But it seems as though if a JVM option flag is "manageable", one can already<br>
use the GC mxbean interfaces to change these values. The limitation may be our ability to synchronously change<br>an entire vector of control parameters or, even better, to provide an advance schedule or, even better, an intelligent<br>
schedule (aka a control program) for their synchronous management. This is just another way of saying that<br>if we had the means of being able to externally and programmatically control GC policy, or to compose it with existing<br>
GC policies available from the JVM (by means of "stitching"), we may be able to tune GC to fit more diverse needs.<br><br>Anyway that is the rather grandiose and perhaps a tad quixotic proposal. Comments, flames, feedback etc. welcome.<br>
<br>I'll have a smaller, more concrete and small bug report to call in, wrt what seems to be a case where the<br>adaptive sizing policy seems to get stuck in a highly suboptimal state. I think it has a fix that is small and<br>
simple, and should be generally useful everywhere. In the interests of not putting too many different<br>things into the same email, I will defer that to another email that I will send after a while.<br><br>thanks.<br>-- ramki<br>
</div></div>