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

Re: New SV Flag

Thread Previous | Thread Next
From:
Arthur Bergman
Date:
February 11, 2003 00:07
Subject:
Re: New SV Flag
Message ID:
E51AB325-3D97-11D7-A2D3-003065D64CBE@contiller.se

On måndag, feb 10, 2003, at 21:38 Europe/Stockholm, Nicholas Clark 
wrote:

> 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?
>

I thought all strings wound up in the shared string table?
They are SvPVIV with the PV being the method name and the IV being the 
hash.


>> 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>
>

America Online?

>> 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?
>

Yes, they only get created and destroyed when opcodes get created and 
destroyed, and that is protected by a mutex.

I am also going to try and see if you can't get shared semantics with 
split sv headers and shared bodies. If one preupgrades to SvPVMG then 
there is no way perl can upgrade anymore. This would allow us to speed 
up shared scalars alot.

Arthur


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