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

On Fri Feb 26 04:01:10 2016, bulk88 wrote:
> 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.

test prog: perl -MTest::Harness -MTest::More -e"sleep 1000"

summary: 8-12 ms of CPU are saved in PP compile time and 280 KB of heap memory

raw data:

after (head of my branch) 5216 KB Private Bytes (heap-ish memory on Win32)

C:\p523\src>timeit -f t.dat  perl -MTest::Harness -MTest::More -e"0"

Version Number:   Windows NT 6.1 (Build 7601)
Exit Time:        11:31 am, Friday, February 26 2016
Elapsed Time:     0:00:00.189
Process Time:     0:00:00.187
System Calls:     4096
Context Switches: 994
Page Faults:      2245
Bytes Read:       758340
Bytes Written:    484
Bytes Other:      9440

C:\p523\src>timeit -f t.dat  perl -MTest::Harness -MTest::More -e"0"

Version Number:   Windows NT 6.1 (Build 7601)
Exit Time:        11:31 am, Friday, February 26 2016
Elapsed Time:     0:00:00.187
Process Time:     0:00:00.156
System Calls:     4419
Context Switches: 1045
Page Faults:      2505
Bytes Read:       758032
Bytes Written:    176
Bytes Other:      9584

C:\p523\src>timeit -f t.dat  perl -MTest::Harness -MTest::More -e"0"

Version Number:   Windows NT 6.1 (Build 7601)
Exit Time:        11:31 am, Friday, February 26 2016
Elapsed Time:     0:00:00.185
Process Time:     0:00:00.187
System Calls:     3549
Context Switches: 999
Page Faults:      2267
Bytes Read:       758032
Bytes Written:    176
Bytes Other:      9512

C:\p523\src>

b4 (last blead commit) 5496 KB Private Bytes (heap-ish memory on Win32)

C:\p523\src>timeit -f t.dat  perl -MTest::Harness -MTest::More -e"0"

Version Number:   Windows NT 6.1 (Build 7601)
Exit Time:        10:58 am, Friday, February 26 2016
Elapsed Time:     0:00:00.198
Process Time:     0:00:00.202
System Calls:     5571
Context Switches: 1114
Page Faults:      3379
Bytes Read:       761106
Bytes Written:    264
Bytes Other:      9512

C:\p523\src>timeit -f t.dat  perl -MTest::Harness -MTest::More -e"0"

Version Number:   Windows NT 6.1 (Build 7601)
Exit Time:        10:58 am, Friday, February 26 2016
Elapsed Time:     0:00:00.197
Process Time:     0:00:00.187
System Calls:     5328
Context Switches: 964
Page Faults:      2641
Bytes Read:       758512
Bytes Written:    132
Bytes Other:      9604

C:\p523\src>timeit -f t.dat  perl -MTest::Harness -MTest::More -e"0"

Version Number:   Windows NT 6.1 (Build 7601)
Exit Time:        10:58 am, Friday, February 26 2016
Elapsed Time:     0:00:00.190
Process Time:     0:00:00.187
System Calls:     3769
Context Switches: 926
Page Faults:      2524
Bytes Read:       758704
Bytes Written:    344
Bytes Other:      9512

C:\p523\src>


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