[squeak-dev] 30 bit unboxed floats

Igor Stasenko siguctua at gmail.com
Tue Oct 19 23:03:52 UTC 2010


Btw, about GC:

http://lambda-the-ultimate.org/node/2391

Garbage Collection without Paging, Matthew Hertz, Yi Feng, Emery D.
Berger. PLDI 2005

    Garbage collection offers numerous software engineering
advantages, but interacts poorly with virtual memory managers.
Existing garbage collectors require far more pages than the
application’s working set and touch pages without regard to which ones
are in memory, especially during full-heap garbage collection. The
resulting paging can cause throughput to plummet and pause times to
spike up to seconds or even minutes.We present a garbage collector
that avoids paging. This bookmarking collector cooperates with the
virtual memory manager to guide its eviction decisions. Using summary
information (“bookmarks”) recorded from evicted pages, the collector
can perform in-memory full-heap collections. In the absence of memory
pressure, the bookmarking collector matches the throughput of the best
collector we tested while running in smaller heaps. In the face of
memory pressure, it improves throughput by up to a factor of five and
reduces pause times by up to a factor of 45 over the next best
collector. Compared to a collector that consistently provides high
throughput (generational mark-sweep), the bookmarking collector
reduces pause times by up to 218x and improves throughput by up to
41x. Bookmarking collection thus provides greater utilization of
available physical memory than other collectors while matching or
exceeding their throughput.



On 19 October 2010 20:54, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Mon, Oct 18, 2010 at 10:06 PM, Andres Valloud
> <avalloud at smalltalk.comcastbiz.net> wrote:
>>
>> I looked into this and from my quick impression, all pointers in reachable
>> object bodies will be written to twice by the algorithm. However, a stack
>> approach would only write such pointers once (copying them from the object
>> into the mark stack).  Doesn't that imply that the pointer reversal
>> algorithm is more memory intensive than a stack approach?
>
> Not necessarily more memory intensive, since it has better locality than a
> mark stack, but it is slower and harder to debug when it blows up in the
> middle since the reversed chain of pointers to the current point effectively
> corrupt the heap.  For these two reasons I won't be using pointer reversal
> in my new GC.
> best
> Eliot
>
>>
>> On 10/18/10 14:55 , Eliot Miranda wrote:
>>>
>>>
>>> On Mon, Oct 18, 2010 at 2:50 PM, Andres Valloud
>>> <avalloud at smalltalk.comcastbiz.net
>>> <mailto:avalloud at smalltalk.comcastbiz.net>> wrote:
>>>
>>>    On 10/18/10 10:31 , Jecel Assumpcao Jr. wrote:
>>>
>>>        We have had several discussions about the tags in Squeak.
>>>        xxxxxx1 is a
>>>        SmallInteger and xxxxxx00 is an object pointer, but xxxxxx10 is
>>> not
>>>        generally used.
>>>
>>>
>>>    How does the mark and sweep GC handle mark stack overflows?  Is
>>>    there a bit in the object header for that?
>>>
>>>
>>> The Squeak GC uses a pointer-reversal algorithm for marking and so is
>>> immune to mark stack overflow.
>>>
>>> cheers,
>>> Eliot
>>>
>>>
>>>    Andres.
>>>
>>>
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list