Memory system questions
Juergen Boemmels
While reworking the IO-system I get deeper in the memory system than I
wanted to. So I have some questions:
* Is there a way to trace only a part of the rootset? pobject_lives
only adds an element to the root-set. But creation of the rootset
and tracing of PMCs are done (as far as I can see) in only one
function: trace_active_PMCs.
* The root set is a linked list with an circular end. The end of this
list is stored in the interpreter structure interprerter->mark_ptr,
the start of the list is a local variable in trace_active_PMCs.
Whats the reason for this choices? (Especially why is this list not
NULL-terminated)
* How can I alloc a fixed amount of garbage collected memory, which
can be shared be more than one PMCs.
io = (Buffer*)(pmc->ext->data)->obj.u.b.bufstart
are IMHO far to many indirections. There must be a shorter way.
* Should the standard-filedescriptors be timely destructed?
If they are this makes the whole sweep 0/1 thing useless because
there are always timely-destructing objects. Otherwise why are the
standard-filedescriptors special.
Yes I have read docs memory-internals.pod
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Dan Sugalski
>* Is there a way to trace only a part of the rootset? pobject_lives
> only adds an element to the root-set. But creation of the rootset
> and tracing of PMCs are done (as far as I can see) in only one
> function: trace_active_PMCs.
Not at the moment. I think we could use that functionality, though,
since we could use it to build the destruct tree for dead
>* The root set is a linked list with an circular end. The end of this
> list is stored in the interpreter structure interprerter->mark_ptr,
> the start of the list is a local variable in trace_active_PMCs.
> Whats the reason for this choices? (Especially why is this list not
> NULL-terminated)
Interesting. It was originally a singly-linked list, though as the
DOD run's concerned it doesn't much matter.
>* How can I alloc a fixed amount of garbage collected memory, which
> can be shared be more than one PMCs.
> io = (Buffer*)(pmc->ext->data)->obj.u.b.bufstart
> are IMHO far to many indirections. There must be a shorter way.
Writable or just readable? If it's readable you can COW-clone the
buffer data. If writable, then we need to put that functionality in
if you need it.
>* Should the standard-filedescriptors be timely destructed?
No. I don't think any filehandle should be marked timely on its
creation--if a language determines that a filehandle should be timely
destructed it ought to mark it just before leaving scope so it can be
cleaned up as part of the scope exit if the thing does go out of
scope. (And I'm not sure that normal filehandles should be marked
even then, but we'll probably do that at least in the perl compiler)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> Hello,
> * How can I alloc a fixed amount of garbage collected memory, which
> can be shared be more than one PMCs.
> io = (Buffer*)(pmc->ext->data)->obj.u.b.bufstart
> are IMHO far to many indirections. There must be a shorter way.
Yep. I'd like to have custom PMC_EXT structures derived from
buffer-likes. This could save 2 indirections above.
Dan and /me discussed that briefly in Paris, his answer was "no
(not currently)".
> boe
leo
Juergen Boemmels
> Juergen Boemmels <boem...@physik.uni-kl.de> wrote:
> > Hello,
>
> > * How can I alloc a fixed amount of garbage collected memory, which
> > can be shared be more than one PMCs.
> > io = (Buffer*)(pmc->ext->data)->obj.u.b.bufstart
> > are IMHO far to many indirections. There must be a shorter way.
>
> Yep. I'd like to have custom PMC_EXT structures derived from
> buffer-likes. This could save 2 indirections above.
I thought of something like that. But deriving from buffer-likes?
PMC_EXT isnt derived from bufferlikes either.
So how is this PMC_EXT supposed to work?
> Dan and /me discussed that briefly in Paris, his answer was "no
> (not currently)".
Ok.
bye