|
From: Julian S. <js...@ac...> - 2006-06-15 10:54:04
|
On Thursday 15 June 2006 00:23, Nicholas Nethercote wrote:
> On Wed, 14 Jun 2006, Eric Li wrote:
> > But the inline comments for LibVEX_Alloc(where the mem for the above IRBB
> > came from) say that the temporary storage this grants will only stay
> > alive until translation of the current BB is complete. This implies that
> > I can't just save irbb, and that I need to make a copy of it. I saw that
> > there is a deep copy constructor, dopyIRBB, but the memory for that also
> > comes from LibVEX_Alloc. So my question is is the only way to get back a
> > usable copy of the irbb to write my own deep copy constructor that
> > doesn't rely on LibVEX_Alloc?
>
> Hmm, as far as I know. Julian might know otherwise.
Your analysis is correct.
You are of course free to replace LibVEX_Alloc with a different
allocation function more suited to your purposes, and this seems
a lot less hassle than rewriting all the constructors. One possibility
is to make it able to allocate in one of a number of different
blocks, by consulting some global variable which you add. Then
what you can do is, first make the IR translation into some
temporary block. Then switch blocks and do a deep copy, which
gets you the copy into a block you can keep hold of permanently.
The problem with just using malloc is that there are no
corresponding free-the-IR functions, and the JIT allocates
very fast, so you soon wind up running out of memory. Really
it's based around the idea of allocating fast from a big block,
then throwing the whole block away when dead ("arena allocation")
which is nicely explained in the Fraser and Hanson book about
retargetable compilers, and also in Hanson's C-I-I book
(http://www.cs.princeton.edu/software/cii)
J
|