Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> If the object was moved and the d_reloc is now updated by MPS I've a
> doubt:
>
> What if our object (say d_reloc[x]) is loaded in a register by the
> compiler?  How does the register gets updated by MPS?  In native code we
> do this all the time for performance reasons.

MPS traces registers and control stacks as ambig roots, so a reference
from there makes the corresponding object immovable.

>> Next strategy or tactic, I think, could be to produce a C file for
>> macroexp.eln, and see where the symbol appears. I would imagine that I
>> can deduce from the text representaton of the constants in C what index
>> correspondons to the symbol, and then see if it is used in surprising
>> ways. Maybe. WDYT?
>
> You'll probably see what I mentioned above.  At the beginning of the
> compiled function we load in regular variables the lisp objects from
> d_reloc so GCC leverage the register allocater and keep in registers.

Yep, I see that.

> For instance we do exactly this 'byte-compile-form-stack' and others
> here:
....
>   /* byte-compile-form-stack */
>   slot_3 = d_reloc[(long long)1];

Haha, I hadn't even remotely occurred to me that you would emit a
comment with the name :-). That makes things a lot easier. 👍

> I think the easiest is to to make objects loaded from native code non
> movable.  Is this possible with MPS? What would be the downside of this?
> They are very rarely collected anyway.  WDYT?

I'd personally prefer to trace comp units in the usual way for Lisp
objects, i.e. the fix_comp_unit.

Main reason is simplicity. The tracing function is super simple, we only
have to identify where in the comp unit data structure, or dylib,
references exist that have to be traced. Registers/stack are not a
problem (see above).

Other reasons, not so important, but anyway, is reducing the number of
roots. Every root adds to what MPS has to do. And ambig roots make
objects immovable, which is somewhat against the spirit of a copying
collector.

Just my personal opinion, of course.