<br><br><div class="gmail_quote">On Tue, Nov 30, 2010 at 6:38 PM, Andres Valloud <span dir="ltr"><<a href="mailto:avalloud@smalltalk.comcastbiz.net">avalloud@smalltalk.comcastbiz.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Awesome, thank you! That makes the "marker technique" more clear. In HPS parlance (excuse me using the terminology I am most familiar with), Squeak has an eden plus two survivor semi spaces, and old space for the rest. The incremental GC would be a scavenge of new space. The full GC is a mark / sweep GC of all object data. Does that make sense?<br>
</blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Also, would you mind a question? If the new objects are above the old data, what happens when the old data grows large enough that it runs into the new object space? Is the new object space moved upwards?</blockquote>
<div><br></div><div>Think of the heap (including new space) as one region growing towards a limit. Old space is immediately below new space, a single variable pointing to the boundary. Somewhere above that is the allocation pointer. When one does a tenuring incremental collection new space is compacted and the pointer to the top of old space merely set to point to teh allocation pointer, so now everything is old. By the same token, to do a full gc the old space pointer is merely set to the bottom of the heap, so now everything is young, and the roots are the active context and the special objects array. </div>
<div> </div><div>Unlinke HPS there is no such thing as an old space allocation, because there is no free list of free old space objects, and because old space and new space are contiguous. Hence a large allocation will typically tenure everything.</div>
<div><br></div><div>Make sense?</div><div><br></div><div>best</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><br>
<br>
On 11/30/10 16:20 , Andreas Raab wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
<a href="http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/Rowledge-Final.pdf" target="_blank">http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/Rowledge-Final.pdf</a><br>
<br>
On pp. 20 it has an excellent summary about how the Squeak GC works.<br>
<br>
Cheers,<br>
- Andreas<br>
<br>
On 11/30/2010 4:13 PM, Andres Valloud wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, from what I've seen, Squeak's GC is different from that in HPS. I<br>
found some information scattered here and there in Google, but it's<br>
mostly commentary. Ideally, I'd look at the source code and figure it<br>
out but I don't quite have the time to look at it in all its detail. I<br>
would really appreciate a current, 3-5 sentence summary of Squeak's GC<br>
implementation. Does anyone have such a pointer? I hope this request is<br>
not deemed ridiculous, I'm thinking it would be just as unreasonable to<br>
expect anybody to look at HPS' GC implementation and get the gist of<br>
what's going on in 5-10 minutes. Thanks in advance!<br>
<br>
On 11/27/10 14:06 , Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Fri, Nov 26, 2010 at 9:15 AM, Andres Valloud<br>
<<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.comcastbiz.net</a><br>
<mailto:<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.comcastbiz.net</a>>> wrote:<br>
<br>
I'm not familiar with Squeak's GC... can you also assume that a GC<br>
(e.g.: a "new space" scavenge) won't move the marker so that the<br>
enumeration goes past it?<br>
<br>
<br>
IIUC, that's irrelevant. FOr the marker technique to work all that's<br>
needed is that the relative order of live objects isn't changed. The<br>
only thing that can change that is a become:. In the absence of a<br>
become: the end marker, no matter how many GCs occur, stays above/after<br>
all previously activated objects and below/before all subsequently<br>
allocated objects. The Squeak GC effectively only compacts to squeeze<br>
out reclaimed objects, it does not reorder. So this is very different<br>
to the VM/HPS GC.<br>
<br>
HTH<br>
Eliot<br>
<br>
<br>
<br>
On 11/26/10 9:12 , Bert Freudenberg wrote:<br>
<br>
<br>
On 26.11.2010, at 18:09, Andres Valloud wrote:<br>
<br>
Can you assume that allocation is sequential?<br>
<br>
<br>
I can.<br>
<br>
- Bert -<br>
<br>
On 11/26/10 8:59 , Bert Freudenberg wrote:<br>
<br>
<br>
On 26.11.2010, at 17:43, Andres Valloud wrote:<br>
<br>
You *must* use an end marker, i.e.,<br>
<br>
last := Object new. "end marker"<br>
obj := self someObject.<br>
[last == obj] whileFalse:[<br>
count := count + 1.<br>
obj := obj nextObject.<br>
].<br>
<br>
This will work because it counts between the<br>
beginning of memory and the<br>
(arbitrary) end marker. Anything else basically<br>
should not be relied on<br>
to work, jit or no.<br>
<br>
<br>
What happens if a process with higher priority<br>
interrupts the iteration and creates more objects?<br>
<br>
<br>
New objects would come after the end marker in memory.<br>
<br>
- Bert -<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br></div></div>
.<br>
<br>
</blockquote>
<br>
</blockquote></div><br>