Record/replay would be incredibly useful for game developers trying to do automated testing or go back and analyze a rare failure case that happens occasionally. I already do a bunch of this on my end by recording API calls and results and such, having it at a lower JS level would be incredibly useful.
Being able to detect operations that produced NaN is also handy for that sort of debugging or even as a way to just assert that it never happens in debug builds of your game. The other features listed sound useful as well but I don't know if they'd ever get used by game developers. I'm not sure I'd use them for JSIL either. Maybe you could use mutation/method call tracing to do a profile-guided-optimization equivalent for JS where you record argument types and clone functions per-callsite to ensure everything is monomorphic? I could see that being a big performance boon, especially if you can do it statically and automatically by using instrumentation. On Wed, Jun 25, 2014 at 3:40 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Thu, Jun 26, 2014 at 8:06 AM, Jason Orendorff <jorendo...@mozilla.com> > wrote: > >> An alternative involves letting you modify JS code just before it's >> compiled (source-to-source transformation). This is more general (you could >> modify the instrumented code arbitrarily, and react synchronously as it >> executes) but maybe that's undesirable. It's not clear that transformed >> source would interact nicely with other tools, like the debugger. And a >> usable API for this is a tall order. >> > > Why is a usable S2S API difficult to produce? > > A while ago I spent a few years doing dynamic analysis of Java code. > Although the VMs had a lot of tracing and logging hooks, bytecode > instrumentation was always more flexible and, done carefully, almost always > more performant. I had to write some libraries to make it easy but tool > builders enjoy writing and reusing those :-). > > For JS of course we wouldn't want to expose our internal bytecode, hence > S2S. > > Rob > -- > Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni > le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa > stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, > 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp > waanndt wyeonut thoo mken.o w > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
