Hi Tony,<br><br><div class="gmail_quote">2010/4/23 Tony Printezis <span dir="ltr"><<a href="mailto:tony.printezis@oracle.com" target="_blank">tony.printezis@oracle.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;">
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 --<br>
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.<br>
</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
</blockquote>
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.<br>
</blockquote><div><br>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.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
</blockquote><br>
It will definitely not be complicated to implement.<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
</blockquote>
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.<br></blockquote><div><br> 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.<br>
<br>A+<br>Osvaldo<br></div></div><br>