Realms aka agents support

[playXE]

Right now there is a single global object per runtime instance but ECMA262 defines realms.

https://262.ecma-international.org/#sec-code-realms

[jameslahm]

I'd like to work on this~

[andrieshiemstra]

Yeah this would be cool, quickjs calls these contexts

[playXE]

@jameslahm if you want to work on them I'll assign you to this issue. :)

[andrieshiemstra]

My main reason for being interested in Realms is the ability to share loaded modules between Realms

The downside of doing this with spidermonkey/quickjs is that they don't realy provide control over how and how many modules are stored or cached.. this means that my projects need to shutdown and restart Runtimes every now and then to unload modules.

It would be nice if starlight got the ability to access the loaded modules in the Runtime, and be able to unload them.. and/or controll how many are cached for how long...

[playXE]

@andrieshiemstra I think you can already unload modules just fine because they are stored inside HashMap<String,ModuleKind> so that should not be a big problem. Why I want realms is that because they make it easy to run test262 suite. Right now for each test262 test new runtime instance is created which takes some time: allocate 2GB of memory for GC, setup heap free list, etc. This time is not the slowest tho, Snapshots help to save it by a lot and running test262 does not take ten or twenty minutes but just a few minutes and now imagine how much time could be saved when there will be realms that are much cheaper compared to runtime.

[andrieshiemstra]

Ok, and implementation wise, would there be a way for JsNativeFunctions to lookup the current realm? or even pass the &Realm to native unctions?

E.g. i'm working on a fetch api and would like to define the function and structs once at runtime/global level but init a CookieContainer per Realm

[playXE]

I think realms should be stored inside the runtime and to access them Runtime::realm() should be used or something like that.

[playXE]

Hmm Starlight's new GC allows us to get access to runtime instance from any GC allocated object so I guess this could also be used to obtain realm or runtime instance when you do not have direct access to it. It is possible due to how heap is implemented. We can identify small objects allocated inside blocks and it allows us to store runtime instance in the block and for large allocation runtime instance pointer can be stored directly in the header.

fn get_rt<T>(obj: GcPointer<T>) -> RuntimeRef {
    if obj.is_precise() {
       PreciseAllocation::from_cell(obj).runtime
    } else {
       Block::from_cell(obj).runtime
    }
}