develooper Front page | perl.perl5.porters | Postings from February 2003

Re: New SV Flag

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 10, 2003 12:53
Subject:
Re: New SV Flag
Message ID:
20030210203812.GA289@Bagpuss.unfortu.net
On Mon, Feb 03, 2003 at 01:14:59AM +0100, Arthur Bergman wrote:
> Hi,
> 
> I would like a new SV flag, or SV flag combination that means, this SV 
> does not live on the arenas and should not be PL_sv_counted, a hint to 
> sv_free not to plant this sv again.
> 
> I would like all SVs that are living in the optree to be of this kind, 
> this would allow us to move constants out of the pad and let them be 
> PVMG so they can't be upgraded anymore, same applies for the 
> METHOD_NAMED SvPVIV.

What do METHOD_NAMED SvPVIV look like? Do they end up as shared hash key
scalars, because they (often) get used for hash lookup?

> An alternative would be to store all these in a global pad like the 
> regex pad to allow shaving down on memory usage.

On Mon, Feb 10, 2003 at 08:59:45PM +0100, Arthur Bergman wrote:

> I think the check is there for objects that have DESTROYS that increase 
> the refcount, there should be a test for this!

<AOL>

> I think that by letting my magic increase the refcount, free the 
> original body, set a fake body, and then return and put the head in a 
> free list to be reused.
> 
> So no flag needed! Thanks.

Why do you want to do this? I presume it relates to ithreads. Is the idea to
make scalars used in the optree common to all threads, so that they don't
need copying on ithread creation?

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About