At 8:59 AM +0100 5/1/05, sphillips wrote:
I have been enjoying the recent discussion of GC vs refcounting. Thanks.
While you're rehashing/justifying sensible design decisions made
years ago ;-) I was wondering why you decided to roll-your-own GC
rather than use an established one e.g. Hans Boehm
Sphillips <[EMAIL PROTECTED]> wrote:
>
> While you're rehashing/justifying sensible design decisions made years
> ago ;-) I was wondering why you decided to roll-your-own GC rather than
> use an established one e.g. Hans Boehm's.
Mainly two reasons: no one did try to implement e.g. Boehm GC with
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:19 AM +0200 4/30/05, Leopold Toetsch wrote:
>>BTW shouldn't we really separate C and C? The latter
>>would be overridable by user code, the former frees allocate memory.
> I can't really think of a reason to have two cleanup actions. Maybe
> I'm miss
Robin Redeker writes:
> On Sat, Apr 30, 2005 at 05:02:54PM -0400, Dan Sugalski wrote:
> > destroy. There's a vtable method that's called by the GC system when
> > an object is no longer reachable from the root set.
>
> Actually, not when, but some (indefinite) time after that has happened,
> righ
I have been enjoying the recent discussion of GC vs refcounting. Thanks.
While you're rehashing/justifying sensible design decisions made years
ago ;-) I was wondering why you decided to roll-your-own GC rather than
use an established one e.g. Hans Boehm's.
I ask this not because I have any cri
On Sat, Apr 30, 2005 at 05:02:54PM -0400, Dan Sugalski wrote:
> destroy. There's a vtable method that's called by the GC system when
> an object is no longer reachable from the root set.
Actually, not when, but some (indefinite) time after that has happened,
right?
> > And if so, what
> >would t
Hi!
Just a small question:
On Thu, Apr 28, 2005 at 04:37:21PM -0400, Dan Sugalski wrote:
> If you don't have the destroy, and don't tag the object as needing
> expedited cleanup, then the finalizer *will* still be called. You
> just don't have any control over when its called.
>
Will there be
At 9:19 AM +0200 4/30/05, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... We should probably make it 'safe' by forcing the
destroyed PMC to be an Undef after destruction, in case something was
still referring to it.
That sounds sane. Or maybe be: convert to an Undef and put
At 7:50 PM +0200 4/30/05, Robin Redeker wrote:
Hi!
Just a small question:
On Thu, Apr 28, 2005 at 04:37:21PM -0400, Dan Sugalski wrote:
If you don't have the destroy, and don't tag the object as needing
expedited cleanup, then the finalizer *will* still be called. You
just don't have any control
On Sat, 2005-04-30 at 09:19 +0200, Leopold Toetsch wrote:
> BTW shouldn't we really separate C and C? The latter
> would be overridable by user code, the former frees allocate memory.
I think that's wise and I thought that was the plan. Certainly for
*Struct PMCs I don't care when Parrot release
At 11:12 PM -0400 4/29/05, Bob Rogers wrote:
From: Dan Sugalski <[EMAIL PROTECTED]>
Date: Fri, 29 Apr 2005 15:23:47 -0400
At 10:55 PM -0400 4/28/05, Bob Rogers wrote:
>From: Robin Redeker <[EMAIL PROTECTED]>
>I'm astounded. Do neither of you ever design data structures with
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... For the most part, refcount O(n) time is
> proportional to the total number of objects created, while tracing
> O(n) time is proportional to the number of live objects.
Not quite. Refcount is O(work) or O(ptr-assign), which can be quite
different. Pyt
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>Not currently. There used to be a C opcode, but I've deleted
>>it, because I thought it's too dangerous.
> We really need to put it back in -- I knew it was dangerous, but it
> was necessary.
Yeah.
> ... We should probably make it 'safe' by forcing the
From: Dan Sugalski <[EMAIL PROTECTED]>
Date: Fri, 29 Apr 2005 15:23:47 -0400
At 10:55 PM -0400 4/28/05, Bob Rogers wrote:
>From: Robin Redeker <[EMAIL PROTECTED]>
>Date: Thu, 28 Apr 2005 00:12:50 +0200
>Refcounting does this with a little overhead, but in a fast and
At 10:55 PM -0400 4/28/05, Bob Rogers wrote:
From: Robin Redeker <[EMAIL PROTECTED]>
Date: Thu, 28 Apr 2005 00:12:50 +0200
Refcounting does this with a little overhead, but in a fast and
deterministic O(1) way.
This is the first half of an apples-to-oranges comparison, and so is
mislead
At 12:37 AM -0400 4/29/05, Uri Guttman wrote:
> "RR" == Robin Redeker <[EMAIL PROTECTED]> writes:
RR> I don't think circular references are used that much. This is
RR> maybe something a programmer still has to think a little bit
RR> about. And if it means, that timely destruction maybe
At 3:05 PM +0200 4/29/05, Leopold Toetsch wrote:
Gerald Butler <[EMAIL PROTECTED]> wrote:
Isn't there something like:
{
my $s does LEAVE { destroy $s } = new CoolClass;
# ... do stuff that may throw ...
}
Or something like that?
Not currently. The
Gerald Butler <[EMAIL PROTECTED]> wrote:
> Isn't there something like:
> {
> my $s does LEAVE { destroy $s } = new CoolClass;
> # ... do stuff that may throw ...
> }
> Or something like that?
Not currently. There used to be a C opcode, but I've deleted
it
On Fri, Apr 29, 2005 at 08:14:38AM -0400, Butler, Gerald wrote:
:
: Isn't there something like:
:
: {
: my $s does LEAVE { destroy $s } = new CoolClass;
: # ... do stuff that may throw ...
: }
:
: Or something like that?
Yes,it's
my $s will leave { d
Sent: Thursday, April 28, 2005 11:00 PM
To: perl6-internals@perl.org
Subject: Re: parrot and refcounting semantics
On Thu, 28 Apr 2005, Luke Palmer wrote:
> Or, with the "block hooks" that I keep claiming makes timely
destruction
> almost never needed, it is:
>
> {
>
> "RR" == Robin Redeker <[EMAIL PROTECTED]> writes:
RR> I don't think circular references are used that much. This is
RR> maybe something a programmer still has to think a little bit
RR> about. And if it means, that timely destruction maybe becomes
RR> slow only for the sake of collec
On Thu, 28 Apr 2005, Luke Palmer wrote:
> Or, with the "block hooks" that I keep claiming makes timely destruction
> almost never needed, it is:
>
> {
> my $s = new CoolClass;
> # ... do stuff that may throw ...
> LEAVE { destroy $s }
> }
>
> This destroys properly a
From: Robin Redeker <[EMAIL PROTECTED]>
Date: Thu, 28 Apr 2005 00:12:50 +0200
On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote:
> I agree with Dan completely here. People make such a big fuss over
> timely destruction when they don't realize that they don't really need
On Thu, 28 Apr 2005, Robin Redeker wrote:
> I don't think circular references are used that much.
Circular references are useful any time you need to be able to iterate
over a collection, and also have to identify which collection a given object
is in.
This may even be implicit from other require
On Thu, Apr 28, 2005 at 05:57:10PM +0200, Robin Redeker wrote:
> Just because refcounting is error-prone it doesn't mean that a garbage
> collector is better (and less error-prone).
I'm one of the maintainers of the perl5 core. perl5 is very mature, with
relatively few new features being added, an
At 7:24 PM +0200 4/28/05, Robin Redeker wrote:
I just wanted to correct my small example:
On Thu, Apr 28, 2005 at 05:00:53PM +0200, Robin Redeker wrote:
> Robin Redeker writes:
And with explicit resource handling (without timely destruction) it may be:
{
my $s = new CoolClass;
...
At 11:48 AM -0600 4/28/05, Luke Palmer wrote:
Robin Redeker writes:
This should actually be, to prevent the resource from leaking:
{
my $s = new CoolClass;
eval {
... do stuff that may throws ...
};
destroy $s;
}
Or, with the "block hooks" that I keep
Robin Redeker writes:
> This should actually be, to prevent the resource from leaking:
>
> {
> my $s = new CoolClass;
> eval {
> ... do stuff that may throws ...
> };
> destroy $s;
> }
Or, with the "block hooks" that I keep claiming makes timely destruction
I just wanted to correct my small example:
On Thu, Apr 28, 2005 at 05:00:53PM +0200, Robin Redeker wrote:
> > Robin Redeker writes:
> And with explicit resource handling (without timely destruction) it may be:
>
>{
> my $s = new CoolClass;
> ...
> destroy $s;
>}
This shoul
At 12:12 AM +0200 4/28/05, Robin Redeker wrote:
On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote:
Dan Sugalski writes:
> Also, with all this stuff, people are going to find timely destruction
> is less useful than they might want, what with threads and
> continuations, which'll screw
At 01:10 PM 4/28/2005, Dan Sugalski wrote:
At 5:57 PM +0200 4/28/05, Robin Redeker wrote:
On Wed, Apr 27, 2005 at 03:43:32PM -0400, Dan Sugalski wrote:
At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
The expense is non-trivial as well. Yeah, it's all little tiny bits
of time, but that adds up. I
At 5:57 PM +0200 4/28/05, Robin Redeker wrote:
On Wed, Apr 27, 2005 at 03:43:32PM -0400, Dan Sugalski wrote:
At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
>Just for the curious me: What was the design decision behind the GC
>solution? Was refcounting that bad? Refcounting gives a more global
>
On Wed, Apr 27, 2005 at 03:43:32PM -0400, Dan Sugalski wrote:
> At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
> >Just for the curious me: What was the design decision behind the GC
> >solution? Was refcounting that bad? Refcounting gives a more global
> >speed hit indeed, but it's more determinist
On Wed, Apr 27, 2005 at 03:59:05PM -0600, Luke Palmer wrote:
> Robin Redeker writes:
> > On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote:
> > > I think, more importantly, they don't understand what they're
> > > getting in return for giving [refcounting] up.
> >
> > Could you point out
Robin Redeker writes:
> On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote:
> > I think, more importantly, they don't understand what they're
> > getting in return for giving [refcounting] up.
>
> Could you point out what i get?
>
> I use TD is to handle resources: filehandles, database
On Wed, Apr 27, 2005 at 12:33:30PM -0600, Luke Palmer wrote:
> Dan Sugalski writes:
> > Also, with all this stuff, people are going to find timely destruction
> > is less useful than they might want, what with threads and
> > continuations, which'll screw *everything* up, as they are wont to do.
>
Dan Sugalski writes:
> Also, with all this stuff, people are going to find timely destruction
> is less useful than they might want, what with threads and
> continuations, which'll screw *everything* up, as they are wont to do.
> I know I've been making heavy use of continuations myself, and this i
Robin Redeker <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 27, 2005 at 02:27:58PM +0200, Leopold Toetsch wrote:
>> API's aren't finished yet and are extended more or less on demand.
> Ah, ok :) Who will decide what is demanded?
A patch on p6l is a good indication for a demand :)
> Hm, ok, i guess i
From: Dan Sugalski <[EMAIL PROTECTED]>
Date: Wed, 27 Apr 2005 15:43:32 -0400
At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
>Just for the curious me: What was the design decision behind the GC
>solution? Was refcounting that bad? . . .
I'll answer this one, since I'm the one res
At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
Just for the curious me: What was the design decision behind the GC
solution? Was refcounting that bad? Refcounting gives a more global
speed hit indeed, but it's more deterministic and you wont run into
(probably) long halts during GC. (Java programs
On Wed, Apr 27, 2005 at 02:27:58PM +0200, Leopold Toetsch wrote:
> Robin Redeker <[EMAIL PROTECTED]> wrote:
[...]
> > Any hints when looking for functions that 'maybe' go into the API?
>
> API's aren't finished yet and are extended more or less on demand.
>
Ah, ok :) Who will decide what is dema
Robin Redeker <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 27, 2005 at 08:09:48AM +0200, Leopold Toetsch wrote:
>> albeit it isn't part of the official embedding API (yet).
> Ok, thanks, i'll have a look at that.
> Any idea when there will be a more complete official embedding API?
> Any hints when l
On Wed, Apr 27, 2005 at 08:09:48AM +0200, Leopold Toetsch wrote:
> Robin Redeker <[EMAIL PROTECTED]> wrote:
[...]
> > 1. i wonder how to load bytecode from the memory to parrot when
> > embedding it. i've read embed.pod and couldn't find a function that let me
> > create a packfile or something i c
Robin Redeker <[EMAIL PROTECTED]> wrote:
> Hello!
> The last weeks i've been in joy to implement a small vm for a
> special runtime enviroment. As i'm a regular reader of the perl.perl6.*
> mailing lists and know about parrot. I wondered how easy it would be
> to throw away my own vm solution and
Hello!
The last weeks i've been in joy to implement a small vm for a
special runtime enviroment. As i'm a regular reader of the perl.perl6.*
mailing lists and know about parrot. I wondered how easy it would be
to throw away my own vm solution and use parrot.
There are currently only two things th
45 matches
Mail list logo
