* Tomas Doran <[email protected]> [2012-01-25 16:05]: > (As perl is interpreted, your perl code lives in 'data' pages, rather > than executable pages - so you don't and can't get the same memory > sharing you can in C - where the code pages are always shared with > your child processes - as you're executing the same program... > > Or, rather - you do get exactly the same semantics - the perl binary > itself, and any shared objects (.so files) you have loaded in the > parent will be shared with children forever - but this is generally > a small proportion of your memory use, compared to your perl code and > data structures, which all live in 'data' pages - meaning that your > program running causes static perl code in data pages to become > unshared..
There is an accessible explanation of this here: http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html In other notes, I have seen weblog posts (maybe from Reini Urban, but I do not recall for certain) discuss the possibility of restructuring the Perl op tree such that the op data that needs to be mutable is stored separately in memory from that which never changes. That would allow forked Perl programs to not inevitably slowly grow unshared over time, just as C programs don’t. But I understood it to be a non-trivial undertaking (much though a feasible one). Maybe someday perl will be implemented that way. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
