> > Actually in my experience the sharing of memory doesn't work as well
> > as one would hope. While compiling perl allocates memory for code
> > and data (variables) from the same memory pools, so code and
> > variables are interlaced. Over the lifetime of a apache/mod_perl
> > child a lot of memory pages are promoted from shared to unshared that
> > contain mostly code and one or two variables... If someone with more
> > knowledge of the perl internals were to change that, this would make
> > a huge difference for mod_perl users and everybody else writing
> > daemons in perl that spawn many children.
Well... the structs for the "Code Values" are mixed with both code,
and variables in the case of Lexicals. However, during runtime these
are not altered. Their are structs within the main code value struct
that will be altered during run time, namely the recursive lexical
array. (That's what I call it, but I'm sure Malcolm uses a more
corect word :->) However, the actual Code (a series of highly
optimized opcodes... instruction set workalike type stuff that take a
few clockcycles each to do depending on the op and the architecture)
is not memory inline with the structs for the recursive lexical array.
What I'm saying is that if you include all your code at the very
begining the design of perl will not alter that code, so it should be
allowed to be fixed and shared. Basically it just holds an opcode
pointer as to which opcode its working at within the CV. The
recursive lexical array itself just has a pointer within the "code
value" struct to itself. So basically that main Code struct should
never need to be realloc'd so it's fairly unlikely that it would need
to be non-shared. However maybe someone that understands how
something is "unshared" within the kernel could be quite helpful. If
you were to change where something was pointing within a struct would
that cause it to be unshared? I think that it's fairly unlikely, but
I suppose it's possible. If that's the case then it's quite likely
that code pieces could become unshared I suppose. However the main
hunk of actual function opcodes would remain fixed, only the execution
pointer (where it's pointing at within the present program) would
change. So, in final (!) the code should always be shared. However
if you change the file and it checks the date on it and reloads it,
obviously it won't be shared :-).
> The Perl is a language that uses weak data types, i.e. you don't specify
> variable size (type) like you do in the strong typed languages like C.
> Therefore Perl uses heap memory by allocating memory on demand, rather
> (unmodifiable) text and (modifiable) data memory pages, used by C. The
> latter get allocated when the program is loaded into memory before it
> starts to run, the former is allocated at the run-time.
Yes that's true. There is some compile time stuff where it organizes
the variable names within the lexical array, but I'm not sure whether
or not it actually reserves space for those things at that time. I'm
really not sure about that item.
> On heap there is no separation for data and text pages, when you call
> malloc it just allocates you a chunk you have asked for, this leads to the
> case where the code (static in most cases) and the variables (dynamic)
> land on the same memory pages.
This is a weak area in my knowledge. I'm not certain how the kernel
actually marks segments as shared and not... so I'll refrain from
commenting.
> I'm not sure this a very good explanation. Perl gurus are very welcome to
> correct/improve my attempt to explain this.
I've tryed to explain what I can. The best book for this is "Advanced
Perl Programming"... published by Oreilly. (of course) There is a
chapter in there written by Malcolm Beatie (well pieces of the chapter)
that are pretty good..., but I'm afraid they might not go into enough
depth on these exact issues. Not only that, but these are also very
kernel related too..., you have to understand how both pieces fit
together, and frankly I couldn't answer that, and I don't know a
person alive that could :-). (I'm sure there are some, but who?)
Thanks,
Shane.
>
> But the main point is that that's how Perl is written, and I don't know
> whether it can be changed.
>
> ______________________________________________________________________
> Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
> http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
> ----------------------------------------------------------------------
>
>
>
