Re: MPS codegen

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Helmut Eller <eller.helmut@gmail.com> writes:

>>> The win would be that no code for copying and mirroring would be needed.
>>> One downside would be that the hot and cold section end up in the same
>>> pool.
>>
>> Then I didn't understand what you meant. How would you avoid the
>> copying? I don't remember seeing something in the MPS docs by which one
>> could let it manage a area of memory the user can allocate or specify.
>
> The idea is simply to do something like dump_mmap_contiguous_heap.
> Instead of malloc'ing the contiguous chunk of memory use mps_reserve.
> After the pdumper has done the usual relocations call mps_commit.

Ah, that's an intersting idea!

> (It might not work out quite like this because the pdumper wants to
> allocate something too early, ie. before the mps_commit. But that's the
> basic idea.)

Maybe one could reserve + commit a suitable block upfront, maybe as one
big IGC_OBJ_PAD, and use read(2) or so to read the .pdmp into that
block.

One problem would be to make the whole thing digestable for the object
format. And maybe one would loose the ability to use the leaf pool for
some objects in the dump. But maybe that's not a big deal. MPS then
calls the scan method which does nothing, but that should be the whole
overhead, I guess.

If one could get rid of the mirroring code, that would be a big
advantage :-)!

> The crucial bit that I'm unsure about is if mps_reserve can be used to
> allocate many objects in this way.

I think it can. But the proof is in the pudding, of course :-).