Re: MPS: native comp

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

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