When does this get initialized? At runtime start?

Yes, when the context is initialized, in JS_AddIntrinsicBaseObjects.

Not a huge fan of this TBH. I was wondering if the following makes any sense:

• have the JS code as a string in the C code
• lazily byte-compile and eval it, ideallly on first use
• profit?

WDYT?

A better approach would be to compile this and possibly other APIs to bytecode as part of the build process and embed said bytecode in the interpreter binary. The APIs would still need to be instantiated lazily upon use but they would be available even if the compiler code is not linked in an embedded target.

have the JS code as a string in the C code [..] profit?

No profit, only loss. Takes more work at runtime and embedding the source is twice as big as the bytecode.

@chqrlie I don't understand your comment vis-a-vis embedded target. edit: oh, I do - that was addressing Saúl.

A better approach would be to compile this and possibly other APIs to bytecode as part of the build process and embed said bytecode in the interpreter binary

Doing it as part of the build results in a chicken and egg problem though. I have a lot of experience with the way V8 does two stage builds and it's miserable.

The approach I picked here (generate ahead of time and commit artifact) results in the least amount of ongoing work, I'm fairly sure.

Yes, it was possible to create smaller executables with embedded byte code but without the eval function, hence without the compiler code. This should still be possible with the current code, with manual C compilation.

#include "gen/builtin-array-fromasync.h"

This implies that future built-in bytecode functions will be placed in separate files.
Would it be possible to concatenate them into a single file (say, builtins.h) instead? That would keep copy-paste vendoring easier, as we'd have to copy just one new file instead of N new files.

It's all in a single file if you use the amalgamated build. If that doesn't work for you, let me know; I'm not going to say yes or no straight away but I can take it into consideration.

FWIW, it's probably academic for the foreseeable future. I don't see us adding too many builtins in this way, only ones that would be extremely onerous to write in C.

I've considered switching to the amalgamation, the problem is that it would make patching too inconvenient.
Right now, I can just develop and commit patches on top of my vendored copy; with the amalgamation I'd have to run a separate build step to even test a patch, then also maintain a separate repository to publish the patched sources.

Why is that? In my own projects I vendor the amalgamation and float any patches I carry on top of that.

You mean to develop/apply the patches on top of the amalgamation? I guess the main drawback is that it becomes harder to borrow/upstream them.
(I feel uneasy about manually editing autogenerated artifacts in general; e.g. if the script changed the order of files on update, I'd have to manually apply everything again. But maybe my fears are unfounded.)

Having typed this out, I've just remembered another thing: I have a binary that depends on libregexp and only libregexp, so I'd also have to patch the generator script to support this somehow.