What influences young generation pause times?
Tony Printezis
tony.printezis at oracle.com
Wed Apr 21 23:27:02 UTC 2010
Raman Gupta wrote:
> 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.
Raman, if you want to cause a Full GC on your app while you have
+DisableExplicitGC, one of the things you can do is to call jmap
-histo:live <pid> on the JVM. The Full GCs initiated by the heap
inspection tools ignore +DisableExplicitGC. Not pretty, but it should
work... FWIW.
Tony
> Cheers,
> Raman
>
>
> On 04/21/2010 06:56 PM, Jon Masamitsu wrote:
>> Raman,
>>
>> Define this GC API for me. Where is the API (Java class)?
>>
>> Jon
>>
>> > 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.
>>>
>>> Cheers,
>>> Raman
More information about the hotspot-gc-dev
mailing list