Front page | perl.perl5.porters |
Postings from August 2011
Re: Mutable constant-expression values
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
August 13, 2011 22:20
Subject:
Re: Mutable constant-expression values
Message ID:
9F3E9E18-CA4C-4859-9D49-7FD8D23FE3D7@cpan.org
On Aug 13, 2011, at 3:40 AM, Nicholas Clark wrote:
> On Sun, Jul 24, 2011 at 01:53:15PM -0700, Father Chrysostomos wrote:
>> Nicholas Clark wrote:
>
>>> One can't do it trivially that way without breaking existing semantics.
>>> Internally, scalars are passed around as (RVALUE) pointers to (LVALUE)
>>> SV structures. Effectively, at the C level, everything is a form of
>>> reference, and C code has to work on the scalar in place.
>>>
>>> Currently the C code croaks if what is has been passed is read-only.
>>> If one wanted to change to the C code to on-demand create a new read-write
>>> copy of a read-only value, then every function would have to have a way to
>>> return a new SV * address of each of its operand that "moved".
>>>
>>> If instead one wanted to keep the current C APIs, and replace the "croak on
>>> read only" check with a "cheap COW copy of the value", keeping the same
>>> SV * address, then one would have to change how constants are put onto the
>>> Perl stack. Currently the address of the SV stored in the optree (1 pointer)
>>> is placed on the Perl stack, without any refcounting:
>>>
>>> PP(pp_const)
>>> {
>>> dVAR;
>>> dSP;
>>> XPUSHs(cSVOP_sv);
>>> RETURN;
>>> }
>>>
>>> To allow mutation, even by copy-on-write, then the above code would have to
>>> change to allocate a new SV * (each time), which would be quite a performance
>>> hit, given that each newly allocated SV would also have to be stored on the
>>> mortal stack to ensure that it was cleaned up at the end of the statement.
>>
>> What about marking SVs in the op tree with the PADTMP flag?
>
> That doesn't solve any of the above problems. pp_const would still be pushing
> the same SV * pointer onto the Perl stack each time.
Which would then be copied by refgen.
>
> One still has to either
>
> a: change pp_const to create a new SV head, so that C functions are able to
> modify that SV without changing the one in the optree.
>
> or
>
> b: keep the SV on the stack the same, but change C functions to return a
> result SV, which may be different from the passed-in SV
>
> The problem isn't the flags on the SV. The problem is that the memory address
> passed around is that of the (master constant) SV in the optree.
Thread Previous
|
Thread Next