develooper Front page | perl.perl5.porters | Postings from September 2012

[perl #114820] Bleadperl v5.17.3-255-g6502e08 breaks SARTAK/Path-Dispatcher-1.04.tar.gz

Thread Next
From:
Father Chrysostomos via RT
Date:
September 17, 2012 21:45
Subject:
[perl #114820] Bleadperl v5.17.3-255-g6502e08 breaks SARTAK/Path-Dispatcher-1.04.tar.gz
Message ID:
rt-3.6.HEAD-11172-1347943493-1140.114820-15-0@perl.org
On Mon Sep 17 14:06:19 2012, nicholas wrote:
> On Tue, Sep 11, 2012 at 12:41:25PM -0700, Father Chrysostomos via RT
> wrote:
> > On Tue Sep 11 06:04:53 2012, davem wrote:
> > > On Mon, Sep 10, 2012 at 03:52:15PM -0700, Father Chrysostomos via
> RT
> > > wrote:
> 
> > > > So I gave up on the whole thing, because even though it seemed
> about
> > > the most
> > > > lightweight approach possible, I still couldn't get it to the
> point
> > > where it
> > > > was measurably faster than not doing it, and it added complexity
> to
> > > the
> > > > (runtime) code, and it looked like it had a risk of subtly
> breaking
> > > CPAN code.
> > > > This was all quite frustrating.
> > >
> > > Which I read as indicating there were subtle and risky issues.
> >
> > I think this part reasonably solves that:
> >
> > > (The idea only came later of using #ifdef PERL_CORE in the
> > > headers to avoid doing COW copies in XS code, after I'd concluded
> that I
> > > couldn't get (general) COW to be fast enough.)
> 
> It still doesn't solve the test failures in one of the Compress::Zlib
> modules.
> (Didn't check thoroughly as to why, but one still failed when I got
> PERL_OLD_COPY_ON_WRITE compiling again a couple of days ago)
> 
> In particular, I remember the frustration that led to this comment in
> Perl_sv_gets:
> 
>     /* XXX. If you make this PVIV, then copy on write can copy scalars
> read
>        from <>.
>        However, perlbench says it's slower, because the existing swipe
> code
>        is faster than copy on write.
>        Swings and roundabouts.  */
>     SvUPGRADE(sv, SVt_PV);
> 
> 
> The swipe code seems to be very effective. However, I don't totally
> like it
> because it relies on SvTEMP() meaning "I can steal the buffer". Which
> isn't
> always true.

Are you referring to the use of _nosteal here and there, or are you
unaware that the swipe code checks for a refcount of 1?

> 
> 
> But I had a thought about an alternative COW mechanism, exploiting the
> OOK mechanism.

...snip details...

That is just brilliant!

> But it would permit a very cheap way to allocate PVs such that they
> could
> be "copied" - the overhead would be just 1 byte.

That’s a lot smaller than allocating a shared_he (20 bytes on a 32-bit
machine), something I tried to do.

> And it feels much cheaper to undo this COW than the old scheme's
> pointer
> loop chasing.
> 
> It might be cheap enough to use everywhere when creating strings, and
> thus
> actually get rid of the swipe code.
> 
> I'm also wondering if it's complementary with the other COW approach.
> That one doesn't need to move the contents of an existing buffer

I may have misunderstood, but it doesn’t sound as though your 1-byte
flag method needs that either, if that extra byte is allocated at the
outset.

> (so
> better
> for long strings), but does need to upgrade the SV body to PVIV, and
> does
> need to chase the pointer loop on release.
> 
> However, I'm still wary of the Compress::Zlib test failure, as an
> indicator
> that I didn't manage to anticipate every problem.

It is probably doing something naughty. :-)

> 
> Also, I'm thinking that we ought to get rid of the (ab)use of
> SvREADONLY()
> to mean two things - "This is a readonly value" and "you can't write
> to
> the buffer that SvPVX() points to". It would be better to have two
> flags.

What about existing XS code that checks SvREADONLY before modifying
SvPVX?  (Is there any?  Most XS code I’ve seen does a terrible job of
handling perl’s types.)

The flag space is rather crowded.  Maybe it’s about time we made pad
names their own type.  Their being SVs makes SVs themselves more
complicated.  A dedicated pad name type would also allow the name to be
allocated as part of the same memory block, much like a hek.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=114820

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