develooper Front page | perl.perl6.internals | Postings from May 2002

[netlabs #629] [PATCH] Memory manager/garbage collector - major revision

From:
Peter Gibbs
Date:
May 27, 2002 09:33
Subject:
[netlabs #629] [PATCH] Memory manager/garbage collector - major revision
Message ID:
rt-629-2861.2.51493167132139@netlabs
# New Ticket Created by  "Peter Gibbs" 
# Please include the string:  [netlabs #629]
# in the subject line of all future correspondence about this issue. 
# <URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=629 >


Attached patch does some fairly radical things to the memory manager.

1) Cycle counter added to interpreter structure; incremented by opcodes that
have something vaguely resembling a function call in their body.
2) Buffer-like objects have their date of birth (cycle counter value)
recorded
3) Neonate flag is deprecated; functionality replaced by the above i.e. no
buffer
header will be freed during the same opcode as it was created
4) Free pool array replaced by a linked list within the arenas
5) Minimum/maximum ratio of memory pool physical size to used size
controlled
by new tuning parameters (fixed #define's for now)
6) DOD run performed during memory allocation if compaction will not reclaim
enough memory

The 'function-call like' logic (which is very primitive at present) for
adding the
cycle count increment into an op's body means that most simple opcodes
should not incur additional overhead. Once an op starts calling functions,
the
additional overhead of a single increment is likely to be minor.
After much thought and playing around, this seems to be the best answer to
the problem of infant mortality. Dan's suggestion of reversing the logic of
DOD
runs would work for the pure infant mortality situation (except perhaps for
the odd
pathological op), but it still leaves problems with the dependency of buffer
memory collection on prior dead object detection.
These changes do cause a slight performance degradation, but I believe it is
worth it for the overall simplification of transparent protection of the
newborn.
Performance can only be a secondary goal, after correct behaviour.

The runaway memory usage of programs like zip and quicksort has hopefully
been resolved; I have successfully run zip.pasm against core_ops.c.

Note that the neonate flag has not been removed; if this patch is applied,
all
use of the neonate flag can be removed, followed by the flag itself. The
flag is
not used in the new GC logic.

The problem of having buffer memory move around still remains; that should
be
addressed shortly.

--
Peter Gibbs
EmKel Systems




nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About