On Tue, 9 Sep 2003, Luke Palmer wrote:
> Okay, after some major changes, here's the second revision of my patch.
> This one is fully functional.
>
> On my system, it creates over a 10x speedup for lazy DOD runs!
What's it do for non-lazy runs?
> (I'll post the benchmark program if someone wants
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Okay, after some major changes, here's the second revision of my patch.
> This one is fully functional.
> On my system, it creates over a 10x speedup for lazy DOD runs!
We need that!!!1
> (I'll post the benchmark program if someone wants; it's pretty long
On Wednesday 10 September 2003 01:52, Luke Palmer wrote:
> Okay, after some major changes, here's the second revision of my patch.
> This one is fully functional.
>
> On my system, it creates over a 10x speedup for lazy DOD runs!
Yay!
>
> (I'll post the benchmark program if someone wants; it's pre
Okay, after some major changes, here's the second revision of my patch.
This one is fully functional.
On my system, it creates over a 10x speedup for lazy DOD runs!
(I'll post the benchmark program if someone wants; it's pretty long)
Luke
Index: core.ops
===
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
>>
>> Can you summarize your scheme again please WRT this and other
>> enhancements. I'm somewhat lost in all the improvements that were
>> proposed since your original.
> Alright, here's a patch that implements it.
Wow.
Some remar
Leopold Toetsch writes:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > In any case, seeing that depth first case (see the footnote) has given
> > me even more hope that I won't be agonizing over scope exit.
>
> Can you summarize your scheme again please WRT this and other
> enhancements. I'm some
Luke Palmer <[EMAIL PROTECTED]> wrote:
> In any case, seeing that depth first case (see the footnote) has given
> me even more hope that I won't be agonizing over scope exit.
Can you summarize your scheme again please WRT this and other
enhancements. I'm somewhat lost in all the improvements that
Steve Fink writes:
> (I am way, way behind on reading this mailing list.)
>
> Assuming I understand your scheme properly, it seems incorrect to me.
>
> An object must be finalized during the first 'sweep 0' after it is no
> longer reachable from the root set. (And no object may be finalized
> w
(I am way, way behind on reading this mailing list.)
Assuming I understand your scheme properly, it seems incorrect to me.
An object must be finalized during the first 'sweep 0' after it is no
longer reachable from the root set. (And no object may be finalized
while it is still reachable, but y
Dave Mitchell wrote:
>
> On Wed, Aug 20, 2003 at 06:40:51PM -0400, Benjamin Goldberg wrote:
> > Dave Mitchell wrote:
> > >
> > > On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> > > > Here comes that ever-reincarnating thread again, sorry.
> > > >
> > > > This is a proposal for an ef
On Wed, Aug 20, 2003 at 06:40:51PM -0400, Benjamin Goldberg wrote:
> Dave Mitchell wrote:
> >
> > On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> > > Here comes that ever-reincarnating thread again, sorry.
> > >
> > > This is a proposal for an efficient solution to the timely destru
Dave Mitchell wrote:
>
> On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> > Here comes that ever-reincarnating thread again, sorry.
> >
> > This is a proposal for an efficient solution to the timely destruction
> > problem, which doesn't use refcounting, and fits in to the current
On Sun, Aug 17, 2003 at 05:48:14AM -0600, Luke Palmer wrote:
> Here comes that ever-reincarnating thread again, sorry.
>
> This is a proposal for an efficient solution to the timely destruction
> problem, which doesn't use refcounting, and fits in to the current
> scheme pretty well.
I don't quit
Luke Palmer wrote:
>
> Here comes that ever-reincarnating thread again, sorry.
>
> This is a proposal for an efficient solution to the timely destruction
> problem, which doesn't use refcounting, and fits in to the current
> scheme pretty well.
>
> It is based on the fact that 90% of the time (o
Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
So during a DOD run the trails of an IO PMC are found on the system
stack during trace_mem_block. The main problem seems to be, that gcc
uses 16-byte aligned stack frames by default.
*Ouch* I spend the whole Friday searching th
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> I have a (partial?) solution for this. What AFAIK is going on is
> something like this:
>
> C-stack: Parrot_open() ... later ... do_dod_run()
>... ...
> $1 = pmc_new sub $0x44, %esp
>
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> t/pmc/io_2 is failing on some tinderboxen that don't have memalign and
> therefore don't have ARENA_DOD_FLAGS set. Besides the wrong count of DOD
> runs, the primary problem is:
> The ParrotIO object is found to be alive in some system areas (probably
>
At 9:56 AM -0500 6/4/03, Garrett Goebel wrote:
Dan Sugalski wrote:
We aren't doing refcounting. We are continuing with the current
scheme as implemented. We're not looking to do anything to change
that scheme except perhaps implementing a generational or continuous
garbage collection system.
La
Dan Sugalski wrote:
>
> We aren't doing refcounting. We are continuing with the current
> scheme as implemented. We're not looking to do anything to change
> that scheme except perhaps implementing a generational or continuous
> garbage collection system.
Last I checked Python used refcounting
19 matches
Mail list logo
