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

Re: Embedding Perl but redefining its malloc()

Thread Previous | Thread Next
From:
Raphael_Manfredi
Date:
September 26, 2009 14:09
Subject:
Re: Embedding Perl but redefining its malloc()
Message ID:
h9kr47$isa$1@tours.ram.loc
Quoting Steffen Mueller <nj88udd02@sneakemail.com> from ml.lang.perl.porters:
:(Raphael Manfredi) wrote:
:> I do not want to recompile perl with my own macros.  I want to link with
:> plain stock -lperl then use an API from the perl library to supersede the
:> memory allocation routines at runtime.
:> 
:> I take from your answer that this API does not exist today and would have
:> to be developped in order to do what I want.
:
: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.

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

Raphael

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About