sq / JSIL

CIL to Javascript Compiler
http://jsil.org/
Other
1.73k stars 240 forks source link

Specify what types should be translated #244

Open iskiselev opened 11 years ago

iskiselev commented 11 years ago

It will be good, if JSILc will have some additional option for assembly - translate only used types and option to translate only some types (instead of assembly now). In that case we can specify starting assmbly/types, than JSILc will translate them and only that types, that was used during translation of starting types. This step may be repeat recursively until we translate all used types. In such case translated assembly could be much smaller then in current implementation. Besides stubs (mscorlib and so on) will also be much smaller, and it will help not only with loading time, but also with browser memory footprint.

wizzard0 commented 11 years ago

There are a lot of static classes and so on which need to be loaded (like System.Configuration) if you just walk the method graph. It's not that simple.

I believe there was a lazy-loading branch somewhere.

And, the ideal implementation would be able to take snapshot which classes were actually initialized AT RUNTIME, and make a hint config from that, then other classes could be split and loaded on-demand (if requested through reflection, for example)

kg commented 11 years ago

Yeah, walking the graph isn't enough. Something to solve this problem is on my todo list but I haven't figured out how to do this yet. It's possible pruning unused methods might do some good but I suspect even that won't do much.

wizzard0 commented 11 years ago

I recently made a primitive MSIL interpreter (no structs, no generics, no exceptions yet, but simple console apps work pretty well - using System.IO code from real mscorlib with PInvoke, tested both with Microsoft and Mono mscorlib) and thought it could be used to mark used classes during runtime. Then, we can split them and preload, and pull other heavy stuff only if reflection is used etc.

BrainSlugs83 commented 11 years ago

... I wonder if maybe the outputs from performance analysis (of type "Instrumentation", for example, as it "Measures function call counts and timing") could be used to gather the "what methods are used at run-time" information?

wizzard0 commented 11 years ago

There are no docs on the .psess file format afaik ;)

kg commented 11 years ago

@wizzard0: That's an interesting approach I've thought about before; the idea of having a baseline interpreter that we use during startup and in a few other scenarios, before dropping to actual JS function bodies.

I think in practice we wouldn't be able to use the actual MSIL though; it'd be too large. What we'd probably want is some sort of middle ground - perhaps the JSIL compiler could output a sort of byte code representing its JS syntax tree, in a streamable, seekable binary format. Then we'd be able to pull individual functions out of the bytecode one-by-one and interpret them or generate the JS on the fly as needed. It'd reduce memory usage and startup time, I think.

BrainSlugs83 commented 11 years ago

So like, a JavaScript based JIT compiler? (Only, it worked on a custom format, not actual MSIL.) I'm very intrigued...

I'm just thinking out loud, and this probably is not compatible with the goals of your project, but, what if there was an ASP.NET add-in that did something similar server side? It could load / compile / cache the assemblies / methods and serve them on demand in JavaScript (or minified javascript) format... then you could still use the native MSIL binaries... though, there would be a bit of perf hit on the first request of anything...

Whatever approach you take, if you're going to "JIT" the binaries, it would be nice to have a .NET Attributes that one could place on methods / classes that let them specify a JIT preference (i.e. "Always include this method in the JSILc output (don't JIT this method)", "Never include this method in the JSILc output (always JIT it)", and the default: "Let JSILc do whatever it feels like").

wizzard0 commented 11 years ago

we wouldn't be able to use the actual MSIL though; it'd be too large.

I actually don't want to even download it; use "training" interpreter run to prepare a bundle of MSIL or JS or whatever from actually used methods to download first; download others only if used (if ever)

kg commented 11 years ago

Oh, I see, like profile guided optimization? That could work pretty well.

wizzard0 commented 11 years ago

Yes