mes and GC'd by zone
Yes. In the presence of PMCs with timely destruction, each lexical scope
will be one GC generation.
leo
Michael
On Sat, 15 Jan 2005 01:28:22 +, Shevek <[EMAIL PROTECTED]> wrote:
> In which Tigger maintains that code relying on timely destruction in
> perl5 is buggy [and relatively rare], and agrees wholeheartedly with
> Rabbit on almost everything else.
>
> On Fri, 2005-01-
In which Tigger maintains that code relying on timely destruction in
perl5 is buggy [and relatively rare], and agrees wholeheartedly with
Rabbit on almost everything else.
On Fri, 2005-01-14 at 17:52 -0700, Luke Palmer wrote:
> Shevek writes:
> > The example you described destroyed a ref
ct heap when permanent store is full,
> although this permanent store ought to be treated as a strictly older
> generation.
There are a lot of partial solutions. I get the impression that when
they say "timely destruction" they want a full solution. Here's an
example of a
a();
# ...
b();
And what I mean is that most approximate solutions won't destroy $fh in
time. One example of such a proposal is keeping tabs on objects in the
current scope which need timely destruction and then do a sweep whenever
we lose a reference to one. Another is using gen
Dave Mitchell writes:
> On Fri, Jan 14, 2005 at 02:40:43PM -0700, Luke Palmer wrote:
> > What I'd most like is to convince Larry to waive the timely destruction
> > requirement. However, that doesn't really solve the problem for other
> > languages that need tim
On Fri, 2005-01-14 at 16:56 -0700, Luke Palmer wrote:
> > I thought C++ only guaranteed destruction (on return or exception) for
> > objects which were directly on the stack.
>
> That's true, you have to explicitly delete most memory. I was actually
> referring to the template refcounting class
d on scope exit.
> > tell Parrot when PMCs need refcounting before it assembled the bytecode,
> > and also in some other places, we might be able to pull it off. But
> > that's a halting problem problem if the language from which we're
> > compiling is untyped.
On Fri, Jan 14, 2005 at 02:40:43PM -0700, Luke Palmer wrote:
> What I'd most like is to convince Larry to waive the timely destruction
> requirement. However, that doesn't really solve the problem for other
> languages that need timely destruction. Are there any?
Per
ces, we might be able to pull it off. But
> that's a halting problem problem if the language from which we're
> compiling is untyped.
>
> What I'd most like is to convince Larry to waive the timely destruction
> requirement. However, that doesn't really solve the problem for other
> languages that need timely destruction. Are there any?
>
> Luke
>
em problem if the language from which we're
compiling is untyped.
What I'd most like is to convince Larry to waive the timely destruction
requirement. However, that doesn't really solve the problem for other
languages that need timely destruction. Are there any?
Luke
ly dead. This is
accomplished by the "sweep 0" opcode, which does nothing if no object
needs timely destruction.
If the number of objects that needs this is relatively small, we could
play a trick somewhat like the following (with small changes to the perl
compiler):
1. Break the
y the "sweep 0" opcode, which does nothing if no object
needs timely destruction.
Above example could roughly translate to Parrot code like:
new_pad -1 # new lexical scope
$P0 = new ParrotIO
store_lex -1, "$fh", $P0
open $P0, "test.tmp", &q
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
===
Tim Bunce wrote:
On Sun, Aug 24, 2003 at 10:48:02AM -0700, Steve Fink wrote:
I guess you could think of the lifecycle of an individual object as
being controlled by a few significant life events:
1. birth
2. the last reference disappearing
3. finalization
4. destruction
That's a nice idea,
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
so you might want to use
1. birth
2. the last reference disappearing
3. (object) destruction
4. (memory) deallocation
which I believe is unambiguous.
And the "timely destruction" problem is about ensuring that nothing at
language level can spot a gap between steps 2 and 3.
It's unclear
whatever
> cleanup actions an object performs at some point after it is no longer
> accessible. So "timely destruction" is not very important, because
> destruction only needs to be timely enough to avoid running out of
> memory. "Timely finalization" is what we spend mu
At 6:45 PM -0700 8/18/03, Dave Whipp wrote:
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
What we'd like is a way (and there've been a couple proposed) to make it
so that the sweep at the end of scope can *quickly* determine that a
onger
accessible. So "timely destruction" is not very important, because
destruction only needs to be timely enough to avoid running out of
memory. "Timely finalization" is what we spend much time talking and
worrying about. In Perl5, if you didn't think about it too hard the
> > > >
> > > > 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 quite fo
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 propos
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 refc
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 p
"Leopold Toetsch" <[EMAIL PROTECTED]>
> To: "Benjamin Goldberg" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 19, 2003 12:20 AM
> Subject: Re: What the heck is: timely destruction
>
>
> > Benjamin Goldberg
Bennett Todd <[EMAIL PROTECTED]> writes:
> Is the destruction going to be timely enough for
>
> IO::File->new(">foo")->print("foo\n");
> print `cat foo`;
>
> to behave predictably?
That's certainly the idea.
On Tue, 19 Aug 2003, Bennett Todd wrote:
> Is the destruction going to be timely enough for
>
> IO::File->new(">foo")->print("foo\n");
> print `cat foo`;
>
> to behave predictably?
If you're asking if you can, in general, coun
Is the destruction going to be timely enough for
IO::File->new(">foo")->print("foo\n");
print `cat foo`;
to behave predictably?
-Bennett
pgp0.pgp
Description: PGP signature
, August 19, 2003 12:20 AM
Subject: Re: What the heck is: timely destruction
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>
> > Every time we come to a scope end, we do a garbage collection run.
>
> ... only if there are objects around, that were marked to need timely
>
Dave Whipp <[EMAIL PROTECTED]> wrote:
> ... I've run into this problem on several GCed apps: the sweep
> destroys locality of access, causing pages to be loaded that the application
> doesn't need. This can cause a very abrupt performance drop.
The flags used during DOD take (for simple PMCs) jus
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> What we'd like is a way (and there've been a couple proposed) to make it
> so that the sweep at the end of scope can *quickly* determine that all
> objects needing timely destructio
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Every time we come to a scope end, we do a garbage collection run.
... only if there are objects around, that were marked to need timely
destruction. If the HLL will decide that each object might need timely
destructions we will get into
at garbage collection will generally happen more
often.
In Java, it happens when you run out of memory, or when someone does
"java.lang.Runtime.getRuntime().gc()". There's no timely destruction,
be cause you'd need to be psychic to know ahead of time when you're
goin
2003-08-18T13:52:50 K Stol:
> After reading most of the messages on timely destruction, I still
> don't quite understand what it is. If someone has a spare minute
> free, could you please explain?
The other explanations certainly have formality to commend them, but
somehow they did
At 11:56 -0700 8/18/03, K Stol wrote:
Uhm, I didn't realize destructor methods were called, but now I see that's
the whole point:
destructor methods should be called when doing timely destruction.
You already said just now:
This doesn't necessarily mean that their memory has to be
On Mon, Aug 18, 2003 at 11:56:53AM -0700, K Stol wrote:
> > This doesn't necessarily mean that their memory has to be freed but that
> > at least their destructor methods are called.
>
> So the objects may be still in memory. I thought the fact that they are
> still in memory
> was troublesome, bu
On Mon, Aug 18, 2003 at 11:38:22AM -0700, K Stol wrote:
> if I understood correctly, the problem is that some objects should be
> destroyed *immediately*, and should not wait for the GC.
Yep. In perl 5 *all* objects and variables are to be destroyed immediately.
This doesn't necessarily mean tha
- Original Message -
From: "Elizabeth Mattijsen" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>; "Michael G Schwern" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 18, 2003 3:10 AM
Subject: Re: What the heck is:
- Original Message -
From: "Michael G Schwern" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 18, 2003 2:49 AM
Subject: Re: What the heck is: timely destruction
> On Mon, Aug 18, 2003 at
- Original Message -
From: "Michael G Schwern" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, August 18, 2003 2:04 AM
Subject: Re: What the heck is: timely destruction
> On Mon, Aug 18, 2003 at 10:52:50
On Mon, Aug 18, 2003 at 10:52:50AM -0700, K Stol wrote:
> After reading most of the messages on timely destruction, I still don't quite
> understand what it is. If someone has a spare minute free, could you please explain?
In perl5 you can write this.
my $Destroyed = 0;
hello,
After reading most of the messages on timely destruction, I still don't quite
understand what it is. If someone has a spare minute free, could you please explain?
Thanks in advance!
Klaas-Jan
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
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 (or more), all objects
needing t
good, but they shine through holes in uninitialized area out
from previous frames into the current. So physically they are in the frame.
We should really rethink the statement "We will always walking the
stack". The timely destruction needs to know for sure if an object is
alive or not.
en.
>
> As we don't pass around mmx/sse memory locations above option should be
> safe.
[...]
We should really rethink the statement "We will always walking the
stack". The timely destruction needs to know for sure if an object is
alive or not. The conservative stack-walking wil
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
>
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
processor registers). Due to the conservative app
ion system.
Last I checked Python used refcounting... How can we claim to
support Python without refcounting?
Easily--Python does *not* claim timely destruction. I've asked Guido,
and he's been pretty adamant about that.
> Unless Larry mandates dead-on timely destruction for Perl 6,
ast I checked Python used refcounting... How can we claim to support Python
without refcounting?
> Unless Larry mandates dead-on timely destruction for Perl 6, and he's
> told me end of block or end of sub is fine so far, refcounting isn't
> an option.
I wandered across some C# d
ementing a generational or continuous
garbage collection system.
Unless Larry mandates dead-on timely destruction for Perl 6, and he's
told me end of block or end of sub is fine so far, refcounting isn't
an option.
Thanks. No, I don't re
58 matches
Mail list logo
