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) {
...
}
foreach(pmc
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
until
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
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: anchor right away
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
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
until the new object isn't needed.
This document doesn't
Jason Gloudon wrote:
3) The vtable calls some code deletes the reference to the PMC, which is now
no longer accessible from the root set. The vtable then attempts to allocate
some memory.
The vtable function will now contain the only remaining reference to the PMC,
but unless the vtable
At 11:21 AM -0500 1/13/03, Jason Gloudon wrote:
On a related note, I have been looking at implementation techniques for
incremental/generational garbage collectors. A critical aspect of a
generational garbage collector is a write barrier, which records any pointer
writes that create references to
when the PMC is unanchored.
This is similar to the infant mortality, but shows that it doesn't
only happen to infants.
The solution is also similar: reorder instructions. If you push
the PMC onto the second aggregate before removing it from the first,
you're ok. And once again, it's unclear how
On Mon, Jan 13, 2003 at 09:51:13AM -0800, Steve Fink wrote:
reference or being a member of an aggregate.
2) A vtable function obtains a PMC* to that PMC.
3) The vtable calls some code deletes the reference to the PMC, which is now
no longer accessible from the root set. The vtable
Dan Sugalski wrote:
At 4:17 PM + 1/9/03, Nicholas Clark wrote:
On Thu, Jan 09, 2003 at 01:32:57PM +0100, Leopold Toetsch wrote:
But I still favor the combination of:
- code reordering, like done for pmc_new
- DOD/GC disabling (e.g. aggregate clone)
- active anchoring to the root set,
On Jan-10, Leopold Toetsch wrote:
Also I was thinking of: trace_system_areas could be run last in marking
and if it finds some unanchored objects, it could print a warning, so we
could really check, if we ware safe.
That's what defining GC_VERBOSE in parrot.h will give you right now,
and
Steve Fink wrote:
On Jan-10, Leopold Toetsch wrote:
Also I was thinking of: trace_system_areas could be run last in marking
and if it finds some unanchored objects, it could print a warning, so we
could really check, if we ware safe.
That's what defining GC_VERBOSE in parrot.h will give
This will be vague and handwavy, but I *think* it suggests something
that hasn't been tried before...
1. The problem of infant mortality is that resource allocation can
trigger a DOD run could wipe out the very thing we were allocating
memory for.
2. This can be solved by extending
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
Piers Cawley wrote:
alloc_and_link( void ** handle, size_t size);
This is covered in Steve Finks summary as solution 3.
There were also two code snippets by Brent Dax and Jerome Vouillon, that
deal with exception handling too. s. thread Infant mortality started
by Steve.
Note
On Thu, Jan 09, 2003 at 01:32:57PM +0100, Leopold Toetsch wrote:
But I still favor the combination of:
- code reordering, like done for pmc_new
- DOD/GC disabling (e.g. aggregate clone)
- active anchoring to the root set, where above is not applicable
Which combined means that there is no
Nicholas Clark wrote:
On Thu, Jan 09, 2003 at 01:32:57PM +0100, Leopold Toetsch wrote:
But I still favor the combination of:
- code reordering, like done for pmc_new
- DOD/GC disabling (e.g. aggregate clone)
- active anchoring to the root set, where above is not applicable
Which combined
At 4:17 PM + 1/9/03, Nicholas Clark wrote:
On Thu, Jan 09, 2003 at 01:32:57PM +0100, Leopold Toetsch wrote:
But I still favor the combination of:
- code reordering, like done for pmc_new
- DOD/GC disabling (e.g. aggregate clone)
- active anchoring to the root set, where above is not
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
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
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 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
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 generation N.
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
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:
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_fail
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
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
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #19668]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19668
Attached patch changes a view places, which cause problems running w/o
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 finalization
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
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
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
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
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
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 subs, may
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
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
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
wouldn't yield more free headers anyway).
I think that by either anchoring a newly created header early or by
blocking DOD/GC we could solve the infant mortality problem.
leo
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
#
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, that things
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
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 headers anyway).
But
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: generational
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, since not much
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 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
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
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
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
array
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 when
#
53 matches
Mail list logo
