MPS: native comp

MPS: native comp

[Gerd Möllmann]

Just a heads up. I've tinkered with the roots of CUs because of a
FIXME I left here. So, don't blame me if something stops working :-).

Re: MPS: native comp

[Andrea Corallo]

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

> Just a heads up. I've tinkered with the roots of CUs because of a
> FIXME I left here. So, don't blame me if something stops working :-).

Hi Gerd,

sorry I'm not sure if you are ironic here or not :) should I stop
tracking the branch in my CI till you think it should be functional
again or you like to keep being informed if something gets broken here?

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Just a heads up. I've tinkered with the roots of CUs because of a
>> FIXME I left here. So, don't blame me if something stops working :-).
>
> Hi Gerd,
>
> sorry I'm not sure if you are ironic here or not :) should I stop
> tracking the branch in my CI till you think it should be functional
> again or you like to keep being informed if something gets broken here?

The latter :-)

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:
>>
>>> Just a heads up. I've tinkered with the roots of CUs because of a
>>> FIXME I left here. So, don't blame me if something stops working :-).
>>
>> Hi Gerd,
>>
>> sorry I'm not sure if you are ironic here or not :) should I stop
>> tracking the branch in my CI till you think it should be functional
>> again or you like to keep being informed if something gets broken here?
>
> The latter :-)

Will do 👍

Re: MPS: native comp

[Gerd Möllmann]

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:
>>>
>>>> Just a heads up. I've tinkered with the roots of CUs because of a
>>>> FIXME I left here. So, don't blame me if something stops working :-).
>>>
>>> Hi Gerd,
>>>
>>> sorry I'm not sure if you are ironic here or not :) should I stop
>>> tracking the branch in my CI till you think it should be functional
>>> again or you like to keep being informed if something gets broken here?
>>
>> The latter :-)
>
> Will do 👍

BTW, just did an AOT native build, and I couldn't believe my eyes - it
finished successfully. Could be a fluke of course, but that has never
happened before :-).

  #define EMACS_CONFIG_FEATURES "ACL DBUS GLIB GNUTLS LCMS2 LIBXML2 MODULES MPS NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB"

  /* Define to the options passed to configure. */
  #define EMACS_CONFIG_OPTIONS "--cache-file /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.igc --with-native-compilation=aot --with-mps=yes CC=clang"

It's macOS 14.5, libgccjit 14.1 from Homebrew, clang 15 from Xcode.

Re: MPS: native comp

[Gerd Möllmann]

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

> 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:
>>>>
>>>>> Just a heads up. I've tinkered with the roots of CUs because of a
>>>>> FIXME I left here. So, don't blame me if something stops working :-).
>>>>
>>>> Hi Gerd,
>>>>
>>>> sorry I'm not sure if you are ironic here or not :) should I stop
>>>> tracking the branch in my CI till you think it should be functional
>>>> again or you like to keep being informed if something gets broken here?
>>>
>>> The latter :-)
>>
>> Will do 👍
>
> BTW, just did an AOT native build, and I couldn't believe my eyes - it
> finished successfully. Could be a fluke of course, but that has never
> happened before :-).
>
>   #define EMACS_CONFIG_FEATURES "ACL DBUS GLIB GNUTLS LCMS2 LIBXML2 MODULES MPS NATIVE_COMP NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB"
>
>   /* Define to the options passed to configure. */
>   #define EMACS_CONFIG_OPTIONS "--cache-file /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.igc --with-native-compilation=aot --with-mps=yes CC=clang"
>
> It's macOS 14.5, libgccjit 14.1 from Homebrew, clang 15 from Xcode.

Hm, and a new GCC package it seems

  .../github/igc/src % brew info gcc
  ==> gcc: stable 14.1.0 (bottled), HEAD
  GNU compiler collection
  https://gcc.gnu.org/
  Installed
  /opt/homebrew/Cellar/gcc/14.1.0_1 (1,559 files, 422.6MB) *

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:
>>
>>> Andrea Corallo <acorallo@gnu.org> writes:
>>>
>>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>>
>>>>> Just a heads up. I've tinkered with the roots of CUs because of a
>>>>> FIXME I left here. So, don't blame me if something stops working :-).
>>>>
>>>> Hi Gerd,
>>>>
>>>> sorry I'm not sure if you are ironic here or not :) should I stop
>>>> tracking the branch in my CI till you think it should be functional
>>>> again or you like to keep being informed if something gets broken here?
>>>
>>> The latter :-)
>>
>> Will do 👍
>
> BTW, just did an AOT native build, and I couldn't believe my eyes - it
> finished successfully. Could be a fluke of course, but that has never
> happened before :-).

That's excellent! 🎉🚀🚀

Do you think is because of the new GCC?

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> BTW, just did an AOT native build, and I couldn't believe my eyes - it
>> finished successfully. Could be a fluke of course, but that has never
>> happened before :-).
>
> That's excellent! 🎉🚀🚀
>
> Do you think is because of the new GCC?

I have no idea. I think it's been some weeks since I last tried, and a
lot of things have changed, including the merge of master, a ton of
fixes and refactorings, the new GCC...

MPS: native comp

[Gerd Möllmann]

Hi Andrea,

I'm back to this after an excursion into the GUI world with MPS. And I
might have something that could be hint where the references live that
are currently not traced. Maybe. Could you please help me with this?

My scribbling from this mornings debug session:

* Bus error in styled_format

macroexp native-compiled, rest source. Bus error while dumping.

#+begin_src sh
Loading emacs-lisp/macroexp (native compiled elisp)...
Loading /Users/gerd/emacs/savannah/igc/lisp/cus-face.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/faces.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/ldefs-boot.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/button.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-preloaded.el (source)...
Process 70068 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1089f2140)
    frame #0: 0x0000000100280b5c temacs`styled_format(nargs=2, args=(struct Lisp_Symbol *) $0 = 0x0000000270a89b70, message=true) at editfns.c:3519:35
#+end_src

In styled_format

#+begin_src sh
p args[0]
(Lisp_Object) 0x00000001089f4e94 (struct Lisp_String *) $2 = 0x00000001089f4e90
(lldb) p *$2
(struct Lisp_String) {
  u = {
    s = {
      size = 4546790736
      size_byte = -1
      intervals = NULL
      data = 0x00000001089f2140 ""
    }
    next = 0x000000010f028550
    gcaligned = 'P'
  }
}
(lldb) p *(struct igc_header *) ((char *) $2 - 8)
(struct igc_header)  (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074619, nwords = 5)
#+end_src

This is a reference pointing to a tombstone, so a reference that
hasn't been traced.

#+begin_src sh
(lldb) p *(struct igc_fwd *) ((char *) $2 - 8)
(struct igc_fwd) {
  header = (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074619, nwords = 5)
  new_base_addr = 0x000000010f028550
(lldb) p *(struct igc_header *) 0x000000010f028550
(struct igc_header)  (obj_type = IGC_OBJ_STRING, pvec_type = PVEC_FREE, hash = 1074619, nwords = 5)
(lldb) p base_to_client ((void*) 0x000000010f028550)
(mps_addr_t) 0x000000010f028558
(lldb) p *(struct Lisp_String *) 0x000000010f028558
(struct Lisp_String) {
  u = {
    s = {
      size = 33
      size_byte = -1
      intervals = NULL
      data = 0x000000010f022988 "Eager macro-expansion failure: %S"
    }
    next = 0x0000000000000021
    gcaligned = '!'
  }
}
#+end_src


So, it looks like the string constant "Eager..." is a reference that is
not traced. Can you please tell me where I can find these string
constants in native cu data structures?

Re: MPS: native comp

[Andrea Corallo]

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

> Hi Andrea,

Hi Gerd

> I'm back to this after an excursion into the GUI world with MPS. And I
> might have something that could be hint where the references live that
> are currently not traced. Maybe. Could you please help me with this?

sure, at least I can try :)

> My scribbling from this mornings debug session:
>
> * Bus error in styled_format
>
> macroexp native-compiled, rest source. Bus error while dumping.
>
> #+begin_src sh
> Loading emacs-lisp/macroexp (native compiled elisp)...
> Loading /Users/gerd/emacs/savannah/igc/lisp/cus-face.el (source)...
> Loading /Users/gerd/emacs/savannah/igc/lisp/faces.el (source)...
> Loading /Users/gerd/emacs/savannah/igc/lisp/ldefs-boot.el (source)...
> Loading /Users/gerd/emacs/savannah/igc/lisp/button.el (source)...
> Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-preloaded.el (source)...
> Process 70068 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x1089f2140)
>     frame #0: 0x0000000100280b5c temacs`styled_format(nargs=2, args=(struct Lisp_Symbol *) $0 = 0x0000000270a89b70, message=true) at editfns.c:3519:35
> #+end_src
>
>
> In styled_format
>
> #+begin_src sh
> p args[0]
> (Lisp_Object) 0x00000001089f4e94 (struct Lisp_String *) $2 = 0x00000001089f4e90
> (lldb) p *$2
> (struct Lisp_String) {
>   u = {
>     s = {
>       size = 4546790736
>       size_byte = -1
>       intervals = NULL
>       data = 0x00000001089f2140 ""
>     }
>     next = 0x000000010f028550
>     gcaligned = 'P'
>   }
> }
> (lldb) p *(struct igc_header *) ((char *) $2 - 8)
> (struct igc_header)  (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074619, nwords = 5)
> #+end_src
>
>
> This is a reference pointing to a tombstone, so a reference that
> hasn't been traced.
>
> #+begin_src sh
> (lldb) p *(struct igc_fwd *) ((char *) $2 - 8)
> (struct igc_fwd) {
>   header = (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074619, nwords = 5)
>   new_base_addr = 0x000000010f028550
> (lldb) p *(struct igc_header *) 0x000000010f028550
> (struct igc_header)  (obj_type = IGC_OBJ_STRING, pvec_type = PVEC_FREE, hash = 1074619, nwords = 5)
> (lldb) p base_to_client ((void*) 0x000000010f028550)
> (mps_addr_t) 0x000000010f028558
> (lldb) p *(struct Lisp_String *) 0x000000010f028558
> (struct Lisp_String) {
>   u = {
>     s = {
>       size = 33
>       size_byte = -1
>       intervals = NULL
>       data = 0x000000010f022988 "Eager macro-expansion failure: %S"
>     }
>     next = 0x0000000000000021
>     gcaligned = '!'
>   }
> }
> #+end_src
>
>
> So, it looks like the string constant "Eager..." is a reference that is
> not traced. Can you please tell me where I can find these string
> constants in native cu data structures?

"Eager macro-expansion failure: %S" is an immediate stored in the eln of
macroexp.el.  This should be deserialized by 'load_static_obj' and
referenced by 'comp_u->data_vec' (see 'load_comp_unit' comp.c:5402).

Maybe mps is not tracking Lisp_Native_Comp_Unit's fields?

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> So, it looks like the string constant "Eager..." is a reference that is
>> not traced. Can you please tell me where I can find these string
>> constants in native cu data structures?
>
> "Eager macro-expansion failure: %S" is an immediate stored in the eln of
> macroexp.el.  This should be deserialized by 'load_static_obj' and
> referenced by 'comp_u->data_vec' (see 'load_comp_unit' comp.c:5402).
>
> Maybe mps is not tracking Lisp_Native_Comp_Unit's fields?

Thanks!

Hm. I think I'm tracing data_vec already. Here is what I do

static mps_res_t
fix_native_cu (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);
      }
  }
  MPS_SCAN_END (ss);
  return MPS_RES_OK;
}

The fix_vectorlike should cover all Lisp_Objects in u that are in the
Lisp part of the pseudovecor (you know what I mean). That's strange.

Could the non-Lisp part of u contain a reference to the string somewhere
else? The difference to the old GC with MPS is that we need to trace all
references because MPS is a moving collector, and all references must be
changed when an object mvoes.

