784303 - self-hosting: support running initialization code on global-creation

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Till Schneidereit [:till]]

In order to enable self-initialization of self-hosted code and full setup of self-hosted builtins from JS, it should be possible to run JS initialization functions when creating a new global object.

Simply running one specific function would be trivial, but also very restrictive: it would force authors of new JS builtins to change a central location for what should be a local change to their builtin code.

Instead, it might be a good idea to add a macro that allows for registering callbacks to be invoked upon initialization. This could look like the following:

%_RegisterInitializer(myInitializer);

Internally, this would then add `myInitializer` to a list of functions to be run on global creation.

Comment 1

[Till Schneidereit [:till]]

Attachment: for posterity

Luke and Ms2Ger have convinced me that executing JS code on every global creation isn't a good idea after all.

Hence, this'll probably be WONTFIX'd. The added patch is what I came up with before the change of mind; I'm posting it just in case it should ever be useful in any way.

Comment 2

[Till Schneidereit [:till]]

We can always reopen if we decide we want this after all.

Comment 3

[Norbert Lindenberg]

What are the arguments against doing this?

I was really looking forward to setting up objects of the ECMAScript Internationalization API from JavaScript rather than from C++...

Comment 4

[Till Schneidereit [:till]]

(In reply to Norbert Lindenberg from comment #3)
> What are the arguments against doing this?
> 
> I was really looking forward to setting up objects of the ECMAScript
> Internationalization API from JavaScript rather than from C++...

You'll still be able to do that, once at least bug 784400 and bug 784293 are fixed.

The difference is that the setup code will be run once after initial compilation of the self-hosted code instead of on each global creation.

The argument against the latter is that it'd make global creation quite a bit more expensive and would force eager cloning of all objects used by initialization code.