What influences young generation pause times?

[Tony Printezis]

Osvaldo,

Osvaldo Doederlein wrote:
>
>     Regarding calling young GCs explicitly from an application: I can
>     see how, in the case of single-threaded applications, the
>     application might know "We are between transactions and, maybe, we
>     have lots of garbage and not much live in the young gen. So let's
>     do a young GC to clean up the young gen at maybe low overhead
>     since we'll copy very little." However, how will this work in the
>     case of multi-threaded applications, which are the vast majority
>     of applications we see from our customers? A thread might be
>     between transactions, but what about the other 50, 300, or even
>     2,000 threads? If a particular time is good to do a young GC 
>
>
> Not all multithreaded apps are heavily multithreaded; for each mammoth 
> website with 2000 concurrent transactions, you'll find a thousand 
> corporate apps with peaks of 5 concurrent transactions and very 
> frequent full-idle periods. Well, admittedly for these apps, cutting 
> the cost of young-GCs copying is irrelevant;
:-)
> it's the former, larger apps that need it. I guess at least my 
> speculation about (big) TLAB collection is valid?
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.
> And what about the large number of non-EE apps - remarkably 
> media-heavy / RIA / games, which are typically 
> "almost-single-threaded" = event dispatch thread plus two or three 
> application threads, typically tightly controlled (so it's trivial and 
> cheap to force all these threads to stop in a barrier when you want to 
> clean up).
I haven't talked to many customers who will be willing to introduce 
their own safepoints in their Java code.
> These apps are often very sensitive to latency: a stop-the-world 50ms 
> pause at the wrong time are sufficient to result in visible or audible 
> stuttering.
>
> [Java GC should not care only for the Enterprise side. If you peek 
> into some dev communities - e.g. javagaming.org 
> <http://javagaming.org> - people are always whining about insufficient 
> control over GC behavior. What we want is something like RTSJ's scoped 
> heaps - you "enter" some execution phase, allocate lots of Young 
> objects, then you "leave" this phase and request GC that will be 
> basically free - but of course, we need something that works in the 
> JavaSE and JavaME platforms, without the complexities and mutator 
> costs of RTSJ.]
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.

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". ;-)
>  
>
>     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

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use