Re: MPS: native comp

[Andrea Corallo <acorallo@gnu.org>]

Andrea Corallo <acorallo@gnu.org> writes:

> 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:
>>>>
>>>>> That promises to become fun :-/
>>>>
>>>> Sometimes one needs a bit of luck. Another try landed me in an abort in
>>>> set_internal, and I could see that we have another case of a symbol
>>>> pointing to a tombstone. So, we have another reference in the
>>>> compilation unit that we don't trace.
>>>
>>> Maybe you can make it more reproducible building at -J1?
>>
>> I meanwhile suspect it's ASLR. When I run things under LLDB, ASLR is off
>> (LLDB does that). When I gmake (with -j1), ASLR on.
>
> Yep that makes sense
>
>>>> @Andrea: Any intuition where else references could lurk, perhaps? I'm
>>>> currently doing this:
>>>>
>>>> static mps_res_t
>>>> fix_comp_unit (mps_ss_t ss, struct Lisp_Native_Comp_Unit *u)
>>>> {
>>>>   MPS_SCAN_BEGIN (ss)
>>>>   {
>>>>     IGC_FIX_CALL_FN (ss, struct Lisp_Vector, u, fix_vectorlike);
>>>>     if (u->data_imp_relocs)
>>>>       {
>>>> 	size_t n = ASIZE (u->data_impure_vec);
>>>> 	IGC_FIX12_NOBJS (ss, u->data_imp_relocs, n);
>>>>       }
>>>>     if (u->data_relocs)
>>>>       {
>>>> 	size_t n = ASIZE (u->data_vec);
>>>> 	IGC_FIX12_NOBJS (ss, u->data_relocs, n);
>>>>       }
>>>>   }
>>>>   MPS_SCAN_END (ss);
>>>>   return MPS_RES_OK;
>>>> }
>>>>
>>>> Maybe there's something wrong with that (the ASIZEs maybe?)
>>>
>>> I think the size should be fine,
>>
>> Thanks.
>>
>>> it would be very interesting to know which one is the symbol that was
>>> actually killed by the GC. This would give us strong indications.
>>> Maybe we can use the watchpoint strategy to identify it?
>>
>> It's the symbol that leads to the setting-constant error in the eager
>> macro expansion error. You can see that in the debug org file I attached
>> to another mail.
>>
>>       data = 0x000000010f0eb008 "byte-compile-form-stack"
>>
>> The problem is apparently similar to what we had before: The symbol has
>> been moved in memory (not freed), and a reference to the symbol was not
>> updated because we don't trace it. So a watchpoint won't help - the
>> problem is that nothing changes :-).
>
> 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.
>
>> 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.
>
> For instance we do exactly this 'byte-compile-form-stack' and others
> here:
>
> macroexp-1776619e-76691d27.c ======================
> extern struct Lisp_X *
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_0 (long long nargs, struct Lisp_X * * args)
> {
>   struct freloc_link_table * freloc;
>   struct Lisp_X * slot_0;
>   struct Lisp_X * slot_1;
>   struct Lisp_X * slot_2;
>   struct Lisp_X * slot_3;
>   struct Lisp_X * slot_4;
>   struct Lisp_X * slot_5;
>   struct Lisp_X * slot_6;
>   struct comp_handler * c;
>
> entry:
>   freloc = freloc_link_table;
>   /* Lisp function: nil */
>   slot_0 = *args;
>   /* ptr_arithmetic */
>   args = (struct Lisp_X * *)bitcast((unsigned long long)((unsigned long long)bitcast((void *)args, unsigned long long) + (unsigned long long)8 * (unsigned long long)(long long)1)\
> , void *);
>   goto entry_rest_args;
>
> entry_rest_args:
>   /* calling subr: list */
>   slot_1 = freloc->R6c697374_list_0 ((nargs - (long long)1), args);
>   goto bb_0;
>
> bb_0:
>   /* let */
>   slot_2 = d_reloc[(long long)0];
>   /* byte-compile-form-stack */
>   slot_3 = d_reloc[(long long)1];
>   /* cons */
>   slot_4 = d_reloc[(long long)2];
>
> [...]
> ======================
>
> Where we load it in 'slot_3'.
>
> 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?
>
> Thanks
>
>   Andrea

BTW we should be able to prove this is the issue compiling at with
native-comp-speed 0.

  Andrea