What influences young generation pause times?

[Osvaldo Doederlein]

Tony,

2010/4/21 Tony Printezis <tony.printezis at oracle.com>

> I'm not quite sure what you mean by big TLAB collection. You mean to
> collect just the TLABs of a thread. You really cannot do that without
> scanning the entire young gen to find all the references into them.


I didn't know that, I was supposing that the TLAB would have a remset for
incoming references from the rest of the young gen.


> Let's assume you want to use something like RTSJ's scopes (and let's say
> they are simplified and assume only one thread will enter them, which
> removes a lot of the complexity associated with RTSJ's scopes). Then the
> only way to be able to reclaim a scope when you leave it is to ensure that
> there are no references from outside the scope into it. You can ensure that
> this is the case by introducing write barriers and throwing an exception if
> such a reference is created (which is what the RTSJ does), but now a lot of
> the existing code won't work correctly with this restriction. So, you just
> cannot do what you're proposing without some extra costs.
>

To make my suggestion more clear, the intention is just enabling something
similar to RTSJ. While "inside" some scope, the program can introduce
references from old to new objects, as long as these refs are all cleared
when "exiting" the scope. By "request GC that will be basically free" I
didn't mean something identical to RTSJ (free() a whole heap block), but
only trigger the young-GC -- at that time, all those young objects are
unreachable. Except perhaps a few objects that existed before entering the
scope - not a problem, they are all compacted in the beginning of the YG, so
young-GC will be only slightly slower than for zero live objects, no big
deal. (I'm also not wishing for real-time GC guarantees like in RTSJ.)



> We have been working on, and thinking about GC, for a long time. Trust me,
> if there was a way to do cheaply what you're proposing, we would have done
> it a long time ago. With the semantics of Java it's not straightforward.
> And, after many years of doing this stuff, I can also assure you that
> nothing in GC it's "free". ;-)


I certainly believe this - I'm not suggesting anything that would be really
free. In all suggestions I would expect some hit in overall throughput
(thread-local young gens would have this cost because we potentially
increase the working set, so reduced cache efficiency alone should more than
offset the cycles saved in GC). In other cases - fine-grained explicit GC
API + strict threading/allocation behavior required for near-instant young
GC - the cost is programming complexity. These costs would be fine for a
great many apps.

Let's put it differently: why not adding a simple API like I suggested
(trigger only young-GC, perhaps with a parameter to only do that if the
young gen has less than some % of free space)? I'd expect this to be trivial
to implement. Maybe we could have this in some sun.* package, and only in
non-release builds for extra protection. Let people kick the tires and give
you feedback - whether this produces significant benefits for some apps.

A+
Osvaldo


>
>
>>    for a particular thread, it does not mean that it's also good for
>>    the rest. Additionally, I would be willing to bet money that if we
>>    provided such an API, library writers will abuse it thinking that
>>    "hey, the end of this library call will be a great time to do a
>>    young GC!", without taking into consideration that many other
>>    threads could be doing something totally different at the same
>>    time (we've seen way too many libraries that call System.gc()
>>    already...).
>>
>>
>> This is true, but I guess the problem could be handled by the Security
>> manager and/or VM options, maybe allowing only certain packages to induce GC
>> in any way. There is precedent for that (-XX:+DisableExplicitGC, and default
>> configuration of app servers to use that option). The problem exisits but
>> it's not new in any "lightweight GC API" proposal - even to current date I
>> sometimes find some app code that invokes Good Old System.gc(). Please let's
>> not use the "developers will shoot themselves in the foot" argument, to not
>> provide a solution for a very painful problem. :)
>>
> On the contrary, our mission is to prevent developers from shooting
> themselves in the foot. :-)
>
> Tony
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20100421/9432d250/attachment.html