[perl #125296] CvFILE on threaded, and gv_fetchfile on all perls,burn mad memory

On Wed Feb 17 01:28:34 2016, davem wrote:
> I feel I would better be able to provide feedback if you were to give
> an
> outline description of what approach your WIP branch takes. I.e. I
> understand (roughly) that on ithreads, every COP gets a copy of the
> filename, while non-threaded share a GV; and (very vaguely) that in
> some
> way the GV has a name like '<_filename' which is needed by the
> debugger,
> and that threaded build recreate the GV in some way.

http://perl5.git.perl.org/perl.git/commitdiff/345d4464184a234301341596f73ee2d3550c9799#patch8

+/* A CHEK is a derived class of HEK, and struct shared_he is also a derived
+ * class of HEK. This makes a CHEK and struct shared_he be sibling classes today.
+ * Provisions exist that would allow struct shared_he to be a derived class of
+ * a CHEK once atomic refcount features are added to perl.
+ * Like a HEK *, a CHEK * is an immutable string. bulk88 decided that
+ * struct refcounted_he is too heavy weight and too specialized to be a
+ * inter-interp "string class" (HEs always have 2 strings conceptually, 1
+ * string has obviously 1 string).
+ *
+ * CHEKs are currently only used to store filepaths that point to original PP
+ * or XS source code files of PP resourses. A CHEK is "stored in the optree".
+ * In reality it is shared between ithreads and psuedoforks and is allocated in
+ * process global memory (like optrees), not in per interp memory. In theory the
+ * CHEK can be used to store other strings between ithreads but that is not done
+ * ATM. Perhaps one day the Newx PV buffers in the PAD SVs of OP_CONST will be
+ * replaced by CHEKs and shared between ithreads, the SV*s and PADs cant be the
+ * same obviously between ithreads.
+ */

> How does your solution work, and how (if at all) does it interact with
> or
> change other parts of perl?

There are no changes to public API except removal of GvFILE_HEK macro. HEKs are not public API, and have never been mentioned in perlguts. Therefore CHEKs are not public API. I did not touch any of the structs of unthreaded perl on purpose. Perhaps one day the threaded CHEK system will be used on unthreaded perl, without any lock acquire/release cycles done on the refcount of the CHEK, and the CHEK being allocated in per interp memory with unthreaded perl obviously.

PP __FILE__, CopFILE, CvFILE on const subs, GvFILE on GP *s, and PP caller all use CHEK *s now in threaded perl. In a perl proc memory dump, you wont find a "_<"-less path string in the process that is identical to a "_<" prefixed path string. I caught all of them and converted them to CHEKs.

CHEKs DO NOT live in PL_strtab due my fears over lock contention between different ithreads. I'd have to lock all operations with the PL_strtab hash or have many fine scope lockable HvARRAY elements and then a master https://msdn.microsoft.com/en-us/library/windows/desktop/aa904937%28v=vs.85%29.aspx (and port that MS code to unix) lock to control hash splitting. Some OSes, especially unixy ones do all locks with kernel mode transitions, user mode locks using atomic CPU features are rare or unheard of unlike MS land. There is no de-duping of CHEKs from a PV arg and LEN arg like with SHEKs.

http://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/bulk88/rt125296-wip-COPFILE-threads branch is now almost, or is feature complete (last issue is static or static const HEKs and CHEKs for B::CC style compiled code I need to bring up in a separate P5P ML thread and that involves discussion P5P's hash seed design and I dont think CHEKs or seed changes will get in for 5.24 since there is a code freeze for user visible (but CHEKs aren't visible, maybe there is hope), but seed changes will have drama). The branch is missing all abstraction macros, and proper names for the APIs and macros. My CS names are poor everywhere so I dont want to name things just for it to be suggested to something else. When I cant think of var names, I start naming macros and vars after my cats. ppl feel free to suggest API names and macro names. Also should the code be "#ifdef USE_ITHREADS" or a different name all together, so you can use it on threaded and unthreaded as a build option if 
 you choose.

I still dont know whether to call my API a CHEK, FHEK, PHEK, PHKS, or SPHEK.

-- 
bulk88 ~ bulk88 at hotmail.com

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

• [perl #125296] CvFILE on threaded, and gv_fetchfile on all perls,burn mad memory by Tony Cook via RT
• [perl #125296] CvFILE on threaded, and gv_fetchfile on all perls,burn mad memory by bulk88 via RT
• [perl #125296] CvFILE on threaded, and gv_fetchfile on all perls,burn mad memory by bulk88 via RT
• Re: [perl #125296] CvFILE on threaded, and gv_fetchfile on allperls, burn mad memory by Dave Mitchell
• [perl #125296] CvFILE on threaded, and gv_fetchfile on all perls,burn mad memory by bulk88 via RT