On Sunday 11 February 2001 22:48, Jan Dubois wrote:
> Doing full GC in this fashion after failed API calls will probably wipe
> out any performance gain mark-and-sweep has over reference counting.
Well, after select failed API calls, not every call. And mark-and-sweep,
if that's the GC scheme u
On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
>
> >On the other side, for a string that is matched against regexps, it doesn't
> >matter much if it has variable character length, since regexps normally read
> >all the string anyway, and indexing characters isn't much of a concern.
[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
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
How much can we do in the compiler, and how much can we do in the
interpreter? If we're having cached bytecode, it makes sense to do
as much optimization as we can in the compiler. If not, we might
as well brute force things to conserve compilation time. Or should
this be user-selectable with "us
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
Simon Cozens wrote:
> How much can we do in the compiler, and how much can we do in the
> interpreter? If we're having cached bytecode, it makes sense to do
> as much optimization as we can in the compiler.
I thought, by PDD 1
(http:[EMAIL PROTECTED]/msg02116.html), it
was:
SOURCE CODE
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
Alan Burlison wrote:
> Branden wrote:
> > Any suggestions?
> Yes, but none of them polite.
> You might do well to study the way perl5 handles these issues.
Perl 5 basically clones on every assignment. As it uses refcounting, it
knows it doesn't need to clone a string if its refcount=1 and it's ma
On Monday 12 February 2001 12:40, Branden wrote:
> Probably Perl 6 programs will be cached/distributed in optimized byte code
> format.
I'm not sure about the leading 'probably'. Perl 6 programs will most likely
be like most other open-source programs in other languages - either source,
which
On Mon, 12 Feb 2001 15:18:47 -0300, "Branden" <[EMAIL PROTECTED]>
wrote:
>Alan Burlison wrote:
>> Branden wrote:
>> > Any suggestions?
>> Yes, but none of them polite.
I do think this rudeness is uncalled for.
>> You might do well to study the way perl5 handles these issues.
>
>Perl 5 basically
On Mon, 12 Feb 2001 16:13:10 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
>How much can we do in the compiler, and how much can we do in the
>interpreter? If we're having cached bytecode, it makes sense to do
>as much optimization as we can in the compiler. If not, we might
>as well brute forc
At 11:16 AM 2/12/2001 +, Tim Bunce wrote:
>On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
> >
> > >On the other side, for a string that is matched against regexps, it
> doesn't
> > >matter much if it has variable character length, since regexps
> normally read
> > >all the str
At 12:25 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
>On Monday 12 February 2001 12:40, Branden wrote:
> > Probably Perl 6 programs will be cached/distributed in optimized byte code
> > format.
>
>I'm not sure about the leading 'probably'. Perl 6 programs will most likely
>be like most other open
At 09:34 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 16:13:10 +, Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> >How much can we do in the compiler, and how much can we do in the
> >interpreter? If we're having cached bytecode, it makes sense to do
> >as much optimization as we can
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
Jan Dubois wrote:
> >Perl 5 basically clones on every assignment. As it uses refcounting, it
> >knows it doesn't need to clone a string if its refcount=1 and it's marked
as
> >temporary, i.e., only a temporary that will go away anyway knows about
this
> >string, so it's guaranteed no other referen
At 04:21 PM 2/12/2001 -0300, Branden wrote:
>Jan Dubois wrote:
>You point out two disadvantages:
>
> > - It steal 2 bits from the SvTYPE flags. Flags are a *very* scarce
> > resource and shouldn't be used up unless there are very good reasons
> > for it.
> >
> > - Using shared strings is not
At 04:13 PM 2/12/2001 +, Simon Cozens wrote:
>How much can we do in the compiler, and how much can we do in the
>interpreter? If we're having cached bytecode, it makes sense to do
>as much optimization as we can in the compiler. If not, we might
>as well brute force things to conserve compilat
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
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
Dan Sugalski wrote:
> ...
> doing software copy-on-write stuff, along with having to make the garbage
> collector smart enough to deal with multiple PMCs pointing to identical
memory.
???
I thought that was the big deal of GC! Dealing with many references to the
same thing and free the thing whe
At 04:57 PM 2/12/2001 -0300, Branden wrote:
>Dan Sugalski wrote:
> > ...
> > doing software copy-on-write stuff, along with having to make the garbage
> > collector smart enough to deal with multiple PMCs pointing to identical
>memory.
>
>???
>
>I thought that was the big deal of GC! Dealing with
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 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
25 matches
Mail list logo