Self-Hosted Code outside SpiderMonkey Tree?

I have embedded the TypeScript compiler in SpiderMonkey.  The way I did 
it was to add the minimal JSNative functions needed to support what the 
compiler needs. If you're curious, grab the TypeScript source look at 
Typescript/src/compiler/sys.ts.

The way I package this is to suck the whole compiler (tsc.js) file into 
a C++ string, and evaluate it after injecting the things I care about -- 
the files to compile, the language flags, etc.

When poking around in the SpiderMonkey shell, I notice that it uses 
self-hosted code to implement the ModuleLoader.  This does exactly what 
I do, but it looks like it requires being inside the SpiderMonkey build 
tree, including tools in js/src/builtin.

Is there any advantage to trying to use self-hosting? Signs point to 
'no' -- looking here: 
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/self-hosting

0
Kent
8/3/2018 6:14:38 PM
mozilla.dev.tech.js-engine 2023 articles. 0 followers. Post Follow

2 Replies
15 Views

Similar Articles

[PageSpeed] 22

On 08/03/2018 11:14 AM, Kent Williams wrote:
> I have embedded the TypeScript compiler in SpiderMonkey.  The way I did 
> it was to add the minimal JSNative functions needed to support what the 
> compiler needs. If you're curious, grab the TypeScript source look at 
> Typescript/src/compiler/sys.ts.

Heh. Sounds pretty crazy, and cool.

> When poking around in the SpiderMonkey shell, I notice that it uses 
> self-hosted code to implement the ModuleLoader.  This does exactly what 
> I do, but it looks like it requires being inside the SpiderMonkey build 
> tree, including tools in js/src/builtin.
> 
> Is there any advantage to trying to use self-hosting? Signs point to 
> 'no' -- looking here: 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/self-hosting 

I doubt it. You'd probably have to modify the TypeScript compiler to 
compile down to self-hosted SpiderMonkey code instead of JS (eg, replace 
every single function call with callFunction()), then compile the 
original TS->JS compiler with that. I've never written anything in 
self-hosted code, only read it, but self-hosted code feels like an 
incredibly restrictive environment. I think it also gets cloned in a 
weird way to every compartment that uses it.
0
Steve
8/3/2018 9:58:32 PM
On 08/03/2018 11:14 AM, Kent Williams wrote:
> I have embedded the TypeScript compiler in SpiderMonkey.  The way I did 
> it was to add the minimal JSNative functions needed to support what the 
> compiler needs. If you're curious, grab the TypeScript source look at 
> Typescript/src/compiler/sys.ts.

Heh. Sounds pretty crazy, and cool.

> When poking around in the SpiderMonkey shell, I notice that it uses 
> self-hosted code to implement the ModuleLoader.  This does exactly what 
> I do, but it looks like it requires being inside the SpiderMonkey build 
> tree, including tools in js/src/builtin.
> 
> Is there any advantage to trying to use self-hosting? Signs point to 
> 'no' -- looking here: 
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/self-hosting 

I doubt it. You'd probably have to modify the TypeScript compiler to 
compile down to self-hosted SpiderMonkey code instead of JS (eg, replace 
every single function call with callFunction()), then compile the 
original TS->JS compiler with that. I've never written anything in 
self-hosted code, only read it, but self-hosted code feels like an 
incredibly restrictive environment. I think it also gets cloned in a 
weird way to every compartment that uses it.
0
Steve
8/3/2018 9:58:32 PM
Reply: