develooper Front page | perl.perl5.porters | Postings from September 2009

Re: Embedding Perl but redefining its malloc()

Thread Previous | Thread Next
Steffen Mueller
September 27, 2009 02:45
Re: Embedding Perl but redefining its malloc()
Message ID:
Hi Raphaelm

(Raphael Manfredi) wrote:
> Quoting Steffen Mueller <> from ml.lang.perl.porters:
> :I wonder whether such an API wouldn't slow down the malloc routine 
> :because it would have to check for user-supplied implementations. But 
> :then again, I'm not known to be particularly clueful in all things C.
> The impact would be completely negligible.  The only thing that is required
> is that a table of function pointers to malloc(), realloc() and free() be
> maintained by Perl and each time you want to perform a memory operation, you
> dereference the pointer from this table.
> Since these would be used fairly frequently, chances are the addresses there
> would be in the CPU cacheline from one of the L1, L2 or even L3 caches.
> Compared to the work that a malloc() routine or a free() routine has to do
> anyway, the extra dereference impact will not be noticeable.

That may well be.

> :Quoting perlvars.h:
> :PERLVARI(Grevision,     U8,     PERL_REVISION)
> :PERLVARI(Gversion,      U8,     PERL_VERSION)
> :PERLVARI(Gsubversion,   U8,     PERL_SUBVERSION)
> So accessing the PL_revision variable from C would give me access to Grevision?

That is my understanding: embed_vars.h has PL_revision and PL_Grevision 
both defined to the above Grevision.



Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About