Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Whiteknight (8626)

  (email not shown publicly)
http://en.wikibo ... User:Whiteknight
AOL IM: wknight8111 (Add Buddy, Send Message)

My name's Andrew. I'm an open-content advocate at I'm also involved with Parrot as a semi-competent C hacker. This blog is going to be a forum where I can ramble about minutia and post information about perl-world stuff that I care about.

Journal of Whiteknight (8626)

Thursday May 29, 2008
06:08 PM

Getting my mind right

[ #36546 ]

One reason why I love writing, both in blogs and on Wikibooks, is because it forces me to really understand things. Having to put a concept into actual words, my own words, requires that I have a concrete understanding of that concept. My previous blog entry is a case in point: I wrote a post that didn't make a whole lot of sense, there were some comments, I posted some replies, and in the process I developed a much firmer picture of this whole GC project.

A lot of my misunderstanding stems from terminology problems. Here's an example: In parrot there is a data structure called "Arenas" which maintains pointers to all the pools. "Pools" are memory areas from which allocations can be made, and are typically defined by the data structure "Small_Object_Pool". Each pool contains a specific type of thing, typically with uniform size. There are 6 pools for objects: PMCs, Constant PMCs, Extended PMCs, Buffer headers, String headers, and constant string headers. The Arenas structure also contains a few GC-related function pointers, and some data items that can be used by the GC.

Small_Object_Pool objects contain pointers to a data structure called a Small_Object_Arena, which is used to demarcate sections of the pool (for what ultimate purpose, however, I am not sure). The Small_Object_Pool also contains pointers to Memory_Pool objects, which are the low-level storage implementations.

So when we talk about "Arenas", it's not immediately clear whether we mean "struct Arenas" or "struct Small_Object_Arena". When we say "Pool", it's not immediately obvious whether we mean a Small_Object_Pool or a Memory_Pool. When we talk about headers, we could mean "Gc_it_hdr" (from the garbage collector) or buffer headers, or PMC headers. See the confusion?

The GC operates per-pool, or pool-at-a-time (I'm treating the two as equivalent terms). When we need new PMC headers, we scan through the PMC pool. When we need new buffer headers, we scan that pool instead. Each pool, since it represents a distinct situation for the GC, gets it's own GC-related structures: generations, cardmarking bitmaps, etc. I'm having to redo all the data structures that I had created previously to follow these relationships.

The allocators that I have to write are also written per-pool, although other GCs have reused code for these and I'm going to do the same. I want to get those knocked out tonight or tomorrow, and I don't see any major impediments to that.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Small_Object_Pool objects contain pointers to a data structure called a Small_Object_Arena, which is used to demarcate sections of the pool (for what ultimate purpose, however, I am not sure).

    A pool contains a linked list of arenas so that we can allocate or deallocate an arena at a time rather than reallocating a pool at a time.

    I'm never sure how much to explain for everyone else following along, but I like to err on the side of verbosity.

    All of our GCable entities ultimately come out of arenas. A

    • I had actually figured out what the Small_Object_Arena structure was used for after I had written my post. I probably could have posted an addendum or something to explain it.

      Parrot, as a matter of brilliance, doesn't call malloc for every single bit of memory it needs: instead, it allocates memory in large-ish chunks with the intent that those chunks store precisely n objects of size m, as chromatic mentioned. Doing things this way, reducing the number of memory transactions and speculating on future memor
      Andrew Whitworth