If you allow some intermission... is the young-gen collector smart enough to avoid semispace copying in some favorable conditions? Let's say I am lucky and when young-GC is triggered, after marking I have [LLLLLLLLLLDDDD] where L=live objects, D=dead. it's stupid to copy the block [LLLLLLLLLL] to another space. I'd expect the collector to have some heuristic like: look at the top address and total size of the remaining live data, and if it is densely populated (say >90% live space - e.g. [LLLDLLLLLLDDDD]), just finish GC without any compaction or semispace flipping.<br>
<br>I would expect this scenario to happen in the real world with very small frequency, because young-GC must be triggered at a "lucky" time, e.g. after some application transactions commit and before any newer transaction begins - but if the collector already accounts the live set size at the marking phase, the cost to attempt this new optimization is virtually zero. And we might hint the VM to make sure the optimal case doesn't depend on good luck. The JVM could expose an API that allows an application (or a container) to request a "lightweight GC", i.e., perform only young-GC, and only if the young-gen is >N% full. E.g., System.fastGC(0.8) for N=80%. A JavaEE application server could invoke this when it detects idle periods (zero running transactions / zero background processes doing anything important); or even after every transaction commit if the VM uses TLABs (in that case we only collect the TLAB; the whole thing only makes sense for large enough TLABs). For single-threaded processes (Ok, almost-single-threaded...) it's much simpler, just call the lightweight-GC API at special places where major activity ends and tons of allocated data are liberated, e.g. after the render-frame step of your game loop, or after importing each file in your batch ETL program, etc.<br>
<br>A+<br>Osvaldo<br><br><div class="gmail_quote">2010/4/20 Matt Khan <span dir="ltr"><<a href="mailto:matt.khan@db.com">matt.khan@db.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Tony<br>
<br>
>> Basically, the more objects survive the collection and need to be<br>
copied, the higher the young GC times will be.<br>
so when does a concurrent collector enter a STW pause?<br>
<br>
for example if I look at figure 6, p10 in the memory management white<br>
paper (<a href="http://java.sun.com/products/hotspot/whitepaper.html" target="_blank">http://java.sun.com/products/hotspot/whitepaper.html</a>) then that<br>
makes it look like there is a single STW pause per young collection that<br>
is made shorter because there are n threads doing the work. Is that an<br>
accurate depiction of when it pauses or just a convenient visualisation?<br>
<br>
My reason for asking is that my app doesn't exhibit this single pause per<br>
young collection, instead I see a succession of short pauses between GC<br>
logs (example below) & I'd like to understand what causes those pauses.<br>
This app is using CMS (params used below) but there is no CMS activity<br>
reported at this time because v little enters the tenured generation and<br>
hence there is no collection required.<br>
<br>
Total time for which application threads were stopped: 0.0051359 seconds<br>
Application time: 99.9576332 seconds<br>
2010-04-13T19:14:53.185+0000: 368542.855: [GC 368542.855: [ParNew<br>
Desired survivor size 14450688 bytes, new threshold 1 (max 1)<br>
- age 1: 3377144 bytes, 3377144 total<br>
: 2986668K->4491K(2998976K), 0.0254753 secs] 3076724K->94963K(3130048K)<br>
icms_dc=0 , 0.0259072 secs] [Time<br>
s: user=0.25 sys=0.01, real=0.03 secs]<br>
Total time for which application threads were stopped: 0.0330759 seconds<br>
Application time: 190.7387185 seconds<br>
Total time for which application threads were stopped: 0.0060798 seconds<br>
Application time: 9.2698867 seconds<br>
Total time for which application threads were stopped: 0.0051861 seconds<br>
Application time: 290.7195886 seconds<br>
Total time for which application threads were stopped: 0.0065455 seconds<br>
Application time: 9.2792321 seconds<br>
Total time for which application threads were stopped: 0.0051541 seconds<br>
Application time: 290.7292153 seconds<br>
Total time for which application threads were stopped: 0.0063071 seconds<br>
Application time: 9.2696694 seconds<br>
Total time for which application threads were stopped: 0.0052036 seconds<br>
Application time: 290.7093779 seconds<br>
Total time for which application threads were stopped: 0.0065365 seconds<br>
Application time: 9.2793591 seconds<br>
Total time for which application threads were stopped: 0.0051265 seconds<br>
Application time: 290.7301471 seconds<br>
Total time for which application threads were stopped: 0.0070431 seconds<br>
Application time: 9.2694376 seconds<br>
Total time for which application threads were stopped: 0.0051428 seconds<br>
Application time: 119.4074368 seconds<br>
Total time for which application threads were stopped: 0.0059739 seconds<br>
Application time: 39.8647697 seconds<br>
2010-04-13T19:40:52.550+0000: 370102.218: [GC 370102.219: [ParNew<br>
Desired survivor size 14450688 bytes, new threshold 1 (max 1)<br>
- age 1: 2911824 bytes, 2911824 total<br>
<br>
-Xms3072m<br>
-Xmx3072m<br>
-Xmn2944m<br>
-XX:+DisableExplicitGC<br>
-XX:+PrintGCDetails<br>
-XX:+PrintGCDateStamps<br>
-XX:+PrintGCApplicationStoppedTime<br>
-XX:+PrintGCApplicationConcurrentTime<br>
-XX:MaxTenuringThreshold=1<br>
-XX:SurvivorRatio=190<br>
-XX:TargetSurvivorRatio=90<br>
-XX:+UseConcMarkSweepGC<br>
-XX:+UseParNewGC<br>
<br>
Cheers<br>
Matt<br>
<br>
Matt Khan<br>
--------------------------------------------------<br>
GFFX Auto Trading<br>
Deutsche Bank, London<br>
<br>
<br>
<br>
---<br>
<br>
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.<br>
<br>
Please refer to <a href="http://www.db.com/en/content/eu_disclosures.htm" target="_blank">http://www.db.com/en/content/eu_disclosures.htm</a> for additional EU corporate and regulatory disclosures.<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
<a href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
<a href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use" target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
</blockquote></div><br>