Re: Infant mortality

2003-08-05 Thread Juergen Boemmels
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

Re: Infant mortality

2003-08-04 Thread Juergen Boemmels
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

Re: Infant mortality

2003-08-04 Thread Dan Sugalski
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

Re: Infant mortality

2003-08-04 Thread Benjamin Goldberg
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

Re: Infant mortality

2003-08-04 Thread Benjamin Goldberg
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

Infant mortality

2003-08-03 Thread Benjamin Goldberg
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

Re: Thoughts on infant mortality...

2003-01-13 Thread Leopold Toetsch
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

Re: Thoughts on infant mortality...

2003-01-13 Thread Dan Sugalski
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

Re: Thoughts on infant mortality...

2003-01-13 Thread Steve Fink
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

Re: Thoughts on infant mortality...

2003-01-13 Thread Jason Gloudon
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

Re: Thoughts on infant mortality...

2003-01-10 Thread Leopold Toetsch
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,

Re: Thoughts on infant mortality...

2003-01-10 Thread Steve Fink
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

Re: Thoughts on infant mortality...

2003-01-10 Thread Leopold Toetsch
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

Thoughts on infant mortality...

2003-01-09 Thread Piers Cawley
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

Re: Infant mortality

2003-01-09 Thread Leopold Toetsch
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

Re: Thoughts on infant mortality...

2003-01-09 Thread Leopold Toetsch
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

Re: Thoughts on infant mortality...

2003-01-09 Thread Nicholas Clark
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

Re: Thoughts on infant mortality...

2003-01-09 Thread Leopold Toetsch
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

Re: Thoughts on infant mortality...

2003-01-09 Thread Dan Sugalski
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

Re: Infant mortality

2003-01-09 Thread Dan Sugalski
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

Re: Infant mortality

2003-01-04 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-04 Thread Leopold Toetsch
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.

Re: Infant mortality

2003-01-03 Thread Jerome Vouillon
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

Re: Infant mortality

2003-01-03 Thread Steve Fink
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.

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

[perl #19668] [PATCH] infant mortality #1

2003-01-02 Thread via RT
# 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

Re: Infant mortality

2003-01-02 Thread Jason Gloudon
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread Angel Faus
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

Re: Infant mortality

2003-01-02 Thread Dan Sugalski
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

RE: Infant mortality [x-adr][x-bayes]

2003-01-02 Thread Garrett Goebel
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread Nicholas Clark
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

Re: Infant mortality

2003-01-02 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-02 Thread bks24
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

Re: Infant mortality

2003-01-02 Thread Dan Sugalski
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

Re: Infant mortality

2003-01-01 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-01 Thread Steve Fink
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 #

Re: Infant mortality

2003-01-01 Thread Steve Fink
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

Re: Infant mortality

2003-01-01 Thread Leopold Toetsch
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

Re: Infant mortality

2003-01-01 Thread Matt Fowles
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

Re: Infant mortality

2003-01-01 Thread Steve Fink
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

Re: Infant mortality

2003-01-01 Thread Steve Fink
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

Re: Infant mortality

2003-01-01 Thread Steve Fink
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

Re: Infant mortality

2003-01-01 Thread Steve Fink
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

Re: Infant mortality

2002-12-31 Thread Leopold Toetsch
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

Re: Infant mortality

2002-12-31 Thread Jerome Vouillon
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

Re: Infant mortality

2002-12-31 Thread Steve Fink
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

RE: Infant mortality

2002-12-31 Thread Brent Dax
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 #