What influences young generation pause times?
rocketraman at fastmail.fm
Wed Apr 21 16:19:54 PDT 2010
I am not suggesting any new API at this time -- I mentioned it only as
a pie-in-the-sky kind of thing.
My current suggestion is simply to gate System.gc() (or actually
Runtime.gc() I guess) with a new RuntimePermission. Without the
appropriate permission granted, gc() would simply be a no-op.
That on its own would be very useful by allowing application code to
call System.gc() without worrying about rogue libraries also doing so
at inopportune times. Currently, I always run with
-XX:+DisableExplicitGC but that also prevents my app from scheduling it.
On 04/21/2010 06:56 PM, Jon Masamitsu wrote:
> Define this GC API for me. Where is the API (Java class)?
> > Without such permission, the System.gc() call would simply return
> without doing anything. Ideally the signature would be
> > modified to return a boolean "true if performed", "false if not", and
> even more ideally, a more comprehensive GC API could be
> > provided.
> On 04/21/10 15:36, Raman Gupta wrote:
>> On 04/21/2010 06:12 PM, Jon Masamitsu wrote:
>>> There is no shortage of good ideas for the GC team to work on.
>>> RuntimePermission might be another one, but the simple fact is
>>> that we don't have time to work on everything we should. Right
>>> now our top priorities are reliability, faster GC's and more
>>> predictable GC's. Anything else is a hard sell.
>> Thanks Jon.
>> I've never contributed to the JDK before, but I suspect that
>> implementing the first phase of this particular feature as I described
>> it would be very easy (basically just gate System.gc() with a new
>> RuntimePermission). But before I go spend hours trying to figure out
>> how to download and build the JDK, and contribute a patch, it would be
>> nice to know if it has a good chance of being accepted.
>> Note that this goes directly towards the goal of predictable GCs. For
>> example, one of my current server applications generally does one or
>> two full GCs daily. Currently, that full GC takes about 3-4 seconds,
>> but its timing is based solely on the size of the old gen, and is
>> completely unpredictable -- it could occur in the middle of the night
>> (good) or it could occur during peak time (bad). My solution would
>> allow my app to schedule the full GC overnight (subject to the
>> non-guaranteed constraints of System.gc, of course, but in practice
>> System.gc seems to pretty reliably kick off a full GC), with which the
>> app will almost certainly make it through the peak period without
>> another full GC occurring.
>> I do of course understand there would be significant work involved by
>> the GC team just to review and accept such a patch, so I completely
>> understand if the answer is no.
More information about the hotspot-gc-dev