Initialization and the lazy freezing algorithm

[jfparadis]

For lazy freezing, we have been discussing the following changes.

Below we distinguish eager freezing (at initialization) and lazy freezing (on demand).

A. Overall process

Create the realm object, in this case a root realm with it own set of intrinsic.
Let the developer adds objects to the global and or alter the intrinsic.
Let the developer call a method to freeze the realm.
B. Performance optimization (suggestion)
Update the evaluator to declare updated list of frozen objects (as long as the references to those objects are frozen on the global.

C. What to eager freeze
The whole standard lib (which saves 5 ms) except "intl" (which saves 2 ms).

D. Augment the set to eager freeze (suggestion)
Between creation and freezing, any object accessed on the global should be eager-frozen.

E. The init hook vs a "freeze" method.
The current specs rely on the init hook:

11.5.1 Realm.prototype.init()
Note Extensible web: This is the dynamic way to define globals in a new realm
The init hook is invoked by the constructor. Some could see this as an anti-pattern because if something fails during the init, the developer is left without an a resource. Also, constructor should be simple, otherwise they are hard to test. They typically initialize fields, and actual work is done elsewhere, according to SRP.

The init method of the current specs can be simply achieved by a subclass:

class myRealm extends Realm {
constructor(options) {
super(options);
// do the init work here.
}
}
On the other hand, having to call a method to complete the initialization can be seen as going against the RAII principle. The developer must remember to call the init, and until then the object is in an unfinished state and should not be used.

It seems advantageous to create a fully functional realm, as opposed to a "frozen realm on standby", and have the method doing the freeing also do the conversion from realm to frozen realm.