Tony,<br><br><div class="gmail_quote">2010/4/21 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;">


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.</blockquote>


<div><br>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.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>


</blockquote><div><br>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.)<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;">

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


<div><br>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. <br>
<br>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.<br>


<br>A+<br>Osvaldo<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
 <br>
    for a particular thread, it does not mean that it's also good for<br>
    the rest. Additionally, I would be willing to bet money that if we<br>
    provided such an API, library writers will abuse it thinking that<br>
    "hey, the end of this library call will be a great time to do a<br>
    young GC!", without taking into consideration that many other<br>
    threads could be doing something totally different at the same<br>
    time (we've seen way too many libraries that call System.gc()<br>
    already...).<br>
<br>
<br>
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. :)<br>



</blockquote></div>
On the contrary, our mission is to prevent developers from shooting themselves in the foot. :-)<br><font color="#888888">
<br>
Tony<br>
<br>
</font></blockquote></div><br>