> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
>> > "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
>>
TB> As a part of that the weak reference concept, bolted recently into
TB> perl5, could be made more central in
On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
> > "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
>
> TB> As a part of that the weak reference concept, bolted recently into
> TB> perl5, could be made more central in perl6.
>
> TB> Around 92.769% of the time circular refere
At 09:13 PM 2/15/2001 -0500, Ken Fox wrote:
>Hong Zhang wrote:
> > The memory barriers are always needed on SMP, whatever algorithm
> > we are using.
>
>I was just pointing out that barriers are an alternative to mutexes.
>Ref count certainly would use mutexes instead of barriers.
Not really they
At 02:08 PM 2/15/2001 -0800, Hong Zhang wrote:
> > Hong Zhang wrote:
> >
> > > This code should NEVER work, period. People will just ask for trouble
> > > with this kind of code.
> >
> > Actually I meant to have specified ">>" as the mode, i.e. append, then
> > what I originally said holds true.
Hong Zhang wrote:
> The memory barriers are always needed on SMP, whatever algorithm
> we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
> The memory barrier can be easily coded in assembly, or intrinsic
> There are several concurrent GC algorithms that don't use
> mutexes -- but they usually depend on read or write barriers
> which may be really hard for us to implement. Making them run
> well always requires help from the OS memory manager and that
> would hurt portability. (If we don't have OS
Alan Burlison wrote:
> I think you'll find that both GC *and* reference counting scheme will
> require the heay use of mutexes in a MT program.
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to
Hong Zhang wrote:
> That was not what I meant. Your code already assume the existence of
> reference counting. It does not work well with any other kind of garbage
> collection. If you translate the same code into C without putting in
> the close(), the code will not work at all.
Wrong, it does
> Hong Zhang wrote:
>
> > This code should NEVER work, period. People will just ask for trouble
> > with this kind of code.
>
> Actually I meant to have specified ">>" as the mode, i.e. append, then
> what I originally said holds true. This behaviour is predictable and
> dependable in the curre
Hong Zhang wrote:
> This code should NEVER work, period. People will just ask for trouble
> with this kind of code.
Actually I meant to have specified ">>" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl implemen
> {
> my $fh = IO::File->new("file");
> print $fh "foo\n";
> }
> {
> my $fh = IO::File->new("file");
> print $fh "bar\n";
> }
>
> At present "file" will contain "foo\nbar\n". Without DF it could just
> as well be "bar\nfoo\n". Make no mistake, this is a major change to t
Branden wrote:
> Just set autoflush, if you're lazy...
And say goodbye to performance...
> > The problem is
> > that you can not only count on $fh's DESTROY being called at the end of
> > the block, you often can't count on it ever happening.
>
> Anyway, the file would be flushed and closed...
> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> As a part of that the weak reference concept, bolted recently into
TB> perl5, could be made more central in perl6.
TB> Around 92.769% of the time circular references are known to be
TB> circular by the code that creates them (like a
Damien Neil wrote:
> On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> > I think you just said all about why we shouldn't bother giving objects
> > deterministic finalization, and I agree with you. If we explicitly want
to
> > free resources (files, database connections), then we explicit
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> I think you just said all about why we shouldn't bother giving objects
> deterministic finalization, and I agree with you. If we explicitly want to
> free resources (files, database connections), then we explicitly call close.
> Otherwise,
Tim Bunce wrote:
> On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> > And don't forget that if we stick with refcounting, we should try to
find a
> > way to break circular references, too.
>
> As a part of that the weak reference concept, bolted recently into perl5,
> could be made more
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> Hong Zhang
> > > A deterministic finalization means we shouldn't need to force
> programmers
> > > to have good ideas. Make it easy, remember? :)
> >
> > I don't believe such an algorithm exists, unless you stick with reference
> > count.
Hong Zhang
> > A deterministic finalization means we shouldn't need to force
programmers
> > to have good ideas. Make it easy, remember? :)
>
> I don't believe such an algorithm exists, unless you stick with reference
> count.
>
Either doesn't exist, or is more expensive than refcounting. I guess
Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization. A much better approach
> is to have methods which allow holders of the object to control it,
> and a finalizer (DESTROY method) which cleans up only if necessary
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Hong
On Thu, Feb 15, 2001 at 12:11:27AM +, Simon Cozens wrote:
> > Using object lifetime to control state is almost never a good idea,
> > even if you have deterministic finalization.
>
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy,
On Wed, Feb 14, 2001 at 01:24:34PM -0800, Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization.
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy, remember?
On Wed, Feb 14, 2001 at 05:43:31PM -0300, Branden wrote:
> 4. Why should we bother destroying an object before GC does it?
>
> To free system resources, like open files or database connections. Probably
> the average program won't do it never, but programs that must open several
> files sequentia
[trimming distribution to -internals only]
On Wed, Feb 14, 2001 at 07:44:53PM +, Simon Cozens wrote:
> package NuclearReactor::CoolingRod;
>
> sub new {
> Reactor->decrease_core_temperature();
> bless {}, shift
> }
>
> sub DESTROY {
> Reactor->increase_core_temperature();
> }
A
At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
>On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > > DESTROY would get called twice, which is VERY BAD.
> >
> > *blink*
> > It is? Why?
> > I grant you it isn't the clearest way of programming, but "VERY BAD"?
>
>package Nuclear
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > DESTROY would get called twice, which is VERY BAD.
>
> *blink*
> It is? Why?
> I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor->decrease_core_te
[[ reply goes to -internals ]]
OK. Let's clear it up all at once from start. Below is the lifecycle of an
object (in Perl). A reference is blessed, and an object is the result of
this blessing. During the object's life, several methods of it are called,
but independent of which are called, it co
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote:
>
> Dan Sugalski wrote:
>
> > Plus there's nothing stopping you from having $obj->DESTROY in your own
> > code, though it may be inadvisable.
>
> It is (mainly) inadvisable because:
> 1. GC will call DESTROY when it collects the memory, s
On Wed, Feb 14, 2001 at 01:30:03PM -0300, Branden wrote:
> John Porter wrote:
> > James Mastros wrote:
> > > I'd think that an extension to delete is in order here. Basicly, delete
> > > should DESTROY the arg, change it's value to undef,...
> >
> > Huh? What delete are you thinking of? This is
Branden wrote:
> John Porter wrote:
> > > ...and trigger a GC that will get rid of the arg.
> >
> > No. Perl decides for itself when to do GC.
>
> The idea is to *allow* a programmer to explicitly destroy an object, for
> better (and sooner) resource disposal. The programmer wouldn't have to do
On Wed, Feb 14, 2001 at 01:25:26PM -0300, Branden wrote:
> The problem is when objects are shared by
> many variables. For example:
>
> $a = new Object();
> $b = $a;
> ...
> destroy $a; ## would call $a->DESTROY()
> ...
> $b->doSomething();## should die. Note
On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote:
> As I wrote in the last post, this isn't what I'm talking about. I'm talking
> about destroying the object before the GC does.
Yah, so am I. I'm just saying that after the object is destroyed, don't
keep it around.
> Yeah, what about a na
[[ reply to this goes only to -internals ]]
Dan Sugalski wrote:
> *) People like it
Well, if people liking it is the only reason (either is the only on or
appears 3 times in a 5 item list, what is pretty much the same to me ;-)
[... the only reason] to add a feature to Perl, we'll probably end
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > [snip about DESTORY predictablity not being neccessary]
> > You're probably right about that, Branden. Quite nice, but not
neccessary.
> Hmm, I'd have to say that predictability is very, *very* nice,
> and we shouldnt ditch it u
James Mastros wrote:
> On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> > Huh? What delete are you thinking of? This is Perl, not C++.
> Umm, perldoc -f delete?
>
> Come to think of it, this doesn't mesh purticularly well with the current
> meaning of delete. It does, however, wit
At 10:12 AM 2/14/2001 -0300, Branden wrote:
>David Mitchell wrote:
> > James Mastros <[EMAIL PROTECTED]> wrote:
> > > ... do refcounting (or somthing like it) for DESTROY to get called at
>the right
> > > time if the class (or any superclass) has an AUTOLOAD, which is
>expensive.
> > ... the above
John Porter wrote:
> James Mastros wrote:
> > I'd think that an extension to delete is in order here. Basicly, delete
> > should DESTROY the arg, change it's value to undef,...
>
> Huh? What delete are you thinking of? This is Perl, not C++.
>
Agreed, definitely Perl is not C++.
> > ...and t
James Mastros wrote:
> On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> > Also, I think it would be valid for the programmer to explicitly say ``I
> > would like to DESTROY this object now'',
> I'd think that an extension to delete is in order here. Basicly, delete
> should DESTROY the
James Mastros <[EMAIL PROTECTED]> wrote:
> [snip about DESTORY predictablity not being neccessary]
> You're probably right about that, Branden. Quite nice, but not neccessary.
Hmm, I'd have to say that predictability is very, *very* nice,
and we shouldnt ditch it unless we *really* have to.
[ l
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> James Mastros wrote:
> > I'd think that an extension to delete is in order here. Basicly, delete
> > should DESTROY the arg, change it's value to undef,...
> Huh? What delete are you thinking of? This is Perl, not C++.
Umm, perldoc
James Mastros wrote:
> I'd think that an extension to delete is in order here. Basicly, delete
> should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not C++.
> ...and trigger a GC that will get rid of the arg.
No. Perl decides for itse
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> David Mitchell wrote:
> > ... the above seems to imply a discussion that you only need to do
> expensive
> > ref-counting (or whatever) on objects which have a DESTROY method.
> > However, since you dont know in advance what class(es), if
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > ... do refcounting (or somthing like it) for DESTROY to get called at
the right
> > time if the class (or any superclass) has an AUTOLOAD, which is
expensive.
> ... the above seems to imply a discussion that you only need to do
e
James Mastros <[EMAIL PROTECTED]> wrote:
> The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
> do refcounting (or somthing like it) for DESTROY to get called at the right
> time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway th
At 06:35 PM 2/13/01 +, Nicholas Clark wrote:
> > This may be a naive question, but what is the benefit - aside from
> > consistency, and we don't need to rehash the litany on that - to AUTOLOAD
> > getting called for DESTROY? I've never actually seen any code that makes
> > use of it. I hav
At 10:32 AM 2/13/2001 -0800, Peter Scott wrote:
>At 01:16 PM 2/13/01 -0500, James Mastros wrote:
>>On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
>>Certainly AUTOLOAD gets
>> > called if DESTROY is called but not defined ... just
>> > like any other method.
>>The idea is [for Larry]
On Tue, Feb 13, 2001 at 10:32:26AM -0800, Peter Scott wrote:
> At 01:16 PM 2/13/01 -0500, James Mastros wrote:
> >On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> >Certainly AUTOLOAD gets
> > > called if DESTROY is called but not defined ... just
> > > like any other method.
> >The i
At 01:16 PM 2/13/01 -0500, James Mastros wrote:
>On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
>Certainly AUTOLOAD gets
> > called if DESTROY is called but not defined ... just
> > like any other method.
>The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
>do
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> > >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
>
> I'm not sure what that means. Certainly AUTOLOAD gets
> called if DESTROY is called but not defined ... just
> like any other method.
Yes, its a classic autoloader mistake
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> > James Mastros wrote:
> > >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
[Note: that's a hypothetical quote.]
> I'm not sure what that means. Certainly AUTOLOAD gets
> called if DESTROY is called but not defined ... just
> l
> James Mastros wrote:
>
> >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
I'm not sure what that means. Certainly AUTOLOAD gets
called if DESTROY is called but not defined ... just
like any other method.
--
John Porter
On Tue, Feb 13, 2001 at 12:40:45PM -0500, Dan Sugalski wrote:
> At 05:55 PM 2/12/2001 -0500, James Mastros wrote:
> >It's pretty hard (for me) to think of when you'd want an AUTOLOADed DESTROY,
> >since if you create /any/ objects of the class, DESTROY will be called.
> >"It isn't possible to AUT
At 05:55 PM 2/12/2001 -0500, James Mastros wrote:
>On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
> >package foo;
> >use attrs qw(cleanup_sub);
> >
> > would be nice, but I don't know that he'll go for it. (Though it's the
> only
> > way I can think of to avoid AUTOLOAD bei
At 07:51 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
>On Monday 12 February 2001 16:54, Dan Sugalski wrote:
> > >Could you guys please use "destruction" or "cleanup" as the term for the
> > >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> > >else to mean: called by GC be
On Monday 12 February 2001 16:54, Dan Sugalski wrote:
> >Could you guys please use "destruction" or "cleanup" as the term for the
> >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> >else to mean: called by GC before the memory is released (see e.g
> >Java/C#).
>
> Corre
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
>package foo;
>use attrs qw(cleanup_sub);
>
> would be nice, but I don't know that he'll go for it. (Though it's the only
> way I can think of to avoid AUTOLOAD being considered a potential destructor)
Fiat?
It's pretty hard
At 17:33 12/02/2001 -0500, Dan Sugalski wrote:
>At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
>>Couldn't we simply (for non-implementer values of simply) provide a way for
>>people to ask for finalization on an object ? Given that most of the time
>>it isn't needed, it wouldn't be too much of a
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
>At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
> >It *is* rare in OO perl, though. How many of the variables you use are
> >really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
> >forget that you need to count every scalar in
At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
>It *is* rare in OO perl, though. How many of the variables you use are
>really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
>forget that you need to count every scalar in every array or hash, and
>every iteration over a blo
At 01:44 PM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >Yep, that's another issue, and one I keep forgetting about, though the fact
> >that we don't do predictable finalization on some objects isn't a good
>
>Yes, I know I pr
On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Yep, that's another issue, and one I keep forgetting about, though the fact
>that we don't do predictable finalization on some objects isn't a good
Yes, I know I promised to shut up until you come up with a spec, but
At 09:08 PM 2/12/2001 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> > >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> > >
> > > > Perl needs some level of tracking for objects with finalization
> attached to
> > > > them. F
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >
> > > Perl needs some level of tracking for objects with finalization attached to
> > > them. Full refcounting isn't required, however.
> >
> >I think I've hea
At 01:33 PM 2/12/2001 -0500, Sam Tregar wrote:
>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>
> > >I think I've heard you state that before. Can you be more specific? What
> > >alternate system do you have in mind? Is this just wishful thinking?
> >
> > This isn't just wishful thinking, no.
>
>You
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >>On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >>
> >> > Perl needs some level of tracking for objects with finalization
On Mon, 12 Feb 2001 13:33:52 -0500 (EST), Sam Tregar <[EMAIL PROTECTED]>
wrote:
>> It's reasonably obvious (which is to say "cheap") which variables aren't
>> involved with anything finalizable.
>
>Probably a simple bit check and branch. Is that cheap? I guess it must
>be.
Yes, but incrementin
At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
>wrote:
>
> >Actually I was thinking something like PMCs ($@%) being copy-GCed and
> >referred objects (new SomeClass) being refcounted. In this case above, every
> >operation would us
At 11:01 PM 2/11/2001 -0800, Jan Dubois wrote:
>[moved to -internals]
>
>On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >Perl needs some level of tracking for objects with finalization attached to
> >them. Full refcounting isn't required, however. Also, the vast ma
On Mon, Feb 12, 2001 at 01:33:52PM -0500, Sam Tregar wrote:
> Perhaps. It's not rare in OO Perl which is coincidentally one area in
> serious need of a speedup. I suppose I'm warped by my own experience -
> all the code I see every day is filled with references and objects.
> That's probably not
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
>>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>>
>> > Perl needs some level of tracking for objects with finalization attached to
>> > them. Full refcounting isn't required, ho
On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >I think I've heard you state that before. Can you be more specific? What
> >alternate system do you have in mind? Is this just wishful thinking?
>
> This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>
> > Perl needs some level of tracking for objects with finalization attached to
> > them. Full refcounting isn't required, however.
>
>I think I've heard you state that before. Can you be more specific? Wh
On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
wrote:
>Actually I was thinking something like PMCs ($@%) being copy-GCed and
>referred objects (new SomeClass) being refcounted. In this case above, every
>operation would use refcount's, since they're storing objects in PMCs. Wha
Buddha Buck wrote:
> At 01:45 PM 02-12-2001 -0300, Branden wrote:
> >Am I too wrong here?
>
> It's... complicated...
>
Agreed.
> Here's an example of where things could go wrong:
>
> sub foo {
> my $destroyme1 = new SomeClass;
> my $destroyme2 = new SomeClass;
> my @pr
At 01:45 PM 02-12-2001 -0300, Branden wrote:
>I think having both copying-GC and refcounting-GC is a good idea. I may be
>saying a stupid thing, since I'm not a GC expert, but I think objects that
>rely on having their destructors called the soonest possible for resource
>cleanup could use a refco
On Mon, 12 Feb 2001, Dan Sugalski wrote:
> Perl needs some level of tracking for objects with finalization attached to
> them. Full refcounting isn't required, however.
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just
Jan Dubois wrote:
> On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >Perl needs some level of tracking for objects with finalization attached
to
> >them. Full refcounting isn't required, however. Also, the vast majority
of
> >perl variables have no finalization attach
Sam Tregar wrote:
> On Mon, 12 Feb 2001, Dan Sugalski wrote:
> > Also, the vast majority of perl variables have no finalization
> > attached to them.
>
> That's true, but without static typing don't you have to treat them as if
> they did? At the very least you need to do a "is it an object with
[moved to -internals]
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Perl needs some level of tracking for objects with finalization attached to
>them. Full refcounting isn't required, however. Also, the vast majority of
>perl variables have no finalization attach
At 11:36 PM 2/11/2001 -0500, Sam Tregar wrote:
>On Sun, 11 Feb 2001, Jan Dubois wrote:
>
> > However, I couldn't solve the problem of "deterministic destruction
> > behavior": Currently Perl will call DESTROY on any object as soon as the
> > last reference to it goes out of scope. This becomes im
On Sun, 11 Feb 2001, Jan Dubois wrote:
> However, I couldn't solve the problem of "deterministic destruction
> behavior": Currently Perl will call DESTROY on any object as soon as the
> last reference to it goes out of scope. This becomes important if the
> object own scarce external resources (
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock"
<[EMAIL PROTECTED]> wrote:
>On Sunday 11 February 2001 19:08, Jan Dubois wrote:
>> However, I couldn't solve the problem of "deterministic destruction
>> behavior": Currently Perl will call DESTROY on any object as soon as the
>> last referen
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
> However, I couldn't solve the problem of "deterministic destruction
> behavior": Currently Perl will call DESTROY on any object as soon as the
> last reference to it goes out of scope. This becomes important if the
> object own scarce external
On Fri, 09 Feb 2001 13:19:36 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Almost all refcounting schemes are messy. That's one of its problems. A
>mark and sweep GC system tends to be less prone to leaks because of program
>bugs, and when it *does* leak, the leaks tend to be large. Plus the
At 04:53 PM 2/9/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > > If I change the way some objects are used so
> > > that I tend to create other objects instead of reusing the old ones, I'm
> > > actually not degrading GC performance, since its wo
Dan Sugalski wrote:
> At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > If I change the way some objects are used so
> > that I tend to create other objects instead of reusing the old ones, I'm
> > actually not degrading GC performance, since its work is proportional to
> > live data. Right?
>
> Cor
At 06:30 PM 2/9/2001 +, Nicholas Clark wrote:
>On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
> > The less memory you chew through the faster your code will probably be (or
> > at least you'll have less overhead). Reuse is generally faster and less
> > resource-intensive than re
On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
> The less memory you chew through the faster your code will probably be (or
> at least you'll have less overhead). Reuse is generally faster and less
> resource-intensive than recycling. What's true for tin cans is true for memory.
At 04:09 PM 2/9/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > > 2. Work proportional to live data, not total data. This is hard to
> > > believe for a C programmer, but good garbage collectors don't have
> > > to "free" every allocation
Dan Sugalski wrote:
> At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > 2. Work proportional to live data, not total data. This is hard to
> > believe for a C programmer, but good garbage collectors don't have
> > to "free" every allocation -- they just have to preserve the live,
> > or
At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
>Branden wrote:
> > I actually don't understand how traversing a graph can be faster than
> > incrementing/decrementing/testing for zero on a refcount.
>
>There are two main reasons advanced garbage collectors are fast:
>
> 1. Cheap allocations. Most fas
91 matches
Mail list logo
