On Sat, Oct 05, 2002 at 09:21:47AM +0000, Leopold Toetsch wrote:
> Attached docu is for review and might also go in.
> Suggestions, bugfixes, comments welcome.
I don't know enough about the technical specifics of parrot to find bugs
in your descriptions. It's a good document, thanks.
I did have some suggestions, which I fear may look like I'm ripping it to
shreds. That's not the intention - it's just that I found several places
where I thought I could see a wording change that could make the intent
clearer.
> +Objects in all pools not alive are considered dead therefore.
I find the order of that sentence slightly confusing - therefore is quite
an important word, yet it's the end (just like a perl5 regexp flag).
I'm not sure which of these I find clearer:
Objects in all pools not alive are therefore considered dead.
Therefore objects in all pools not alive are considered dead.
> +I<Memory_pool> and I<header_pool> are variable and fixed sized pool
> +pointers respectively.
Likewise, I find that I reach "respectively" at the end of that sentence and
have to scan back over it to re-comprehend it
I<Memory_pool> and I<header_pool> are respectively variable and fixed sized
pool pointers.
> +Buffer_like object's of the same size are maintained in the
x
whoops! escaped apostrophe.
Arguably the earlier one in I<Small_Object_Arena>'s is also wrong
> +All fixed sized objects are allocated with alloc_objects(), and first put
> +onto the pool's free_list. When there is need for a new object it's taken
> +off the free_list and when it's unused (detected during a DOD run), it
> +will be put back on the free list again.
> +
> +If the free_list is empty, first a DOD run is started, which may put
> +dead objects there, or if not, a new pool is allocated to hold more
> +objects.
I'd pull the bit out of the brackets and make it into a new sentence.
Currently I was a bit unsure about what was going on. I think I'd write it as
All fixed sized objects are allocated with alloc_objects(), and first put
onto the pool's free_list. When there is need for a new object it is taken
off the free_list, and when it stops being used it will be put back on the
free list again. DOD runs detect which objects are no longer being used.
I'm trying hard not to use the verb "used" twice, in two different contexts;
firstly to describe the state of the objects themselves, and secondly to
describe the purpose of the DOD run.
If the free_list is empty then a DOD run is started, which may be able
to refill the free_list with dead objects it detects are free for re-use.
If it finds none then a new pool is allocated to hold more objects.
> +Here, different memory allocation scemes jump in:
schemes?
> +this memory block, a garbage collections (GC) is started. This copies all
garbage collection (singular) ?
> +living items of all used memory blocks into one new block, which holds
by living I assume you mean in use, as we're using "dead" and "not in use"
interchangeably. However, this is the first time you've described in use
objects as living. Maybe "living" and "dead" need to go into the glossary,
plus a definition of how we determine if an object is dead.
(by it not being "in use", where we know that we can reach an in-use object
from our "root set", which we also ought to define)
> +An alternative to above is, to use a memory allocator, which is as fast
> +as above and does resuse free()ed items in a memory conserving way.
> +Actually I<libc> provides this, based on Lea's allocator, and parrot
> +includes one, for systems not having such a nice feature.
Not all the world is Linux. Maybe that would be better phrased as
Actually, the malloc implementations in some systems' I<libc> efficiently
provide this, such as the glibc malloc based on Doug Lea's allocator.
I've always seen him referred to as Doug Lea, never just Lea. I don't know why.
> +Using this allocator, all variable sized items are just allocated via a
> +plain malloc() call, or resized with realloc(), and after they lost
> +there existence, this is, when DOD detected, that the managing buffer
lose their?
> +header is not used anymore, they are free()ed. That's all. The
> +underlaying allocator collect's this pieces, does coalesce them to bigger
> +parts - if possible, keeps them on free lists, sorted by their sizes, and
> +when a new malloc() arrives, eventually gives them back to parrot.
underlying allocator collects these pieces, where possible coalesces them
to form bigger pieces, and then puts them on free lists, sorted by their
sizes. Eventually, when a new malloc() arrives, it gives them back to
parrot.
> +Now, during GC (or freeing buffers) the problem arises: to whome belongs
> +this string. You shouldn't copy the same string to different places,
Now, during GC (or freeing buffers) the problem arises: to whom does this
string belong?
> +The malloc()/free() approach stores a usage flag there. Only if all
> +users of this string are dead, one and only one buffer header using this
> +string, is allowed to free this string. And additionally this header is
string is allowed to free this string.
You use commas more frequently than I would. That's the first where I found it
actually confused me. (In this case, sufficiently that I thought that there
was an word missing from the last clause of the sentence, and had to re-read
it twice)
> +All spelling errors belong to those, who honestly collected them, as well as
> +all errors related to my abuse of the English language - I'm not natively
> +speaking it.
> +
> +To minimize this bugs section - please patch this document and keep it
> +up to date - thanks.
Oops. Does that mean I should have just committed it, and then committed my
suggested changes?
> +Leopold T?tsch <[EMAIL PROTECTED]>
Erk. What did my mailer do. The raw message is:
-- attachment 1 ------------------------------------------------------
url: http://rt.perl.org/rt2/attach/39249/31851/1c9a63/memory_internals_pod.patch
------------=_1033809707-24225-0
Content-Type: text/plain; name="memory_internals_pod.patch"
Content-Disposition: inline; filename="memory_internals_pod.patch"
Content-Transfer-Encoding: base64
Content-Description: memory_internals_pod.patch
It seems that RT doesn't specify an encoding on its attachments, and my
copy of mutt takes a rather conservative view about what they might be.
I presume that that should be Leopold Tötsch
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
