Front page | perl.perl5.porters |
Postings from January 2016
On Thu Jan 28 15:01:20 2016, perl.p5p@rjbs.manxome.org wrote: > * bulk88 via RT <perlbug-followup@perl.org> [2015-08-15T22:04:29] > > Bump. > > Bump. :-) > > I've had this ticket flagged for a long time. I think it's reasonable > for us > to be cautious in the face of no expertise, but right now it seems > like "we're > not sure what's up, so we're doing nothing." > > I wonder whether we're not better off trying it and seeing, lest this > patch > languish forever. Alternately, would someone like to work on becoming > an > expert on this area? :) This patch series is sort of a precursor to sharing HEKs between ithreads. I have to review what cperl does and if rurban came up with his own solution or not and what can be borrowed from it if it exists, but a COP's filename (used for all warning messages and perl debugger) is currently allocated, with threads, one malloc block per COP. That is insane. It means something like 25 bytes of overhead (lets round it to 32 or 64 bytes with malloc header), for almost EVERY line of perl source code with threads (lines that you can't set a breakpoint on, have no COP op and therefore no file name). My initial plans for shared filenames, which are probably best implemented as a being a derivative of a HEK with a refcount as a struct field, with most of the fields being compatible with HEKs. struct refcounted_he, which looks like a "shared" rip off a SV looks too heavy weight. Filenames are always strings, not IVs. Storing a filename as a "dualvar" is insane. Who has a perl source code file, name "1"? Yes, no .pl, no .pm. Just a file called "1" on disk. This part of taming source code file names in threaded perl got tamed, http://perl5.git.perl.org/perl.git/commit/9b669ea1e2997fbb78558e1fc0a7ecae3aa23af0 but http://perl5.git.perl.org/perl.git/commit/9b669ea1e2997fbb78558e1fc0a7ecae3aa23af0 was a part of a number of ideas I had. Shared HEKs are also best implemented (but not necessarily first implemented) with atomic CPU op refcounts, instead of the current MUTEX_LOCK APIs in thread.h that use OS specific mutex function calls instead of CPU atomic instrinics. A global mutex for all SHEK opcounts is the first step, like a number of other things in perl core that would be best done with atomics but instead are done with a global mutex for changing the count of a particular instance of a global struct. I have a patch to add CC atomics to perl that I never finished. -- bulk88 ~ bulk88 at hotmail.com --- via perlbug: queue: perl5 status: open https://rt.perl.org/Ticket/Display.html?id=125569Thread Previous | Thread Next