Juergen Boemmels wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
[snip]
> > Except that generational_dod_helper is much simpler and faster -- it
> > doesn't mark anything as alive or free, it only adjusts the generation
> > of those pmcs that were created in C functions which we have sinc
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Actually, I meant generation set to MAX_INT, not 0.
>
> Marking pmcs as free happens at the end of DOD. Marking pmcs as live or
> dead happens earlier. I was thinking of something like:
>
>foreach(pmc in all_pmcs) {
...
>}
>fo
Having applied a bit more thought, having the generation field as part
of the PMC isn't all that great -- it makes PMCs larger, but it's really
only needed for new/neonate pmcs.
Instead of attatching the generation directly to the pmc, have a global
(per-interpreter) stack of neonate pmcs. Each
Juergen Boemmels wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> writes:
>
> > I was recently reading the following:
> >
> >http://www.parrotcode.org/docs/dev/infant.dev.html
> >
> > It's missing some things. One of which is the (currently used?) way
> > of preventing infant mortality: anch
At 3:28 PM +0200 8/4/03, Juergen Boemmels wrote:
I have the feeling that extending the signature of all
Parrot-functions will remove the need of walking the C-Stack
entirely. If this will be the linked list of frames or the generation
count is more or less a matter of taste: The generation count fo
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> I was recently reading the following:
>
>http://www.parrotcode.org/docs/dev/infant.dev.html
>
> It's missing some things. One of which is the (currently used?) way of
> preventing infant mortality: anchor right away, or else turn off DoD
> unt
At 1:46 PM +0100 1/9/03, Leopold Toetsch wrote:
Leopold Toetsch wrote:
Steve Fink wrote:
(3) propose something else that solves the whole problem neatly.
i.e. reorder code where possible, and anchor early,
RFC: changing the clone op functionality slightly:
Clone does in the first step p
Leopold Toetsch wrote:
Steve Fink wrote:
(3) propose something else that solves the whole problem neatly.
i.e. reorder code where possible, and anchor early,
RFC: changing the clone op functionality slightly:
Clone does in the first step pmc_new{,noinit} a PMC of the desired type.
This
Steve Fink wrote:
It's late here, but I'll try an answer ;-)
... I was thinking that it might be okay
to say that any single operation (even those that could conceivably
trigger many other operations) must fit all of its allocations within
the total amount of available memory when it starts.
On Jan-02, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >Another (maybe silly) possibility suggested itself to me based on a
> >private mail re: infant mortality from Thomas Whateley: could we try
> >optimistic allocations?
>
>
> > if (alloc_object() =
Steve Fink wrote:
I was assuming the generation would be automatically incremented per
op, either in the runops loop or (if that is too slow) in the
implementation of selected ops.
In the runops loop would be slow, and not very practical for e.g. JIT or
CGoto. But e.g. branch instructions wo
On Jan-02, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >On Dec-31, Leopold Toetsch wrote:
>
>
> >>I think, it moves the problems just around with a lot of overhead. E.g.
> >>cloning a PerlArray of 10^6 entries would need 1000 generations
>
> >I don't understand. The outer clone belongs to
On Tue, Dec 31, 2002 at 06:32:42PM -0800, Steve Fink wrote:
> On Dec-31, Jerome Vouillon wrote:
> > The temporary objects could be stored in a stack, which is popped when
> > leaving the current function (both with normal exits and longjmp).
> > This should make it a lot less likely to forget the u
At 6:52 PM -0500 1/2/03, [EMAIL PROTECTED] wrote:
Here's a proposal w.r.t. adaptive GC (it's a variant of
the NEW/BABY/DONTGCME/whatever flag): all buffers are
created with this flag, but we only clear the flag on
DOD runs when we _know_ it's safe (e.g. between opcodes);
if we find we're getting l
Here's a proposal w.r.t. adaptive GC (it's a variant of
the NEW/BABY/DONTGCME/whatever flag): all buffers are
created with this flag, but we only clear the flag on
DOD runs when we _know_ it's safe (e.g. between opcodes);
if we find we're getting low on resources, we queue a do-DOD-now
event to be
Nicholas Clark wrote:
On Thu, Jan 02, 2003 at 08:12:45PM +0100, Leopold Toetsch wrote:
[ refcounting ]
Effectively everything currently holding an object needing active
destruction becomes an object needing active destruction, (for the duration,
but no longer), and so on all the way back up
On Thu, Jan 02, 2003 at 08:12:45PM +0100, Leopold Toetsch wrote:
> Angel Faus wrote:
>
> >
> >What about refcounting + real GC?
>
>
> As soon as you start to refcount objects, which need active destroying,
> you end up refcounting all objects (a timer may be stored in an
> aggregate, passed to
Angel Faus wrote:
What about refcounting + real GC?
As soon as you start to refcount objects, which need active destroying,
you end up refcounting all objects (a timer may be stored in an
aggregate, passed to subs, may have references, ...).
So this is not an option, except changing every
From: Angel Faus [mailto:[EMAIL PROTECTED]]
>
> What about refcounting + real GC?
>
> refcounting will free most of the objects as soon as
> possible, and the real GC system makes sure that even
> cyclical references are eventually freed..
I believe this was covered in that same Re: DOC etc thr
At 10:24 PM +0100 1/2/03, Angel Faus wrote:
>
The best partial solution to early finalization is compile-time
tracing of possible references by the compiler which can explicitly
generate the appropriate DESTROY calls.
What about refcounting + real GC?
Yech, refcounting is one of the thin
>
> The best partial solution to early finalization is compile-time
> tracing of possible references by the compiler which can explicitly
> generate the appropriate DESTROY calls.
>
What about refcounting + real GC?
refcounting will free most of the objects as soon as possible, and the
real GC s
Jason Gloudon wrote:
On Wed, Jan 01, 2003 at 08:09:05PM -0800, Steve Fink wrote:
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
On Wed, Jan 01, 2003 at 08:09:05PM -0800, Steve Fink wrote:
> To anyone out there who is thinking of a Grand Unified Infant
> Mortality Solution, here's another thing that vastly complicates
> things, and that we don't yet have a workable solution for yet: prompt
> finalization.
Timely finalizati
Steve Fink wrote:
On Jan-01, Leopold Toetsch wrote:
Yep. The goal can only be, to either have *all* code paths that might
trigger DOD checked, or use one of the mentioned strategies. Though
reducing possibilities of infant mortatility by early anchoring is IMHO
always a good thing: it wou
Matt Fowles wrote:
All~
Parrot_do_at_most_N_DOD/GC(1);
do_clone
Parrot_unblock_DOD/GC(-1);
This would allow it to do one DOD run if it realized that it needed it part
way through the clone, but would never do more.
Very interesting approach. Yep. No need to check for probably needed
resour
Steve Fink wrote:
Another (maybe silly) possibility suggested itself to me based on a
private mail re: infant mortality from Thomas Whateley: could we try
optimistic allocations?
if (alloc_object() == NULL) {
undo everything
do_DOD_run
interp->on_alloc_f
Steve Fink wrote:
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
my %x;
{ # start scope
my $timer1 = Timer->new();
my $
Steve Fink wrote:
On Dec-31, Leopold Toetsch wrote:
I think, it moves the problems just around with a lot of overhead. E.g.
cloning a PerlArray of 10^6 entries would need 1000 generations
I don't understand. The outer clone belongs to generation N. Then if
you called clone() individually
To anyone out there who is thinking of a Grand Unified Infant
Mortality Solution, here's another thing that vastly complicates
things, and that we don't yet have a workable solution for yet: prompt
finalization.
my %x;
{ # start scope
my $timer1 = Timer->new();
my $timer2 = Timer->new(
Another (maybe silly) possibility suggested itself to me based on a
private mail re: infant mortality from Thomas Whateley: could we try
optimistic allocations?
Say we have a single memory backtracking jump buffer in the
interpreter. Then, before creating objects that cannot be easily
anchored to
On Jan-01, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >On Jan-01, Leopold Toetsch wrote:
>
>
> >>I know, that things get worse with optimization and with more complex
> >>programs.
>
> >And with other architectures that make heavier use of registers --
> >i386 may be an unrealistic example
On Dec-31, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >... So I decided to summarize the various approaches in
> >hopes that something will jump out at someone.
>
>
> Great document, thanks for all the work of summarizing this.
>
>
> > (2) point out what's wrong with my "variant 5: gener
All~
> >>The clone functions could be redone like:
> >> Parrot_do_dod_run(); // get free headers if possible
> >> Parrot_block_DOD/GC();
> >> do_clone
> >> Parrot_unblock_DOD/GC
> >>This would also be faster, because there are no DOD runs during clone
> >>(which wouldn't yield more free header
Steve Fink wrote:
On Jan-01, Leopold Toetsch wrote:
I know, that things get worse with optimization and with more complex
programs.
And with other architectures that make heavier use of registers --
i386 may be an unrealistic example, since not much can even fit into
the available register
On Jan-01, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >Many of our tinderbox failures result from architecture-specific
> >shortcomings in our current root set scanning code.
>
>
> Here is a test result (i386/linux) *without* --gc-debug and without
> trace_system_areas:
> ...
>
> I know,
On Dec-31, Brent Dax wrote:
> Steve Fink:
> # How do you do this with longjmp? I could see chaining another
> # handler onto the longjmp context so that longjmp would
> # backtrack through all of these allocations, but that would
> # require allocating space for another context. And allocating
Steve Fink wrote:
Many of our tinderbox failures result from architecture-specific
shortcomings in our current root set scanning code.
Here is a test result (i386/linux) *without* --gc-debug and without
trace_system_areas:
Failed Test Stat Wstat Total Fail Failed List of Failed
--
Steve Fink:
# > > - Easy to forget to remove temporaries from the root set
# > > - Easy to double-anchor objects and forget to remove the
# temporary
# > >anchoring
# > > - longjmp() can bypass the unanchoring
# >
# > The temporary objects could be stored in a stack, which is
# popped whe
On Dec-31, Jerome Vouillon wrote:
> On Mon, Dec 30, 2002 at 04:00:55PM -0800, Steve Fink wrote:
> > =head1 Solution 3: Explicity root set augmentation
> >
> > A final possible solution is to provide a mechanism to temporarily
> > anchor an otherwise unanchored object to the root set. (eg, have an
On Mon, Dec 30, 2002 at 04:00:55PM -0800, Steve Fink wrote:
> =head1 Solution 3: Explicity root set augmentation
>
> A final possible solution is to provide a mechanism to temporarily
> anchor an otherwise unanchored object to the root set. (eg, have an
> array of objects associated with the inter
Steve Fink wrote:
... So I decided to summarize the various approaches in
hopes that something will jump out at someone.
Great document, thanks for all the work of summarizing this.
(2) point out what's wrong with my "variant 5: generational
stack",
I think, it moves the problems
41 matches
Mail list logo
