Re: [EXPERIMENT] Emacs with the SpiderMonkey garbage collector

[Pip Cet]

On Fri, Nov 24, 2017 at 8:07 AM, Paul Eggert <address@hidden> wrote:
> Wow

Thank you.

> sounds like you've done some interesting things, and it's interesting
> to see that you got it to work at all with a copying collector.

"At all" being about the limit of it, at present. While I managed to
write that email without a segfault, there are plenty of race
conditions that I'm aware of. I think we're fine in theory, though,
once we make sure that signal handlers cannot trigger GC. (If my
understanding is correct, signals can occur after every instruction,
including in the middle of a call sequence while the argument, or
return value, is unprotected).

>> I do advocate making the
>> official Emacs compile with G++ with the -fpermissive option, to help
>> further experiments.
>
> What changes would this entail? If you're already running Emacs through a
> C-to-C++ converter, why can't the converter arrange for the changes itself?

You're right, I should be clearer on this point: I want to help out
others who decide not to use my converter, not myself.

One thing that current stable versions of g++ are missing is
structured initializers, and I decided to convert the few instances we
have of those by hand rather than write code to do it. I think, but
I'm not sure, that the current development version of g++ will
correctly deal with those, though.

Another thing is nested structs/enums/unions. I think those are bad
style in addition to presenting a portability concern, even though
they're easy to catch for the converter.

The most vexing issue for me right now is that I haven't figured out
how to get gnulib working with g++ without modifying files after every
sh autogen.sh, though. I admit I don't understand the gnulib build
process at all, so any hints would be appreciated.

The other issues are minor (a union and a typedef sharing a name, C++
keywords, enums treated as ints), but overall it seems a potential
deterrent to people who want to just try linking a C++ library to
Emacs as an experiment, without using my converter.

>>  - dumping (I'm currently using CANNOT_DUMP=yes. Is that supposed to
>> work? Because it doesn't without a few changes to the initial Lisp
>> files.)

> It is supposed to work. Admittedly it's not tested much. We really need to
> move away from the current dumping model anyway, so CANNOT_DUMP mode will
> grow in importance (in some sense).

I'll open a bug for the CANNOT_DUMP issue. While I've got a fairly
good overview regarding the C code, now, I don't understand the Lisp
bootstrapping process, which appears to be the issue...

What do you think about the future of pure space? That also seems to
me to be an optimization that might no longer be worth it, and perhaps
to add even more complexity to the code than dumping does.

>> [1] - there's one place that uses "false" for "NULL"
>
> Please let us know where, and we'll fix it.

Patch attached.

0001-Use-NULL-for-NULL-rather-than-false.patch
Description: Text Data