Re: MPS: native comp

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel missing value <emacs-devel@gnu.org>
> Date: Mon, 29 Apr 2024 07:35:05 +0200
> 
> So, it looks like the string constant "Eager..." is a reference that is
> not traced. Can you please tell me where I can find these string
> constants in native cu data structures?

I'm not Andrea, but (risking to tell you what you already know): The
string "Eager macro-expansion failure: %S" comes from the function
internal-macroexpand-for-load, defined in macroexp.el.  It is the
error message shown when we signal an error from that function.
internal-macroexpand-for-load is called from
lread.c:readevalloop_eager_expand_eval, which is called from readevalloop.

Why that string is not traced, I don't know, since it comes from Lisp.
Do we do something special with string constants in the calls to
'error', when we compile such Lisp code?

HTH

Re: MPS: native comp

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel missing value <emacs-devel@gnu.org>
>> Date: Mon, 29 Apr 2024 07:35:05 +0200
>> 
>> So, it looks like the string constant "Eager..." is a reference that is
>> not traced. Can you please tell me where I can find these string
>> constants in native cu data structures?
>
> I'm not Andrea, but (risking to tell you what you already know): The
> string "Eager macro-expansion failure: %S" comes from the function
> internal-macroexpand-for-load, defined in macroexp.el.  It is the
> error message shown when we signal an error from that function.
> internal-macroexpand-for-load is called from
> lread.c:readevalloop_eager_expand_eval, which is called from readevalloop.
>
> Why that string is not traced, I don't know, since it comes from Lisp.
> Do we do something special with string constants in the calls to
> 'error', when we compile such Lisp code?

My model of this is that constants contained in the Lisp program that is
being natived-compiled, land in the dylib, somewhere in the data
segment. Like for C, say. I think Andrea confirmed that.

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.

But... I'm already tracing data_vec, so there must be something else...

Re: MPS: native comp

[Gerd Möllmann]

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

Re: MPS: native comp

[Gerd Möllmann]

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!

Re: MPS: native comp

[Andrea Corallo]

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.

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

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.

Re: MPS: native comp

[Gerd Möllmann]

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

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

Or, we coould scan the machine code for exact references, if that's
realistic. We'd need the info where to find the references though, but
that should be in the dylib, right?

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

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

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

Thanks!

And data_relocs points into the dylib, I see.

      Lisp_Object *data_relocs = dynlib_sym (handle, DATA_RELOC_SYM);

So, we could make [data_relocs, data_relocs + d_vec_len) an ambig root.

I'm wondering, where is the machine code being patched, if it is? Or
does it the machine code have an indirection into data_relocs? Because,
in that case, we could perhaps change the references when objects nove.

Do I have to do anything with these

      d_vec_len = XFIXNUM (Flength (comp_u->data_impure_vec));
      for (EMACS_INT i = 0; i < d_vec_len; i++)
	data_imp_relocs[i] = AREF (comp_u->data_impure_vec, i);

?


>
>   Andrea

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> 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".
>
> Thanks!
>
> And data_relocs points into the dylib, I see.
>
>       Lisp_Object *data_relocs = dynlib_sym (handle, DATA_RELOC_SYM);
>
> So, we could make [data_relocs, data_relocs + d_vec_len) an ambig root.
>
> I'm wondering, where is the machine code being patched, if it is? Or
> does it the machine code have an indirection into data_relocs? Because,
> in that case, we could perhaps change the references when objects nove.

For:

test.el =================
;; -*- lexical-binding: t; -*-

(defun foo ()
  "xxx")
=================

The generated code looks like this:

test-a526a80f-f923b2eb.c =====================
[...]

struct Lisp_X *[7] d_reloc;

[...]

extern struct Lisp_X *
F666f6f_foo_0 ()
{

[...]

return d_reloc[(long long)0];
}

[...]
=================

> Do I have to do anything with these
>
>       d_vec_len = XFIXNUM (Flength (comp_u->data_impure_vec));
>       for (EMACS_INT i = 0; i < d_vec_len; i++)
> 	data_imp_relocs[i] = AREF (comp_u->data_impure_vec, i);
>
> ?

Yes I guess the same applies  :)

PS if you are interested we can generate the pesudo C for the code with
emit with something like:

(let ((native-comp-debug 3))
  (native-compile "test.el"))

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Yes I guess the same applies  :)

Thanks! I think I now know just enough to be dangerous ;-).

> PS if you are interested we can generate the pesudo C for the code with
> emit with something like:
>
> (let ((native-comp-debug 3))
>   (native-compile "test.el"))

Wot? This can be done? Thanks!

(And from the C code I think I see that there is the indirection I
meant.)

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Yes I guess the same applies  :)
>
> Thanks! I think I now know just enough to be dangerous ;-).

Excellent :D

>> PS if you are interested we can generate the pesudo C for the code with
>> emit with something like:
>>
>> (let ((native-comp-debug 3))
>>   (native-compile "test.el"))
>
> Wot? This can be done? Thanks!

Pure magic 😀 one could even step into it with the deugger

> (And from the C code I think I see that there is the indirection I
> meant.)

Yes there is the indirection, so MPS could patch 'd_reloc' & friends.

OTOH I'm not sure it's worth, those objects are collected only when CU
are unloaded which is in practice a very rare event.  But I really dunno
which of the two option (moving/non moving) is the most expensive option
with MPS.

Thanks!

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> Wot? This can be done? Thanks!
>
> Pure magic 😀 one could even step into it with the deugger

Wait, wait, wait - how do I do that? I must play with it.

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> Wot? This can be done? Thanks!
>>
>> Pure magic 😀 one could even step into it with the deugger
>
> Wait, wait, wait - how do I do that? I must play with it.

Should be sufficiente to place a break point the C counterpart of the
Lisp function, say in this case 'F666f6f_foo_0'.

If it was compiled with native-comp-debug >=2 the debugger should
directly find the pseudo C 😀.

Note that with native-comp-speed > 0 the build is optimized so the debug
experience should come with all the expected limitaiton, if you want a
better experience you can use native-comp-speed 0 (or force GCC to -O0).

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Should be sufficiente to place a break point the C counterpart of the
> Lisp function, say in this case 'F666f6f_foo_0'.
>
> If it was compiled with native-comp-debug >=2 the debugger should
> directly find the pseudo C 😀.
>
> Note that with native-comp-speed > 0 the build is optimized so the debug
> experience should come with all the expected limitaiton, if you want a
> better experience you can use native-comp-speed 0 (or force GCC to -O0).
>
>   Andrea

Progress. Same scenario as before and we come to pdumping, but it
complains

  ./temacs --batch  -l loadup --temacs=pbootstrap \
          --bin-dest  --eln-dest
  ...
  Loading emacs-lisp/macroexp (native compiled elisp)...
  ..
  Dumping under the name bootstrap-emacs.pdmp
  Dumping fingerprint: 4ff41caeb772618cf9be4dd61ae8a1cf909c29b0ff417318ec6039950eaf53fc

  Error: error ("trying to dump non fixed-up eln file")

Whatever, that can wait til tomorrow. I have to do something else now ;-).
Thanks!

Re: MPS: native comp

[Gerd Möllmann]

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

> Progress. Same scenario as before and we come to pdumping, but it
> complains
>
>   ./temacs --batch  -l loadup --temacs=pbootstrap \
>           --bin-dest  --eln-dest
>   ...
>   Loading emacs-lisp/macroexp (native compiled elisp)...
>   ..
>   Dumping under the name bootstrap-emacs.pdmp
>   Dumping fingerprint: 4ff41caeb772618cf9be4dd61ae8a1cf909c29b0ff417318ec6039950eaf53fc
>
>   Error: error ("trying to dump non fixed-up eln file")
>

Actually, and strangely, I get a different error when running under
LLDB.

  Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-generic.el (source)...
  Loading /Users/gerd/emacs/savannah/igc/lisp/simple.el (source)...

  Error: error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)")
    signal(error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)"))

In a way that makes more sense because we saw that "Eager..." string
before. byte-compile-form-stack is a var defined in macroexp.

Does someone know what "eager" macro expansion means? In what way is it
eager? Or different from non-eager (lazy?) macro expansion? But why
would ME be lazy? Questions about questions...

Re: MPS: native comp

[Gerd Möllmann]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Progress. Same scenario as before and we come to pdumping, but it
>> complains
>>
>>   ./temacs --batch  -l loadup --temacs=pbootstrap \
>>           --bin-dest  --eln-dest
>>   ...
>>   Loading emacs-lisp/macroexp (native compiled elisp)...
>>   ..
>>   Dumping under the name bootstrap-emacs.pdmp
>>   Dumping fingerprint: 4ff41caeb772618cf9be4dd61ae8a1cf909c29b0ff417318ec6039950eaf53fc
>>
>>   Error: error ("trying to dump non fixed-up eln file")
>>
>
> Actually, and strangely, I get a different error when running under
> LLDB.
>
>   Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-generic.el (source)...
>   Loading /Users/gerd/emacs/savannah/igc/lisp/simple.el (source)...
>
>   Error: error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)")
>     signal(error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)"))
>
> In a way that makes more sense because we saw that "Eager..." string
> before. byte-compile-form-stack is a var defined in macroexp.
>
> Does someone know what "eager" macro expansion means? In what way is it
> eager? Or different from non-eager (lazy?) macro expansion? But why
> would ME be lazy? Questions about questions...

And sometimes, dumping is even successful

  Dump complete (3.01 seconds)
  Byte counts: header=100 hot=16116548 discardable=203120 cold=11263336
  Reloc counts: hot=1118119 discardable=5568
  Process 24209 exited with status = 0 (0x00000000) 

That promises to become fun :-/

Re: MPS: native comp

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

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.

@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?)

@Eli & Helmut ainly: I'm attaching my debug log because this is one of
the cases I mentioned where I needed xpostmortem to remove MPS'
barriers. xpostmortem is a command that I defined for LLDB that called
igc_postmortem.


