What influences young generation pause times?

[Osvaldo Doederlein]

Hi Tony,

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

> 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 --
> Here you are assuming that what you're referring to as a "young GC" will
> only touch the objects that just got allocated by that thread (and there'd
> be extra costs associated with ensuring that). Or did you really mean an
> actual young GC? Again, in the single-threaded case, this might work. It
> won't in the multi-threaded case: if each thread that completes a
> transaction triggers a young GC, then the system will be overwhelmed by
> young GCs.
>

I'm not ignoring the cost of marking - the discussion started because
copying alone can be a significant fraction of the total cost of
generational GC. If the young-gen is basically empty of live objects, I
think we have significant speedup compared to an average young-GC (that
doesn't necessarily happen in the "perfect" time, with lots of live young
objects). But I see now that the idea doesn't work at all for nontrivial
multithreaded apps.


>  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.
>>
> As I said, there's nothing "free" in GC. If you copy all the objects (as we
> do now), you have to copy the ones that existed when you entered the scope
> anyway. If you introduce a way to only copy the survivors of the objects
> that were created from inside the scope, you'd still have to scan the ones
> you didn't copy to find and update references to the objects you're moving.
> If you don't want to scan them, you'd have to maintain remembered sets. You
> might think that implementing something like what you're proposing is simple
> but, really, it's not.
>

My assumption here is that the old generation is very stable - the program
loops in a cycle of phases that create lots of new objects, then in the end
of each cycle virtually all these objects die, they are collected, goto next
cycle. Any objects that you may have in the YG initially (before the program
stabilizes in such loop) would be promoted to the old gen after a few
collections. The app developer would measure the worst-case allocation
volume for each cycle, and size the young-gen so that volume fits.



> 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.
>>
>
> It will definitely not be complicated 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.
>>
> There are no plans to do this at the moment. In all honesty, we all have
> our hands full right now and such an API would be low in our (very long)
> priority list.
>

 This looks like an interesting OpenJDK experiment. Maybe I should find some
time to write a patch, then test a couple apps that I think that would
benefit from the idea.

A+
Osvaldo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20100423/bf64a639/attachment.html