Re: MPS: native comp

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>>
>>>>> Then, in some way Andrea sets up Lisp_Objects for what we have in the
>>>>> dylib when it is loaded and these land in data_vec.
>>>>
>>>> And that's exactly what's going on, from reading the code.
>>>> load_static_obj gets a pointer to text represention of Lisp data in the
>>>> dylib, and then uses Fread to make Lisp_Objects from that.
>>>>
>>>> Scratchign head...
>>>
>>> Hm, maybe...
>>>
>>> @Andrea: How are the Lisp_Objects created in load_static_obj referenced
>>> from the code? There must be a step that puts them into the machine
>>> code, right? Probably the "relocs" that are used there.
>>>
>>> If that's the case (and I'm almost sure), then we need to make these
>>> objects immovable.
>>>
>>> That was a nice puzzle!
>>
>> Oh yes that's correct! If MPS wants to move objects referenced in ELN
>> files it needs to update what every elns has in his own data_relocs
>> array!  (Or make them immovale indeed).
>>
>> ATM in the CU we refence those objects only to have the GC not collect
>> them.
>
> struct Lisp_Native_Comp_Unit
> {
>   /* STUFFS WE DO NOT DUMP!!  */
>   Lisp_Object *data_imp_relocs;
>
> Are these the ones?

Almost, this is a similar class of immediates, but the ones we do not
dump.

> IIRC, and without looking at the code, this points
> into the dylib, right? If that's the case, we could scan them
> ambiguously, and they'd be kept alive and wouldn't move.

The object we are discussing is part of the class that gets set here:
comp.c:5413

      for (EMACS_INT i = 0; i < d_vec_len; i++
        data_relocs[i] = AREF (comp_u->data_vec, i);

This is the action you correctly imagined of "putting them into the
machine code".

  Andrea