develooper Front page | perl.perl5.porters | Postings from March 2016

Re: [perl #125296] CvFILE on threaded, and gv_fetchfile on allperls, burn mad memory

Thread Previous | Thread Next
Dave Mitchell
March 9, 2016 16:40
Re: [perl #125296] CvFILE on threaded, and gv_fetchfile on allperls, burn mad memory
Message ID:
On Fri, Feb 26, 2016 at 04:01:11AM -0800, bulk88 via RT wrote:
> > How does your solution work, and how (if at all) does it interact with
> > or
> > change other parts of perl?
> [stuff]

I'm sorry, I'm finding your descriptions *really* hard to follow.

What I would really appreciate is an overall "big picture" description
of what your solution is, rather than a mess of detail.

As I understand it, the issue is that at the moment on threaded builds,
every COP for all code compiled from a particular src file contains a
pointer to a malloc()ed copy of the current src filename. This results in
much duplication.

So you have a solution that aims to reduce this duplication, by sharing
the filename strings across most (all) COPs in a file. Is this right?

This sharing is done using a structure called a CHEK, which is basically
a HEK (which contains a string, a length and a hash) plus a reference
count. Is this right?

So some questions which immediately occur to me:

* How is the de-duplication done?

* how is change of filename handled, e.g. C<#line 100 "foo">?

* HEK's are normally stored in hashes. Are CHEKs stored in hashes too?

* If so, what hash, and where is this hash stored?

* Also if so, how is this hash accessed across threads?

* If not, why is it a CHEK rather than something unassociated with hashes?
  And what is the hash value then used for?

You live and learn (although usually you just live).

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About