[-- Attachment #2: debug log --]
[-- Type: text/x-org, Size: 11070 bytes --]

:PROPERTIES:
:ID:       544E65F2-9EED-4D0E-812F-79205DA0040F
:END:
#+title: Debugging Ideas
* Eager macro expansion failure, abort, ...

macroexp native-compiled, rest source. Dumnping.

#+begin_src sh
Loading /Users/gerd/emacs/savannah/igc/lisp/indent.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-generic.el (source)...
Loading /Users/gerd/emacs/savannah/igc/lisp/simple.el (source)...

Error: error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)")
  signal(error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)"))
  error("Eager macro-expansion failure: %S" (setting-constant byte-compile-form-stack))
  internal-macroexpand-for-load((defalias 'undo #'(lambda (&optional arg) "Undo some previous changes.\nRepeat this command to undo more changes.\nA numeric ARG serves as a repeat count.\n\nIn Transient Mark mode when the mark is active, undo changes only within\nthe current region.  Similarly, when not in Transient Mark mode, just \\[universal-argument]\nas an argument limits undo to changes within the current region." (interactive "*P") (let* ((modified (buffer-modified-p)) (base-buffer (or (buffer-base-buffer) (current-buffer))) (recent-save (with-current-buffer base-buffer (recent-auto-save-p))) (inhibit-region (and (symbolp last-command) (get last-command 'undo-inhibit-region))) message) (setq this-command 'undo-start) (unless (and (eq last-command 'undo) (or (eq pending-undo-list t) (undo--last-change-was-undo-p buffer-undo-list))) (setq undo-in-region (and (or (region-active-p) (and arg (not (numberp arg)))) (not inhibit-region))) (if undo-in-region (undo-start (region-beginning) (region-end)) (undo-start)) (undo-more 1)) (setq this-command 'undo) (let ((equiv (gethash pending-undo-list undo-equiv-table))) (or (eq (selected-window) (minibuffer-window)) (setq message (format "%s%s" (if (or undo-no-redo (not equiv)) "Undo" "Redo") (if undo-in-region " in region" "")))) (when (and (consp equiv) undo-no-redo) (while (let ((next (gethash equiv undo-equiv-table))) (if next (setq equiv next)))) (setq pending-undo-list (if (consp equiv) equiv t)))) (undo-more (if (numberp arg) (prefix-numeric-value arg) 1)) (let ((list buffer-undo-list)) (while (eq (car list) nil) (setq list (cdr list))) (puthash list (cond (undo-in-region 'undo-in-region) ((eq list pending-undo-list) (or (gethash list undo-equiv-table) 'empty)) (t pending-undo-list)) undo-equiv-table)) (let ((tail buffer-undo-list) (prev nil)) (while (car tail) (when (integerp (car tail)) (let ((pos (car tail))) (if prev (setcdr prev (cdr tail)) (setq buffer-undo-list (cdr tail))) (setq tail (cdr tail)) (while (car tail) (if (eq pos (car tail)) (if prev (setcdr prev (cdr tail)) (setq buffer-undo-list (cdr tail))) (setq prev tail)) (setq tail (cdr tail))) (setq tail nil))) (setq prev tail tail (cdr tail)))) (and modified (not (buffer-modified-p)) (with-current-buffer base-buffer (delete-auto-save-file-if-necessary recent-save))) (if message (message "%s" message))))) t)
  eval-buffer(#<buffer  *load*> nil "/Users/gerd/emacs/savannah/igc/lisp/simple.el" nil t)
  (if eval-function (funcall eval-function buffer (if dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil t))
  (let ((read-symbol-shorthands shorthands)) (if eval-function (funcall eval-function buffer (if dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil t)))
  (let ((load-true-file-name fullname) (load-file-name fullname) (set-auto-coding-for-load t) (inhibit-file-name-operation nil) shorthands) (with-current-buffer buffer (set-buffer-multibyte t) (let (deactivate-mark) (insert-file-contents fullname)) (setq shorthands (and hack-read-symbol-shorthands-function (funcall hack-read-symbol-shorthands-function))) (if (and enable-multibyte-characters (or (eq (coding-system-type last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil)) (set-buffer-modified-p nil)) (let ((read-symbol-shorthands shorthands)) (if eval-function (funcall eval-function buffer (if dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil t))))
  (unwind-protect (let ((load-true-file-name fullname) (load-file-name fullname) (set-auto-coding-for-load t) (inhibit-file-name-operation nil) shorthands) (with-current-buffer buffer (set-buffer-multibyte t) (let (deactivate-mark) (insert-file-contents fullname)) (setq shorthands (and hack-read-symbol-shorthands-function (funcall hack-read-symbol-shorthands-function))) (if (and enable-multibyte-characters (or (eq (coding-system-type last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil)) (set-buffer-modified-p nil)) (let ((read-symbol-shorthands shorthands)) (if eval-function (funcall eval-function buffer (if dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil t)))) (let (kill-buffer-hook kill-buffer-query-functions) (kill-buffer buffer)))
  (let ((buffer (generate-new-buffer " *load*")) (load-in-progress t) (source (string-suffix-p ".el" fullname))) (unless nomessage (if source (message "Loading %s (source)..." file) (message "Loading %s..." file))) (when purify-flag (push (purecopy file) preloaded-file-list)) (unwind-protect (let ((load-true-file-name fullname) (load-file-name fullname) (set-auto-coding-for-load t) (inhibit-file-name-operation nil) shorthands) (with-current-buffer buffer (set-buffer-multibyte t) (let (deactivate-mark) (insert-file-contents fullname)) (setq shorthands (and hack-read-symbol-shorthands-function (funcall hack-read-symbol-shorthands-function))) (if (and enable-multibyte-characters (or (eq (coding-system-type last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil)) (set-buffer-modified-p nil)) (let ((read-symbol-shorthands shorthands)) (if eval-function (funcall eval-function buffer (if dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil t)))) (let (kill-buffer-hook kill-buffer-query-functions) (kill-buffer buffer))) (do-after-load-evaluation fullname) (unless (or nomessage noninteractive) (if source (message "Loading %s (source)...done" file) (message "Loading %s...done" file))) t)
  (if (null (file-readable-p fullname)) (and (null noerror) (signal 'file-error (list "Cannot open load file" file))) (let ((buffer (generate-new-buffer " *load*")) (load-in-progress t) (source (string-suffix-p ".el" fullname))) (unless nomessage (if source (message "Loading %s (source)..." file) (message "Loading %s..." file))) (when purify-flag (push (purecopy file) preloaded-file-list)) (unwind-protect (let ((load-true-file-name fullname) (load-file-name fullname) (set-auto-coding-for-load t) (inhibit-file-name-operation nil) shorthands) (with-current-buffer buffer (set-buffer-multibyte t) (let (deactivate-mark) (insert-file-contents fullname)) (setq shorthands (and hack-read-symbol-shorthands-function (funcall hack-read-symbol-shorthands-function))) (if (and enable-multibyte-characters (or (eq (coding-system-type last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil)) (set-buffer-modified-p nil)) (let ((read-symbol-shorthands shorthands)) (if eval-function (funcall eval-function buffer (if dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil t)))) (let (kill-buffer-hook kill-buffer-query-functions) (kill-buffer buffer))) (do-after-load-evaluation fullname) (unless (or nomessage noninteractive) (if source (message "Loading %s (source)...done" file) (message "Loading %s...done" file))) t))
  load-with-code-conversion("/Users/gerd/emacs/savannah/igc/lisp/simple.el" "/Users/gerd/emacs/savannah/igc/lisp/simple.el" nil nil)
  load("simple")
  load("loadup.el")
Eager macro-expansion failure: (setting-constant byte-compile-form-stack)
#+end_src

C-h v

#+begin_src sh
byte-compile-form-stack is a variable defined in ‘macroexp.el’.
#+end_src

At least suspicious that it is in macroexp which is native cpmpiled.

* Abort in set_internal

#+begin_src sh
(lldb) p *sym
(Lisp_Symbol) {
  u = {
    s = {
      gcmarkbit = false
      redirect = SYMBOL_PLAINVAL
      trapped_write = SYMBOL_NOWRITE | SYMBOL_TRAPPED_WRITE
      interned = SYMBOL_INTERNED | SYMBOL_INTERNED_IN_INITIAL_OBARRAY
      declared_special = true
      pinned = true
      name = 0x000000010f0f1614 (struct Lisp_String *) $4 = 0x000000010f0f1610
      val = {
        value = 0x0000000110623fe3 (struct Lisp_Cons *) $5 = 0x0000000110623fe0
        alias = 0x0000000110623fe3
        blv = 0x0000000110623fe3
        fwd = (fwdptr = 0x0000000110623fe3)
      }
      function = NULL
      plist = 0x000000010f0f163b (struct Lisp_Cons *) $6 = 0x000000010f0f1638
      next = 0x000000010f0f1650
    }
    gcaligned = '\xf8'
  }
}
(lldb) p *$4
error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory
(lldb) p *(struct igc_header *) client_to_base (sym)
(struct igc_header)  (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074169, nwords = 7)
#+end_src

Same procedure as last year, Miss Sophie. Symbol points to tombstone.

#+begin_src sh
(lldb) p *(struct igc_header *) 0x000000010f8619f8
(struct igc_header)  (obj_type = IGC_OBJ_SYMBOL, pvec_type = PVEC_FREE, hash = 1074169, nwords = 7)
(lldb) p *(struct Lisp_Symbol *) base_to_client ((void *)0x000000010f8619f8)
(struct Lisp_Symbol) {
  u = {
    s = {
      gcmarkbit = false
      redirect = SYMBOL_PLAINVAL
      trapped_write = SYMBOL_UNTRAPPED_WRITE
      interned = SYMBOL_INTERNED_IN_INITIAL_OBARRAY
      declared_special = true
      pinned = false
      name = 0x000000010f0f1614 (struct Lisp_String *) $9 = 0x000000010f0f1610
      val = {
        value = 0x000000010f864efb (struct Lisp_Cons *) $10 = 0x000000010f864ef8
        alias = 0x000000010f864efb
        blv = 0x000000010f864efb
        fwd = (fwdptr = 0x000000010f864efb)
      }
      function = NULL
      plist = 0x000000010f0f163b (struct Lisp_Cons *) $11 = 0x000000010f0f1638
      next = 0x000000010f0f1650
    }
    gcaligned = '\xc0'
  }
}
(lldb) p *$9
error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory
(lldb) p *(struct igc_header *) client_to_base ($9)
error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory
(lldb) memory read 0x000000010f0f1610
error: memory read failed for 0x10f0f1600
(lldb) xpostmortem
(lldb) memory read 0x000000010f0f1610
0x10f0f1610: 17 00 00 00 00 00 00 00 17 00 00 00 00 00 00 00  ................
0x10f0f1620: 00 00 00 00 00 00 00 00 08 b0 0e 0f 01 00 00 00  ................
(lldb) p *(struct Lisp_String *)0x000000010f0f1610
(struct Lisp_String) {
  u = {
    s = {
      size = 23
      size_byte = 23
      intervals = NULL
      data = 0x000000010f0eb008 "byte-compile-form-stack"
    }
    next = 0x0000000000000017
    gcaligned = '\x17'
  }
}
#+end_src

Re: MPS: native comp

[Andrea Corallo]

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?

> @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, 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?

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

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.

>> @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 :-).

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?

Re: MPS: native comp

[Gerd Möllmann]

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

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

That almost worked, except that the text is not readable

  char[4173] text_data_reloc_blob=
    { 0x45, 0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5b, ...

Is there something I can do to let the compiler output a string?
Sorry for pestering you ;-).

Re: MPS: native comp

[Andrea Corallo]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> 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?
>
> That almost worked, except that the text is not readable
>
>   char[4173] text_data_reloc_blob=
>     { 0x45, 0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5b, ...
>
> Is there something I can do to let the compiler output a string?
> Sorry for pestering you ;-).

'text_data_reloc_blob' is the text represantation that needs to go
through 'read' at load-time to become a real Lisp object, so I think
should not be of much use for the issue we have ATM.  I suspect the
issue is the one I mentioned in my other reply.

Thanks

  Andrea

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:
>>>
>>>> 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

Re: MPS: native comp

[Andrea Corallo]

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

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.

Re: MPS: native comp

[Andrea Corallo]

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

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

I think I miss few bits to understand MPS:

If stack and registers are scanned I guess MPS has to stop the mutator
thread no?  In the moment after the mutator restarts after the scan
other ambig roots might appear, so how can such moving collection be
done in a parallel fashion?

Also if this mechanism (I don't fully understand ATM) is working the
issue I mentioned of values being kept in registers should be a non
issue.  Code we generate from Lisp is not very different from the one we
compile form C (we still have registers spill/fills etc).

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

To survive I had to find my way somehow :)

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

Well other than spirit and possibly simplicity we should evaluate if
(and in case how much) is the cost to have this objects movable vs
non-movable.

The starting point for me is that this is a very special kind of object
class we know in advance is very rarely (if ever) collected, so would be
a pity to not consider this in the definition of the GC strategy
(assuming is an option).

Thanks

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> 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.
>
> I think I miss few bits to understand MPS:
>
> If stack and registers are scanned I guess MPS has to stop the mutator
> thread no?  

Yes.

> In the moment after the mutator restarts after the scan other ambig
> roots might appear, so how can such moving collection be done in a
> parallel fashion?

The exact algorith MPS implements I don't know either. The docs include
some design documents, but I haven't read them all, and some I didn't
understgand because there was some context missing.

A number of possible algorithms that could be used are described in the
literature, or one could glance at existing GCs for V8, for example.
Hard to read though, for me at least.

> Also if this mechanism (I don't fully understand ATM) is working the
> issue I mentioned of values being kept in registers should be a non
> issue.  Code we generate from Lisp is not very different from the one we
> compile form C (we still have registers spill/fills etc).

Yes, I think the same. It's just like some C code running.

>> Haha, I hadn't even remotely occurred to me that you would emit a
>> comment with the name :-). That makes things a lot easier. 👍
>
> To survive I had to find my way somehow :)

:-)

>
>>> 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.
>
> Well other than spirit and possibly simplicity we should evaluate if
> (and in case how much) is the cost to have this objects movable vs
> non-movable.

Sure.

For me personally the most important aspect is interactive user
experience. Let's say complaints about GC pauses are not entirelly
unheard of ;-). I even have one myself: In an Org file, with my init.el,
GC kicks in every 5 lines with C-n/C-p (something font/jit-locking
produces heaps of garbage). It's unbearable, and that's on my old
battlehorse MBPro with i7 from 2013 which I used for years for C++
development in Linux VMs just fine :-/.

> The starting point for me is that this is a very special kind of object
> class we know in advance is very rarely (if ever) collected, so would be
> a pity to not consider this in the definition of the GC strategy
> (assuming is an option).

MPS is also generational, i.e. objects eventually move to older
generations which are less frequently collected. Haven't played with
that knob though. Atm, there are 2 generations.

If the CUs are in the loaded pdump, they won't be collected anyway, of
course. How that works best I have still to figure out, but I didn't get
a chance yet :-).

And the pdump is also an aspect all in in itself...
And in general, lots of things could be tried...

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:
>>
>>> 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.
>>
>> I think I miss few bits to understand MPS:
>>
>> If stack and registers are scanned I guess MPS has to stop the mutator
>> thread no?  
>
> Yes.
>
>> In the moment after the mutator restarts after the scan other ambig
>> roots might appear, so how can such moving collection be done in a
>> parallel fashion?
>
> The exact algorith MPS implements I don't know either. The docs include
> some design documents, but I haven't read them all, and some I didn't
> understgand because there was some context missing.
>
> A number of possible algorithms that could be used are described in the
> literature, or one could glance at existing GCs for V8, for example.
> Hard to read though, for me at least.

I think is mandatory that at least some of us understand at least the
high level mechanism of how MPS works otherwise before of later we will
be beaten by it somehow.

My fear is that the GC requires the code is generated respecting some
property way we might not respect.  Other issues might rise in the
future if we don't understand all of this.

>> Also if this mechanism (I don't fully understand ATM) is working the
>> issue I mentioned of values being kept in registers should be a non
>> issue.  Code we generate from Lisp is not very different from the one we
>> compile form C (we still have registers spill/fills etc).
>
> Yes, I think the same. It's just like some C code running.
>
>>> Haha, I hadn't even remotely occurred to me that you would emit a
>>> comment with the name :-). That makes things a lot easier. 👍
>>
>> To survive I had to find my way somehow :)
>
> :-)
>
>>
>>>> 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.
>>
>> Well other than spirit and possibly simplicity we should evaluate if
>> (and in case how much) is the cost to have this objects movable vs
>> non-movable.
>
> Sure.
>
> For me personally the most important aspect is interactive user
> experience. Let's say complaints about GC pauses are not entirelly
> unheard of ;-).

I totally second your opinion on this.  OTOH given we (well you 😅) are
doing the work now, is good we think about decision we are taking.

> I even have one myself: In an Org file, with my init.el,
> GC kicks in every 5 lines with C-n/C-p (something font/jit-locking
> produces heaps of garbage). It's unbearable, and that's on my old
> battlehorse MBPro with i7 from 2013 which I used for years for C++
> development in Linux VMs just fine :-/.
>
>> The starting point for me is that this is a very special kind of object
>> class we know in advance is very rarely (if ever) collected, so would be
>> a pity to not consider this in the definition of the GC strategy
>> (assuming is an option).
>
> MPS is also generational, i.e. objects eventually move to older
> generations which are less frequently collected. Haven't played with
> that knob though. Atm, there are 2 generations.

Yep, essentially we know that all objects coming from CUs should go
directly to the oldest generation by definition and we should not bother
moving them.

Thanks!

  Andrea

PS last week I failed compiling MPS :/ I hope I can retry in the future
and have a look.

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> The exact algorith MPS implements I don't know either. The docs include
>> some design documents, but I haven't read them all, and some I didn't
>> understgand because there was some context missing.
>>
>> A number of possible algorithms that could be used are described in the
>> literature, or one could glance at existing GCs for V8, for example.
>> Hard to read though, for me at least.
>
> I think is mandatory that at least some of us understand at least the
> high level mechanism of how MPS works otherwise before of later we will
> be beaten by it somehow.

Speaking for myself, I think I have some understanding.

Opa telling stories from the good old times again :-): Back in, I don't
remember exactly anymore, around the late 1890s ;-), not long after the
invention of sliced bread, I was implementing a GC for Emacs that was
very similar to MPS. Incremental, generational, mostly-copying,
barriers, but not concurrent. Concurrency was not that big a thing back
then ISTR. That was torpedoed hearing of the existemce of a software
patent for the mostly-copying algorithm, which I consider a trivial idea
:-(. (The patent has expired 10 years or so ago.)

All that's left of that is a C source file I posted to emacs-devel when
I left, which was also named igc.c, what a coincidence :-). I got that
some time ago from Stefan Monnier, who had kept a copy. I seem to have
lost it again. Not a loss.

Be that as it may. What I eanted to say is that I feel for myself I have
a good model of what MPS does in my head. I personally don't want to
dive into details of its code. It's a library for me. A good one I'd
say, and well documented. And if it does A or B is not important to me,
unless I land there in a debugger, and then I can see it.

I'm actually trying to spread some knowledge by talking/writing too much
sometimes. I know I'm in general not good at such things. And I'm of
course not an encyclopedia, or professor for garbage collection.

> My fear is that the GC requires the code is generated respecting some
> property way we might not respect.  Other issues might rise in the
> future if we don't understand all of this.

No special casing required for MPS. If it's valid in C, it's fine.

>> For me personally the most important aspect is interactive user
>> experience. Let's say complaints about GC pauses are not entirelly
>> unheard of ;-).
>
> I totally second your opinion on this.  OTOH given we (well you 😅) are
> doing the work now, is good we think about decision we are taking.

Don't forget Helmut and Eli! If they hadn't picked it up, it would
probably be dead already.

And I agree, with a twist perhaps. The whole experiment started with the
first commit in my local fork

  dbdc3a8745eab17c170be0bb27bd36515626f3b5
  Author:     Gerd Möllmann <gerd@gnu.org>
  AuthorDate: Tue Feb 20 06:42:49 2024 +0100
  Commit:     Gerd Möllmann <gerd@gnu.org>
  CommitDate: Tue Feb 20 06:42:49 2024 +0100

  Use MPS if available

  New configure option --with-mps=(yes,no,debug), on by default.
  If debug, use -lmps-debug, otherwise use -lmps.

  * configure.ac (LIBMPS, HAVE_MPS): New.
  * src/Makefile.in (LIBMPS): New.
  
So, we're _very early_, it's almost certain that things will turn out
not to work out, or experiments will be done how to do things best. And
so on.

> PS last week I failed compiling MPS :/ I hope I can retry in the future
> and have a look.

Maybe Helmut could help you? He's on Debian.

Re: MPS: native comp

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Helmut Eller
>  <eller.helmut@gmail.com>
> Date: Tue, 30 Apr 2024 13:54:50 +0200
> 
> Andrea Corallo <acorallo@gnu.org> writes:
> 
> > PS last week I failed compiling MPS :/ I hope I can retry in the future
> > and have a look.
> 
> Maybe Helmut could help you? He's on Debian.

FTR, I've built MPS on Trisquel GNU/Linux with no trouble at all.
There's a ready makefile in the tarball, you just need to run it.

MPS doesn't use Autoconf (well, it does, but not the way we are used
to).  Instead, for every platform it supports OOTB it has a makefile
ready to run.

Re: MPS: native comp

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Helmut Eller
>>  <eller.helmut@gmail.com>
>> Date: Tue, 30 Apr 2024 13:54:50 +0200
>> 
>> Andrea Corallo <acorallo@gnu.org> writes:
>> 
>> > PS last week I failed compiling MPS :/ I hope I can retry in the future
>> > and have a look.
>> 
>> Maybe Helmut could help you? He's on Debian.
>
> FTR, I've built MPS on Trisquel GNU/Linux with no trouble at all.
> There's a ready makefile in the tarball, you just need to run it.
>
> MPS doesn't use Autoconf (well, it does, but not the way we are used
> to).  Instead, for every platform it supports OOTB it has a makefile
> ready to run.

Okay thanks for the info, I tried ./configure + make on the repo
checking out the latest release but this failed on my machine.  Also I
was puzzled there are instruction to build it using only the compiler
like 'cd code && cc -O2 -c mps.c' (but I wanted have it installed as
well).

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Helmut Eller
>>>  <eller.helmut@gmail.com>
>>> Date: Tue, 30 Apr 2024 13:54:50 +0200
>>> 
>>> Andrea Corallo <acorallo@gnu.org> writes:
>>> 
>>> > PS last week I failed compiling MPS :/ I hope I can retry in the future
>>> > and have a look.
>>> 
>>> Maybe Helmut could help you? He's on Debian.
>>
>> FTR, I've built MPS on Trisquel GNU/Linux with no trouble at all.
>> There's a ready makefile in the tarball, you just need to run it.
>>
>> MPS doesn't use Autoconf (well, it does, but not the way we are used
>> to).  Instead, for every platform it supports OOTB it has a makefile
>> ready to run.
>
> Okay thanks for the info, I tried ./configure + make on the repo
> checking out the latest release but this failed on my machine.  Also I
> was puzzled there are instruction to build it using only the compiler
> like 'cd code && cc -O2 -c mps.c' (but I wanted have it installed as
> well).

Not sure this is helpful, because I'm on macOS.

I used ./configure --prefix=... in the repo as well, but needed a fix
that I posted as an issue to the project. It was something with an
unused variable that lead to an error because of -Werror.

Re: MPS: native comp

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   emacs-devel@gnu.org,
>   eller.helmut@gmail.com
> Date: Tue, 30 Apr 2024 09:05:40 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > FTR, I've built MPS on Trisquel GNU/Linux with no trouble at all.
> > There's a ready makefile in the tarball, you just need to run it.
> >
> > MPS doesn't use Autoconf (well, it does, but not the way we are used
> > to).  Instead, for every platform it supports OOTB it has a makefile
> > ready to run.
> 
> Okay thanks for the info, I tried ./configure + make on the repo
> checking out the latest release but this failed on my machine.  Also I
> was puzzled there are instruction to build it using only the compiler
> like 'cd code && cc -O2 -c mps.c' (but I wanted have it installed as
> well).

You should read manual/build.txt.  It tells you to run the following
to build MPS on a 64-bit GNU/Linux with GCC:

  cd code && make -f lii6gc.gmk

To test, read design/tests.txt; basically you should run

  cd code && make -f lii6gc.gmk VARIETY=cool testall
  cd code && make -f lii6gc.gmk VARIETY=hot testall

If you want to install it (not manually, but by "make install"), then
yes, you need to do

    ./configure --prefix=PREFIX
    make install

But then you are at the mercy of the few platforms supported by the
configure script (although for GNU/Linux you should be okay).

Re: MPS: native comp

[Visuwesh]

[செவ்வாய் ஏப்ரல் 30, 2024] Eli Zaretskii wrote:

>> Okay thanks for the info, I tried ./configure + make on the repo
>> checking out the latest release but this failed on my machine.  Also I
>> was puzzled there are instruction to build it using only the compiler
>> like 'cd code && cc -O2 -c mps.c' (but I wanted have it installed as
>> well).
>
> You should read manual/build.txt.  It tells you to run the following
> to build MPS on a 64-bit GNU/Linux with GCC:
>
>   cd code && make -f lii6gc.gmk
>
> To test, read design/tests.txt; basically you should run
>
>   cd code && make -f lii6gc.gmk VARIETY=cool testall
>   cd code && make -f lii6gc.gmk VARIETY=hot testall
>
> If you want to install it (not manually, but by "make install"), then
> yes, you need to do
>
>     ./configure --prefix=PREFIX
>     make install
>
> But then you are at the mercy of the few platforms supported by the
> configure script (although for GNU/Linux you should be okay).

If you're using a newer gcc though, you will get bit by a warning about
dangling-pointer and the build stops.  See https://github.com/Ravenbrook/mps/issues/256.

If I remove -Werror from the gc.gmk, I can finish the compilation.

Re: MPS: native comp

[Helmut Eller]

> If you want to install it (not manually, but by "make install"), then
> yes, you need to do
>
>     ./configure --prefix=PREFIX
>     make install
>
> But then you are at the mercy of the few platforms supported by the
> configure script (although for GNU/Linux you should be okay).

The configure script generates a beautifully simple Makefile.  For the
32-bit build, I edited this Makefile directly.

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> The exact algorith MPS implements I don't know either. The docs include
>>> some design documents, but I haven't read them all, and some I didn't
>>> understgand because there was some context missing.
>>>
>>> A number of possible algorithms that could be used are described in the
>>> literature, or one could glance at existing GCs for V8, for example.
>>> Hard to read though, for me at least.
>>
>> I think is mandatory that at least some of us understand at least the
>> high level mechanism of how MPS works otherwise before of later we will
>> be beaten by it somehow.
>
> Speaking for myself, I think I have some understanding.
>
> Opa telling stories from the good old times again :-): Back in, I don't
> remember exactly anymore, around the late 1890s ;-), not long after the
> invention of sliced bread, I was implementing a GC for Emacs that was
> very similar to MPS. Incremental, generational, mostly-copying,
> barriers, but not concurrent. Concurrency was not that big a thing back
> then ISTR. That was torpedoed hearing of the existemce of a software
> patent for the mostly-copying algorithm, which I consider a trivial idea
> :-(. (The patent has expired 10 years or so ago.)
>
> All that's left of that is a C source file I posted to emacs-devel when
> I left, which was also named igc.c, what a coincidence :-). I got that
> some time ago from Stefan Monnier, who had kept a copy. I seem to have
> lost it again. Not a loss.
>
> Be that as it may. What I eanted to say is that I feel for myself I have
> a good model of what MPS does in my head. I personally don't want to
> dive into details of its code. It's a library for me. A good one I'd
> say, and well documented. And if it does A or B is not important to me,
> unless I land there in a debugger, and then I can see it.

I don't have any doubt you have knowledge of GCs (I do as well to a
certain degree) or how the MPS interface works.  But still my basic
question is unanswered and we don't know how MPS can work reliably in a
parallel fashion moving objects.

> I'm actually trying to spread some knowledge by talking/writing too much
> sometimes. I know I'm in general not good at such things. And I'm of
> course not an encyclopedia, or professor for garbage collection.
>
>> My fear is that the GC requires the code is generated respecting some
>> property way we might not respect.  Other issues might rise in the
>> future if we don't understand all of this.
>
> No special casing required for MPS. If it's valid in C, it's fine.

Maybe depending on how the C is written (keeps local non volatile
references to objects) the collector can move objs or not in parallel?

Or maybe the moving part never happen in a parallel fashion? 🤷

I'm saying we'll have to understand all of this (willing or not).

Thanks

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> I'm saying we'll have to understand all of this (willing or not).

That's of course a valid standpoint.

I won't do it, though.

Re: MPS: native comp

[Peter Hull]

On Tue, 30 Apr 2024 at 11:53, Andrea Corallo <acorallo@gnu.org> wrote:

> I think is mandatory that at least some of us understand at least the
> high level mechanism of how MPS works otherwise before of later we will
> be beaten by it somehow.

I wonder, are the people at Ravenbrook aware of this work? The idea of
converting a project of the stature of emacs might be interesting
enough for them to give you some advice. There is a mailing list
though it seems somewhat 'moribund' :
https://mailman.ravenbrook.com/mailman/listinfo/mps-discussion
I didn't see any mention of emacs there, nor in their github issues/PR pages.

Peter

Re: MPS: native comp

[Gerd Möllmann]

Peter Hull <peterhull90@gmail.com> writes:

> On Tue, 30 Apr 2024 at 11:53, Andrea Corallo <acorallo@gnu.org> wrote:
>
>> I think is mandatory that at least some of us understand at least the
>> high level mechanism of how MPS works otherwise before of later we will
>> be beaten by it somehow.
>
> I wonder, are the people at Ravenbrook aware of this work? The idea of
> converting a project of the stature of emacs might be interesting
> enough for them to give you some advice. There is a mailing list
> though it seems somewhat 'moribund' :
> https://mailman.ravenbrook.com/mailman/listinfo/mps-discussion
> I didn't see any mention of emacs there, nor in their github issues/PR pages.

I sent them a mail with a pointer to the "experiment successf" post here
when I posted it. They ack'd.

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> 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.
>
> Well other than spirit and possibly simplicity we should evaluate if
> (and in case how much) is the cost to have this objects movable vs
> non-movable.

FYI:

I have ambig roots for the relocs, as an experiment. That brings us
further. Bootstrap.pdmp is built successfully, and some .elns are
successfully built, too. It fails eventually in one file:

  ./lisp.h:1631: Emacs fatal error: assertion failed: STRINGP (a)
  gmake[1]: *** [Makefile:285: ../lisp/files.elc] Abort trap: 6
  gmake: *** [Makefile:925: ../lisp/files.elc] Error 2

and it's super slow. The reasons for that I don't know, but I know for a
fact that I didn't do anything for CUs in the loaded dump, which is
probably not helpful.

I think I let this ripe a bit. Maybe I find the reference in macroexp,
and then don't need the roots. But I'll push it. 

Re: MPS: native comp

[Gerd Möllmann]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> 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.
>>
>> Well other than spirit and possibly simplicity we should evaluate if
>> (and in case how much) is the cost to have this objects movable vs
>> non-movable.
>
> FYI:
>
> I have ambig roots for the relocs, as an experiment. That brings us
> further. Bootstrap.pdmp is built successfully, and some .elns are
> successfully built, too. It fails eventually in one file:
>
>   ./lisp.h:1631: Emacs fatal error: assertion failed: STRINGP (a)
>   gmake[1]: *** [Makefile:285: ../lisp/files.elc] Abort trap: 6
>   gmake: *** [Makefile:925: ../lisp/files.elc] Error 2
>
> and it's super slow. The reasons for that I don't know, but I know for a
> fact that I didn't do anything for CUs in the loaded dump, which is
> probably not helpful.
>
> I think I let this ripe a bit. Maybe I find the reference in macroexp,
> and then don't need the roots. But I'll push it.

Good news, to close the evening, letting it simmer without thinking much
helped again. It's indeed simple: There are references we don't trace,
as one would naively expect.

- comp_unit
- ephemral relocs

I'll try that tomorrow, without the ambig roots.

Re: MPS: native comp

[Gerd Möllmann]

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

> Good news, to close the evening, letting it simmer without thinking much
> helped again. It's indeed simple: There are references we don't trace,
> as one would naively expect.
>
> - comp_unit
> - ephemral relocs
>
> I'll try that tomorrow, without the ambig roots.

That was it. I can now reliably build, up to the pdump step, with a
native-compiled macroexp.eln, which wasn't the case previously. Dumping
sometimes gets an error here:

dump_native_comp_unit (struct dump_context *ctx,
		       struct Lisp_Native_Comp_Unit *comp_u)
{
  if (!CONSP (comp_u->file))
      error ("trying to dump non fixed-up eln file");

It might be dependent on ASLR because it works reliably in LLDB but not
outside. That's the next step then.

Re: MPS: native comp

[Gerd Möllmann]

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

Hello Andrea,

I have a question that probably only you can answer quickly :-).

In the generated code we have things like

  struct Lisp_X *[227] d_reloc;

I would like the get the size of that array (and others that are
similar), ie. I would like to get the 227 above, and if possible without
relying on anything like the length of the array returned from
load_static_obj or computing the size from addresses like &sym1 - &sym2.

Is that possible? Is it somewhere in the C being emitted?

TIA

Re: MPS: native comp

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> Hello Andrea,
>
> I have a question that probably only you can answer quickly :-).
>
> In the generated code we have things like
>
>   struct Lisp_X *[227] d_reloc;
>
> I would like the get the size of that array (and others that are
> similar), ie. I would like to get the 227 above, and if possible without
> relying on anything like the length of the array returned from
> load_static_obj or computing the size from addresses like &sym1 - &sym2.
>
> Is that possible? Is it somewhere in the C being emitted?
>
> TIA

Kind of a progress report, with the request to anyone understanding
halfway what I say in my debug notes to chime in because I'm stuck. I'm
obviously overlooking something.

Summary of the problem:

Eln files contain an array of Lisp_Objects named d_reloc. Compiled
functions referring to Lisp_Objects load these from d_reloc, say
d_reloc[1]. Igc traces the contents of d_reloc; when objects move,
references are made to point to their new location in memory. So
theoreically the compiled functions should be fine. When a function
loads from d_reloc it gets a traced reference, when a reference is on
its stack, the object doesn't move, so the Lisp_Object doesn't change.

That's the theory. What I see instead is that in one case a compiled
function gets something from d_reloc that has _not_ been traced. In this
case, a symbol has been moved in memory, afaict d_reloc has been traced,
i.e. the symbol ref should be to the new location of the symbol, and
despite that, the compiled function passes the old location to Emacs C
core.

Please add "it looks as if, theoretically" and so on everywhere.

Like I said, I'm overlooking something, abviously.

Debug log with more detailed info attached. I'll let this ripe now for
myself.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Debug log --]
[-- Type: text/x-org, Size: 9604 bytes --]

* set_internal

Changed comp.el to native-compile-debug 3 and native-compile-speed 0.
Build from git clean -xdf, kill after macroexp been native-compiled.
Then

#+begin_src sh
  target create temacs
  settings set -- target.run-args --batch  -l loadup --temacs=pbootstrap --bin-dest /Users/gerd/emacs/savannah/igc/nextstep/Emacs.app/Contents/MacOS/ --eln-dest /Users/gerd/emacs/savannah/igc/nextstep/Emacs.app/Contents/Frameworks/
  command alias go process launch --working-dir .
  settings set target.disable-aslr false
#+end_src

Run N times until symbol in set_internal points to tombstone, and we abort.

#+begin_src sh
  (lldb) p *(struct igc_header *) client_to_base (sym)
  (struct igc_header)  (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074169, nwords = 7)
  (lldb) p *(struct igc_fwd *) client_to_base (sym)
  (struct igc_fwd) {
    header = (obj_type = IGC_OBJ_FWD, pvec_type = PVEC_FREE, hash = 1074169, nwords = 7)
    new_base_addr = 0x0000000110c6bb18
  }
  (lldb) p *(struct igc_header *) 0x0000000110c6bb18
  (struct igc_header)  (obj_type = IGC_OBJ_SYMBOL, pvec_type = PVEC_FREE, hash = 1074169, nwords = 7)
  (lldb) p *(struct Lisp_Symbol *) base_to_client ((void *) 0x0000000110c6bb18)
  (struct Lisp_Symbol) {
    u = {
      s = {
        gcmarkbit = false
        redirect = SYMBOL_PLAINVAL
        trapped_write = SYMBOL_UNTRAPPED_WRITE
        interned = SYMBOL_INTERNED_IN_INITIAL_OBARRAY
        declared_special = true
        pinned = false
        name = 0x0000000110529d94 (struct Lisp_String *) $8 = 0x0000000110529d90
        val = {
          value = 0x0000000110ca6b63 (struct Lisp_Cons *) $9 = 0x0000000110ca6b60
          alias = 0x0000000110ca6b63
          blv = 0x0000000110ca6b63
          fwd = (fwdptr = 0x0000000110ca6b63)
        }
        function = NULL
        plist = 0x0000000110529dbb (struct Lisp_Cons *) $10 = 0x0000000110529db8
        next = 0x0000000110529dd0
      }
      gcaligned = '\xc0'
    }
  }
  (lldb) xpostmortem
  (lldb) p *$8
  (struct Lisp_String) {
    u = {
      s = {
        size = 23
        size_byte = 23
        intervals = NULL
        data = 0x000000011051b5a8 "byte-compile-form-stack"
      }
      next = 0x0000000000000017
      gcaligned = '\x17'
    }
  }
  ##+end_src

  Comes from specbind with the broken symbol.

  ,#+begin_src sh
  (lldb) xbacktrace
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5e8 "macroexp--all-forms"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5e8 "macroexp--all-forms"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5e8 "macroexp--all-forms"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5e8 "macroexp--all-forms"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5e8 "macroexp--all-forms"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x000000011051b5e8 "macroexp--all-forms"
  (unsigned char *) data = 0x000000011051b5c8 "macroexp--expand-all"
  (unsigned char *) data = 0x0000000110c60780 "macroexpand--all-toplevel"
  (unsigned char *) data = 0x00000001014df2f0 "internal-macroexpand-for-load"
  (unsigned char *) data = 0x00000001014e104b "eval-buffer"
  (unsigned char *) data = 0x00000001014da312 "if"
  (unsigned char *) data = 0x00000001014da3e2 "let"
  (unsigned char *) data = 0x00000001014da3e2 "let"
  (unsigned char *) data = 0x00000001014da426 "unwind-protect"
  (unsigned char *) data = 0x00000001014da3e2 "let"
  (unsigned char *) data = 0x00000001014da312 "if"
  (unsigned char *) data = 0x0000000110c5b2f8 "load-with-code-conversion"
  (unsigned char *) data = 0x00000001014df6f9 "load"
  (unsigned char *) data = 0x00000001014df6f9 "load"

  (lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 6.1
    frame #0: 0x00000001014ba00c temacs`emacs_abort at sysdep.c:2391:3
    frame #1: 0x00000001011e67a8 temacs`set_internal(symbol=(struct Lisp_Symbol *) $156 = 0x0000000109612230, newval=(struct Lisp_Cons *) $157 = 0x0000000111244110, where=(struct Lisp_Symbol *) $158 = 0x0000000101c13a78, bindflag=SET_INTERNAL_BIND) at data.c:1665:14
    frame #2: 0x00000001012160e8 temacs`do_specbind(sym=0x0000000109612230, bind=0x000000014a032220, value=(struct Lisp_Cons *) $159 = 0x0000000111244110, bindflag=SET_INTERNAL_BIND) at eval.c:3444:9
  * frame #3: 0x000000010120bb44 temacs`specbind(symbol=(struct Lisp_Symbol *) $160 = 0x0000000109612230, value=(struct Lisp_Cons *) $161 = 0x0000000111244110) at eval.c:3531:3
  frame #4: 0x0000000101e39e54 macroexp-2c3e1495-76691d27.eln`F6d6163726f6578702d2d657870616e642d616c6c_macroexp__expand_all_0 + 116
    frame #5: 0x00000001012147f0 temacs`funcall_subr(subr=0x000000010a181528, numargs=1, args=(struct Lisp_Symbol *) $162 = 0x0000000270a8be90) at eval.c:3100:15

#+end_src

frame 3 does the specbind in the eln:

#+begin_src c
extern struct Lisp_X *
F6d6163726f6578702d2d657870616e642d616c6c_macroexp__expand_all_0 (struct Lisp_X * par_0)
{
  struct freloc_link_table * freloc;
  struct Lisp_X *[22] frame;
  struct comp_handler * c;

entry:
  freloc = freloc_link_table;
  /* Lisp function: macroexp--expand-all */
  frame[(int)0] = par_0;
  goto bb_0;

bb_0:
  frame[(int)1] = frame[(int)0];
  /* nil */
  /* const lisp obj: nil */
  /* calling subr: cons */
  frame[(int)1] = freloc->R636f6e73_cons_0 (frame[(int)1], (struct Lisp_X *)NULL);
  frame[(int)2] = frame[(int)1];
  /* calling subr: car-safe */
  frame[(int)2] = freloc->R6361722d73616665_car_safe_0 (frame[(int)2]);
  /* byte-compile-form-stack */
  /* const lisp obj: byte-compile-form-stack */
  /* l-value for lisp obj: byte-compile-form-stack */
  /* calling subr: symbol-value */
  frame[(int)3] = freloc->R73796d626f6c2d76616c7565_symbol_value_0 (d_reloc[(long)1]);
  /* calling subr: cons */
  frame[(int)2] = freloc->R636f6e73_cons_0 (frame[(int)2], frame[(int)3]);
  /* byte-compile-form-stack */
  /* const lisp obj: byte-compile-form-stack */
  /* l-value for lisp obj: byte-compile-form-stack */
  /* calling subr: specbind */
  (void)freloc->R7370656362696e64_specbind_0 (d_reloc[(long)1], frame[(int)2]);
  frame[(int)2] = frame[(int)1];
  /* calling subr: car-safe */
  frame[(int)2] = freloc->R6361722d73616665_car_safe_0 (frame[(int)2]);
#+end_src

Nothing suspicious to see, and it's speed 0. Debugging into this
doesn't work with LLDB OOTB. Have to investigate.

Can see by instrumenting igc that d_reloc[1] is traced and moved in
memory at various points.

#+begin_src sh
  (lldb) disassemble -f
macroexp-2c3e1495-76691d27.eln`F6d6163726f6578702d2d657870616e642d616c6c_macroexp__expand_all_0:
    0x1036c22ec <+0>:     stp    x29, x30, [sp, #-0xf0]!
    0x1036c22f0 <+4>:     mov    x29, sp
    0x1036c22f4 <+8>:     str    x19, [sp, #0x10]
    0x1036c22f8 <+12>:    str    x0, [sp, #0x28]
    0x1036c22fc <+16>:    adrp   x0, 19
    0x1036c2300 <+20>:    add    x0, x0, #0x9d0            ; freloc_link_table
    0x1036c2304 <+24>:    ldr    x0, [x0]
    0x1036c2308 <+28>:    str    x0, [sp, #0xe8]
    0x1036c230c <+32>:    ldr    x0, [sp, #0x28]
    0x1036c2310 <+36>:    str    x0, [sp, #0x38]
    0x1036c2314 <+40>:    nop
    0x1036c2318 <+44>:    ldr    x0, [sp, #0x38]
    0x1036c231c <+48>:    str    x0, [sp, #0x40]
    0x1036c2320 <+52>:    ldr    x0, [sp, #0xe8]
    0x1036c2324 <+56>:    ldr    x2, [x0, #0x2240]
    0x1036c2328 <+60>:    ldr    x0, [sp, #0x40]
    0x1036c232c <+64>:    mov    x1, #0x0                  ; =0
    0x1036c2330 <+68>:    blr    x2
    0x1036c2334 <+72>:    str    x0, [sp, #0x40]
    0x1036c2338 <+76>:    ldr    x0, [sp, #0x40]
    0x1036c233c <+80>:    str    x0, [sp, #0x48]
    0x1036c2340 <+84>:    ldr    x0, [sp, #0xe8]
    0x1036c2344 <+88>:    ldr    x1, [x0, #0x29d8]
    0x1036c2348 <+92>:    ldr    x0, [sp, #0x48]
    0x1036c234c <+96>:    blr    x1
    0x1036c2350 <+100>:   str    x0, [sp, #0x48]
    0x1036c2354 <+104>:   ldr    x0, [sp, #0xe8]
    0x1036c2358 <+108>:   ldr    x1, [x0, #0x2940]
    0x1036c235c <+112>:   adrp   x0, 18
    0x1036c2360 <+116>:   add    x0, x0, #0xee8            ; d_reloc
    0x1036c2364 <+120>:   ldr    x0, [x0, #0x8]
    0x1036c2368 <+124>:   blr    x1
    0x1036c236c <+128>:   str    x0, [sp, #0x50]
    0x1036c2370 <+132>:   ldr    x0, [sp, #0xe8]
    0x1036c2374 <+136>:   ldr    x2, [x0, #0x2240]
    0x1036c2378 <+140>:   ldr    x0, [sp, #0x48]
    0x1036c237c <+144>:   ldr    x1, [sp, #0x50]
    0x1036c2380 <+148>:   blr    x2
    0x1036c2384 <+152>:   str    x0, [sp, #0x48]
    0x1036c2388 <+156>:   ldr    x0, [sp, #0xe8]
    0x1036c238c <+160>:   ldr    x2, [x0, #0x60]
    0x1036c2390 <+164>:   adrp   x0, 18
    0x1036c2394 <+168>:   add    x0, x0, #0xee8            ; d_reloc
    0x1036 c2398 <+172>:   ldr    x0, [x0, #0x8]
    0x1036c239c <+176>:   ldr    x1, [sp, #0x48]
    0x1036c23a0 <+180>:   blr    x2
->  0x1036c23a4 <+184>:   ldr    x0, [sp, #0x40]
    0x1036c23a8 <+188>:   str    x0, [sp, #0x48]
    0x1036c23ac <+192>:   ldr    x0, [sp, #0xe8]
    0x1036c23b0 <+196>:   ldr    x1, [x0, #0x29d8]
    0x1036c23b4 <+200>:   ldr    x0, [sp, #0x48]
    0x1036c23b8 <+204>:   blr    x1
    0x1036c23bc <+208>:   str    x0, [sp, #0x48]

#+end_src

Disassemly looks totally as expectd, too. It uses d_reloc.

=> I'm overlooking something.

Re: MPS: native comp

[Gerd Möllmann]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Debug log with more detailed info attached. I'll let this ripe now for
> myself.

Just a tiny update to this:

Seems like the fact that I can't debug elns on the source level is
caused by the .eln not containing debug info that LLDB could use.
Oen can see with

  dsymutil -s macroexp-2c3e1495-76691d27.eln | grep N_OSO

GCC on contemporary macOS seems to have a similar problem, judging from
what I found on the Internet. Pity!

Re: MPS: native comp

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Helmut Eller
>  <eller.helmut@gmail.com>
> Date: Thu, 02 May 2024 16:08:28 +0200
> 
> Seems like the fact that I can't debug elns on the source level is
> caused by the .eln not containing debug info that LLDB could use.

That's true, but it's easy to fix by customizing native-comp-debug.

Re: MPS: native comp

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Helmut Eller
>>  <eller.helmut@gmail.com>
>> Date: Thu, 02 May 2024 16:08:28 +0200
>> 
>> Seems like the fact that I can't debug elns on the source level is
>> caused by the .eln not containing debug info that LLDB could use.
>
> That's true, but it's easy to fix by customizing native-comp-debug.

Alas, I've used native-comp-speed = 0, n-c-debug = 3 already.

Re: MPS: native comp

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: acorallo@gnu.org,  emacs-devel@gnu.org,  eller.helmut@gmail.com
> Date: Thu, 02 May 2024 17:56:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,  Helmut Eller
> >>  <eller.helmut@gmail.com>
> >> Date: Thu, 02 May 2024 16:08:28 +0200
> >> 
> >> Seems like the fact that I can't debug elns on the source level is
> >> caused by the .eln not containing debug info that LLDB could use.
> >
> > That's true, but it's easy to fix by customizing native-comp-debug.
> 
> Alas, I've used native-comp-speed = 0, n-c-debug = 3 already.

That should have produced debug info.  I know it worked for me with
GCC.

Re: MPS: native comp

[Helmut Eller]

> Kind of a progress report, with the request to anyone understanding
> halfway what I say in my debug notes to chime in because I'm stuck. I'm
> obviously overlooking something.

Is there some way to build with the compiler enabled but not actually
using it?  So that we could run the test suite first.  Or have you
already tried that?

Re: MPS: native comp

[Gerd Möllmann]

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

>> Kind of a progress report, with the request to anyone understanding
>> halfway what I say in my debug notes to chime in because I'm stuck. I'm
>> obviously overlooking something.
>
> Is there some way to build with the compiler enabled but not actually
> using it?  So that we could run the test suite first.  Or have you
> already tried that?

No, I haven't tried. And I don't know how to do either, alas.

Re: MPS: native comp

[Helmut Eller]

On Thu, May 02 2024, Gerd Möllmann wrote:

>> Is there some way to build with the compiler enabled but not actually
>> using it?  So that we could run the test suite first.  Or have you
>> already tried that?
>
> No, I haven't tried. And I don't know how to do either, alas.

make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
issue?

Re: MPS: native comp

[Gerd Möllmann]

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

> On Thu, May 02 2024, Gerd Möllmann wrote:
>
>>> Is there some way to build with the compiler enabled but not actually
>>> using it?  So that we could run the test suite first.  Or have you
>>> already tried that?
>>
>> No, I haven't tried. And I don't know how to do either, alas.
>
> make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
> the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
> issue?

No idea. I need some inspiration.

Re: MPS: native comp

[Helmut Eller]

On Thu, May 02 2024, Gerd Möllmann wrote:

>> make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
>> the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
>> issue?
>
> No idea. I need some inspiration.

For me, native compilation seems to work as it should.  How do I see
that something is broken?  Is this a macOS only problem?

Re: MPS: native comp

[Gerd Möllmann]

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

> On Thu, May 02 2024, Gerd Möllmann wrote:
>
>>> make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
>>> the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
>>> issue?
>>
>> No idea. I need some inspiration.
>
> For me, native compilation seems to work as it should.  How do I see
> that something is broken?  Is this a macOS only problem?

Ah, good idea! Maybe it's macOS...

I do git clean -xdf, then configure with native comp and build. This
step dumps bootstrap.pdmp successfully, loading all dumped stuff from
sources. After the dumping, some preloaded files are native-compiled,
among them macroexp.el.

After that step, I kill the build (it will abort later on anyway).

Then run temacs with the equivalent of the below in GDB

  target create temacs
  settings set -- target.run-args --batch  -l loadup --temacs=pbootstrap --bin-dest  --eln-dest
  command alias go process launch --working-dir .
  settings set target.disable-aslr false

This dumps bootstrap.pdmp, but this time macroexp.eln exists and gets
loaded for the dump. Please note the ASLR setting. Without ASLR, it
doesn't fail for me.

I sometimes have to run the stuff several times before it fails, and it
fails in different ways. I guess the interesting ones are aborts and alike.

Re: MPS: native comp

[Andrea Corallo]

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

> On Thu, May 02 2024, Gerd Möllmann wrote:
>
>>> make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
>>> the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
>>> issue?
>>
>> No idea. I need some inspiration.
>
> For me, native compilation seems to work as it should.  How do I see
> that something is broken?  Is this a macOS only problem?

You mention the bootstrap was not passing, is it still the case?  

Maybe the reason is the use of NATIVE_DISABLED dunno, but consider that
is the only big piece of code that we run in test-suite, the rest are all
small testcases poking at single features.

Thanks

  Andrea

Re: MPS: native comp

[Helmut Eller]

>>>> make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
>>>> the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
>>>> issue?
>>>
>>> No idea. I need some inspiration.
>>
>> For me, native compilation seems to work as it should.  How do I see
>> that something is broken?  Is this a macOS only problem?
>
> You mention the bootstrap was not passing, is it still the case?  
>
> Maybe the reason is the use of NATIVE_DISABLED dunno, but consider that
> is the only big piece of code that we run in test-suite, the rest are all
> small testcases poking at single features.

I disabled it because it takes so long.  And would probably not have
helped do create a smallish test case.  I have later enabled it and it
passes.

Re: MPS: native comp

[Andrea Corallo]

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

>>>>> make NATIVE_DISABLED=1 seems to do the trick.  I run the testsuite with
>>>>> the comp-tests-bootstrap disabled; the other tests simply passed.  Pdump
>>>>> issue?
>>>>
>>>> No idea. I need some inspiration.
>>>
>>> For me, native compilation seems to work as it should.  How do I see
>>> that something is broken?  Is this a macOS only problem?
>>
>> You mention the bootstrap was not passing, is it still the case?  
>>
>> Maybe the reason is the use of NATIVE_DISABLED dunno, but consider that
>> is the only big piece of code that we run in test-suite, the rest are all
>> small testcases poking at single features.
>
> I disabled it because it takes so long.  And would probably not have
> helped do create a smallish test case.  I have later enabled it and it
> passes.

Cool that's good sign!

Re: MPS: native comp

[Andrea Corallo]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> Hello Andrea,
>
> I have a question that probably only you can answer quickly :-).
>
> In the generated code we have things like
>
>   struct Lisp_X *[227] d_reloc;
>
> I would like the get the size of that array (and others that are
> similar), ie. I would like to get the 227 above, and if possible without
> relying on anything like the length of the array returned from
> load_static_obj or computing the size from addresses like &sym1 - &sym2.
>
> Is that possible? Is it somewhere in the C being emitted?
>
> TIA

Hi Gerd,

I don't think it's emitted in the eln, should be added or some other way
as to be used.

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Hi Gerd,

Hi Andrea!

> I don't think it's emitted in the eln, should be added or some other way
> as to be used.

We can do without, I just wanted to make sure that it isn't somewhere.
Thanks!

Re: MPS: native comp

[Andrea Corallo]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>>> 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.
>>>
>>> Well other than spirit and possibly simplicity we should evaluate if
>>> (and in case how much) is the cost to have this objects movable vs
>>> non-movable.
>>
>> FYI:
>>
>> I have ambig roots for the relocs, as an experiment. That brings us
>> further. Bootstrap.pdmp is built successfully, and some .elns are
>> successfully built, too. It fails eventually in one file:
>>
>>   ./lisp.h:1631: Emacs fatal error: assertion failed: STRINGP (a)
>>   gmake[1]: *** [Makefile:285: ../lisp/files.elc] Abort trap: 6
>>   gmake: *** [Makefile:925: ../lisp/files.elc] Error 2
>>
>> and it's super slow. The reasons for that I don't know, but I know for a
>> fact that I didn't do anything for CUs in the loaded dump, which is
>> probably not helpful.
>>
>> I think I let this ripe a bit. Maybe I find the reference in macroexp,
>> and then don't need the roots. But I'll push it.
>
> Good news, to close the evening, letting it simmer without thinking much
> helped again. It's indeed simple: There are references we don't trace,
> as one would naively expect.
>
> - comp_unit
> - ephemral relocs

I think is not correct to add ephemral relocs to the compilation unit.
They are not reachable by the GC from that path on purpose, so that
after the load procedure they get GCed.

If MPS is scanning the stack as our GC does it should just work.  Are we
sure this modification was necessary?

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> I think is not correct to add ephemral relocs to the compilation unit.
> They are not reachable by the GC from that path on purpose, so that
> after the load procedure they get GCed.

>
> If MPS is scanning the stack as our GC does it should just work.  Are we
> sure this modification was necessary?

Yes.

I've read that comment.

      /* Note: data_ephemeral_vec is not GC protected except than by
	 this function frame.  After this functions will be
	 deactivated GC will be free to collect it, but it MUST
	 survive till 'top_level_run' has finished his job.  We store
	 into the ephemeral allocation class only objects that we know
	 are necessary exclusively during the first load.  Once these
	 are collected we don't have to maintain them in the heap
	 forever.  */

The problem is not liveness, it's the existence of untraced references
there.

It's easy to tell igc when these references are definitely no longer in
use, by setting a cu member to NULL. Then igc will no longer trace them.

Haven't done that yet

# ifdef HAVE_MPS
	  /* FIXME: If we want to get rid of these objects, stop tracing
	     these references at some point.  */
	  comp_u->data_eph_relocs = data_eph_relocs;
	  comp_u->n_data_eph_relocs = d_vec_len;
# endif

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> I think is not correct to add ephemral relocs to the compilation unit.
>> They are not reachable by the GC from that path on purpose, so that
>> after the load procedure they get GCed.
>
>>
>> If MPS is scanning the stack as our GC does it should just work.  Are we
>> sure this modification was necessary?
>
> Yes.
>
> I've read that comment.
>
>       /* Note: data_ephemeral_vec is not GC protected except than by
> 	 this function frame.  After this functions will be
> 	 deactivated GC will be free to collect it, but it MUST
> 	 survive till 'top_level_run' has finished his job.  We store
> 	 into the ephemeral allocation class only objects that we know
> 	 are necessary exclusively during the first load.  Once these
> 	 are collected we don't have to maintain them in the heap
> 	 forever.  */
>
> The problem is not liveness, it's the existence of untraced references
> there.

Yes but this way seems that there's no way to tell the GC that something
exists other than making it reachable from the heap.  There's really no
better way to tell MPS at runtime that a certain obj was allocated and
needs to be tracked?

Thanks

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Yes but this way seems that there's no way to tell the GC that something
> exists other than making it reachable from the heap.  There's really no
> better way to tell MPS at runtime that a certain obj was allocated and
> needs to be tracked?

I'm sorry, I don't understand. Could you perhaps rephrase?

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Yes but this way seems that there's no way to tell the GC that something
>> exists other than making it reachable from the heap.  There's really no
>> better way to tell MPS at runtime that a certain obj was allocated and
>> needs to be tracked?
>
> I'm sorry, I don't understand. Could you perhaps rephrase?

I suspect ATM don't have a better way to express that.

You said:

> The problem is not liveness, it's the existence of untraced references
> there.

So my question is, there's really no way to express to MPS the
'existence' of an object without impacting his 'liveness'?

This case is supported by alloc.c as the change in discussion
demonstrates.

Thanks

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> You said:
>
>> The problem is not liveness, it's the existence of untraced references
>> there.
>
> So my question is, there's really no way to express to MPS the
> 'existence' of an object without impacting his 'liveness'?
>
> This case is supported by alloc.c as the change in discussion
> demonstrates.

Hm, let me try. I don't know what exactly you are asking, but maybe
explaining it in different way helps. So, ...

We have two things at hand

 1. liveness
 2. references

Liveness with MPS and old GC is handled the same way. We have something
on the stack, as an example, and that fact keeps it alive. No problem.

References are different in MPS and old GC.

In the old GC, _all_ references to live objects are _always_ correct
because objects never move in memory.

With MPS this is not the case. Unless we do something, only references
that are _traced_ (updated) are guranteed to be correct, if an object
ever moves. Or, alternatively we prevent an object from moving.

I think the following C is similar to what we have in our case:

Lisp_Object global;

void foo ()
{
  Lisp_Object v = Fread (....);
  global = AREF (v, 0);

  do_something ();
  // MPS kicks in when we rea here
  do_something_else (global);
}

We read new a vector v from some string. This keeos the vector and its
contents alive because it is on the stack.

But, please note that only v is on the stack. The contents are _not_ on
the stack. Means, in the MPS case, that only v cannot move in memory.
Its contents _can_ move.

In the C code above, when we reach do_something_else, this means that
the reference in global may be invalid because v->contents[0] has
meanwhile moved.

Is that of help?

Re: MPS: native comp

[Gerd Möllmann]

Hi Andrea,

simply question this time: Could you please point me to where in the
code a compilation units file, comp_u->file becomes a cons instead of a
string?

Thanks!

Re: MPS: native comp

[Andrea Corallo]

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

> Hi Andrea,
>
> simply question this time: Could you please point me to where in the
> code a compilation units file, comp_u->file becomes a cons instead of a
> string?
>
> Thanks!

Hi Gerd,

sure, should be 'load--fixup-all-elns' defined in loadup.el is called
from pdumper.c :)

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Hi Andrea,
>>
>> simply question this time: Could you please point me to where in the
>> code a compilation units file, comp_u->file becomes a cons instead of a
>> string?
>>
>> Thanks!
>
> Hi Gerd,
>
> sure, should be 'load--fixup-all-elns' defined in loadup.el is called
> from pdumper.c :)

Thanks!

I came to the conclusion now that this has nothing to do with igc. It's
some artefact of the build procedure,

Short summary what the scenario is: Build from git clean -xdf with
native comp. Build fails at some point after native compiling macroexp.
Gmake in src/ again. Dumping bootstrap.pdmp fails here:

dump_native_comp_unit (struct dump_context *ctx,
		       struct Lisp_Native_Comp_Unit *comp_u)
{
  if (!CONSP (comp_u->file))
    error ("trying to dump non fixed-up eln file");

The CU in question is macroexp

  "/Users/gerd/emacs/github/igc/native-lisp/30_0_50-3a137b7d/preloaded/macroexp-2c3e1495-76691d27.eln"

Maybe --eln-dest is not set right in this scenario, or whatever it is.
In any case, this doesn't look interesting for igc.

Maybe one could improve the error message? 

Re: MPS: native comp

[Gerd Möllmann]

Hi Andrea,

another entirely trivial question :-). Could you please explain what
this is is (C from eln)?

struct comp_handler
{
  char[24] pad0;
  struct Lisp_X * val;
  struct comp_handler * next;
  char[20] pad1;
  struct comp_jmp_buf jmp;
  char[36] pad2;
};

struct comp_thread_state
{
  char[96] pad0;
  struct comp_handler * m_handlerlist;
  char[416] pad1;
};

in particular comp_handler::val? And how this is used:

struct comp_thread_state * * current_thread_reloc;

TIA

Re: MPS: native comp

[Gerd Möllmann]

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

> Hi Andrea,
>
> another entirely trivial question :-). Could you please explain what
> this is is (C from eln)?
>
> struct comp_handler
> {
>   char[24] pad0;
>   struct Lisp_X * val;
>   struct comp_handler * next;
>   char[20] pad1;
>   struct comp_jmp_buf jmp;
>   char[36] pad2;
> };
>
> struct comp_thread_state
> {
>   char[96] pad0;
>   struct comp_handler * m_handlerlist;
>   char[416] pad1;
> };
>
> in particular comp_handler::val? And how this is used:
>
> struct comp_thread_state * * current_thread_reloc;
>

Or maybe more specific because I think I got what that is. It's
&current_thread, right?

Current_thread is staticpro'd, so in Emacs we'll fix that if a
thread_sate moves in memory. But what does/could GCC assume about this,
or maybe comp?

Re: MPS: native comp

[Andrea Corallo]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Hi Andrea,
>>
>> another entirely trivial question :-). Could you please explain what
>> this is is (C from eln)?
>>
>> struct comp_handler
>> {
>>   char[24] pad0;
>>   struct Lisp_X * val;
>>   struct comp_handler * next;
>>   char[20] pad1;
>>   struct comp_jmp_buf jmp;
>>   char[36] pad2;
>> };
>>
>> struct comp_thread_state
>> {
>>   char[96] pad0;
>>   struct comp_handler * m_handlerlist;
>>   char[416] pad1;
>> };
>>
>> in particular comp_handler::val? And how this is used:
>>
>> struct comp_thread_state * * current_thread_reloc;
>>
>
> Or maybe more specific because I think I got what that is. It's
> &current_thread, right?

Hi Gerd, AFAIR comp_handler is the equivalent of 'struct handler' and
"struct comp_thread_state * * current_thread_reloc" is a pointer to
'current_thread'.

> Current_thread is staticpro'd, so in Emacs we'll fix that if a
> thread_sate moves in memory. But what does/could GCC assume about this,
> or maybe comp?

I think we'll have to update "struct comp_thread_state * *
current_thread_reloc" as well if 'current_thread' moves.

Hope it helps.

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

>> Current_thread is staticpro'd, so in Emacs we'll fix that if a
>> thread_sate moves in memory. But what does/could GCC assume about this,
>> or maybe comp?
>
> I think we'll have to update "struct comp_thread_state * *
> current_thread_reloc" as well if 'current_thread' moves.

Thanks.

BTW, is there a way to let libgccjit keep to .o file together with the
.c file?

I'm asking because the .elns don't have debug info on macOS (for a
long-winded reason that made macOS handle DWARF differently from the
rest). If I had a .o with debug info, I could maybe generate .dSYM
files.

Re: MPS: native comp

[Gerd Möllmann]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> Current_thread is staticpro'd, so in Emacs we'll fix that if a
>>> thread_sate moves in memory. But what does/could GCC assume about this,
>>> or maybe comp?
>>
>> I think we'll have to update "struct comp_thread_state * *
>> current_thread_reloc" as well if 'current_thread' moves.
>
> Thanks.
>
> BTW, is there a way to let libgccjit keep to .o file together with the
> .c file?
>
> I'm asking because the .elns don't have debug info on macOS (for a
> long-winded reason that made macOS handle DWARF differently from the
> rest). If I had a .o with debug info, I could maybe generate .dSYM
> files.

Good news! I think I know what's going on, 100% - epsilon.

The error occurs in an Emacs that has a pdump loaded. (I submitted a bug
concerning the build process. The workaround for this made it much
easier for me to recognize what's going on.)

The loaded dump contains, among other things, native compilation unit
objects. These objects contain pointers into the loaded .eln for things
that we need to trace. For CUs that are in MPS memory, this is done by
fix_comp_unit and all it good. For CUs in the dump this is not done,
simply because they are not in MPS memory but in the hot segment of the
loaded dump. Result is that references in these .eln are not fixed, and
so on.

In the end, it's always the same problem with the dump. The dump is not
in MPS, MPS knows only traces as an ambig root.

I guess we should do something about this. Maybe we could try Helmut's
idea of copying the objects to MPS.

Meanwhile, I'll try to come up with a workaround.

Re: MPS: native comp

[Gerd Möllmann]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>>> Current_thread is staticpro'd, so in Emacs we'll fix that if a
>>>> thread_sate moves in memory. But what does/could GCC assume about this,
>>>> or maybe comp?
>>>
>>> I think we'll have to update "struct comp_thread_state * *
>>> current_thread_reloc" as well if 'current_thread' moves.
>>
>> Thanks.
>>
>> BTW, is there a way to let libgccjit keep to .o file together with the
>> .c file?
>>
>> I'm asking because the .elns don't have debug info on macOS (for a
>> long-winded reason that made macOS handle DWARF differently from the
>> rest). If I had a .o with debug info, I could maybe generate .dSYM
>> files.
>
> Good news! I think I know what's going on, 100% - epsilon.
>
> The error occurs in an Emacs that has a pdump loaded. (I submitted a bug
> concerning the build process. The workaround for this made it much
> easier for me to recognize what's going on.)
>
> The loaded dump contains, among other things, native compilation unit
> objects. These objects contain pointers into the loaded .eln for things
> that we need to trace. For CUs that are in MPS memory, this is done by
> fix_comp_unit and all it good. For CUs in the dump this is not done,
> simply because they are not in MPS memory but in the hot segment of the
> loaded dump. Result is that references in these .eln are not fixed, and
> so on.
>
> In the end, it's always the same problem with the dump. The dump is not
> in MPS, MPS knows only traces as an ambig root.
>
> I guess we should do something about this. Maybe we could try Helmut's
> idea of copying the objects to MPS.
>
> Meanwhile, I'll try to come up with a workaround.

Bad news! I added a workaround but it's not the fix.

At least not completely. The build with native compilation still fails,
at a different point, but with the same symptom that we hit an unfixed
reference. This time Ffuncall is called from a native-compiled
bytecomp--check-eq-args with a symbol pointing to a tombstone.

So the original question how to get debug info for .elns (maybe by
keeping .o files, as I mentioned) is still important.

I'll transfer what I have later to scratch/igc.

Re: MPS: native comp

[Andrea Corallo]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>>> Current_thread is staticpro'd, so in Emacs we'll fix that if a
>>> thread_sate moves in memory. But what does/could GCC assume about this,
>>> or maybe comp?
>>
>> I think we'll have to update "struct comp_thread_state * *
>> current_thread_reloc" as well if 'current_thread' moves.
>
> Thanks.
>
> BTW, is there a way to let libgccjit keep to .o file together with the
> .c file?

Hi Gerd,

not that I'm aware.

Maybe you could ask on jit@gcc.gnu.org?

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>>> Current_thread is staticpro'd, so in Emacs we'll fix that if a
>>>> thread_sate moves in memory. But what does/could GCC assume about this,
>>>> or maybe comp?
>>>
>>> I think we'll have to update "struct comp_thread_state * *
>>> current_thread_reloc" as well if 'current_thread' moves.
>>
>> Thanks.
>>
>> BTW, is there a way to let libgccjit keep to .o file together with the
>> .c file?
>
> Hi Gerd,
>
> not that I'm aware.
>
> Maybe you could ask on jit@gcc.gnu.org?
>
>   Andrea

Thanks

Re: MPS: native comp

[Andrea Corallo]

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Progress. Same scenario as before and we come to pdumping, but it
>> complains
>>
>>   ./temacs --batch  -l loadup --temacs=pbootstrap \
>>           --bin-dest  --eln-dest
>>   ...
>>   Loading emacs-lisp/macroexp (native compiled elisp)...
>>   ..
>>   Dumping under the name bootstrap-emacs.pdmp
>>   Dumping fingerprint: 4ff41caeb772618cf9be4dd61ae8a1cf909c29b0ff417318ec6039950eaf53fc
>>
>>   Error: error ("trying to dump non fixed-up eln file")
>>
>
> Actually, and strangely, I get a different error when running under
> LLDB.
>
>   Loading /Users/gerd/emacs/savannah/igc/lisp/emacs-lisp/cl-generic.el (source)...
>   Loading /Users/gerd/emacs/savannah/igc/lisp/simple.el (source)...
>
>   Error: error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)")
>     signal(error ("Eager macro-expansion failure: (setting-constant byte-compile-form-stack)"))
>
> In a way that makes more sense because we saw that "Eager..." string
> before. byte-compile-form-stack is a var defined in macroexp.
>
> Does someone know what "eager" macro expansion means? In what way is it
> eager? Or different from non-eager (lazy?) macro expansion? But why
> would ME be lazy? Questions about questions...

AFAIU it's when we do macro expansions before execution, read every time
we byte/native compile.  The error typically implies something goes
wrong in the macro expander (which is one of the first native compiled
pieces of code leveraged during a native bootstrap).

IOH native compiled code is probably still not functional for some
reason.  A simpler testcase should help narrowing down the issue
excluding all the bootstrap complexity.

  Andrea

Re: MPS: native comp

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> AFAIU it's when we do macro expansions before execution, read every time
> we byte/native compile.  The error typically implies something goes
> wrong in the macro expander (which is one of the first native compiled
> pieces of code leveraged during a native bootstrap).
>
> IOH native compiled code is probably still not functional for some
> reason.  A simpler testcase should help narrowing down the issue
> excluding all the bootstrap complexity.

Thanks