Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by xamuel on Friday August 30, 2019 @02:53PM
(#20841466)
One way to see it's more subtle than meets the eye: suppose the website defines a function F which is annotated as taking a string argument. The website itself only ever calls F with strings. But suppose I go to the website, open the console, and punch in F(1). Of course, this sort of thing could be guarded against, but the point is just that it would introduce more complexity than initially meets the eye.
[ Parent
| on HN ]
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by dymk on Friday August 30, 2019 @03:02PM
(#20841553)
Engines already have to do this - check the type of an argument before calling the compiled version of the function. What the OP is suggesting is simply prefilling the type and instruction caches with information that the build system was already able to gleen.
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by _bxg1 on Friday August 30, 2019 @03:05PM
(#20841575)
And that would probably amount to a "bailout". I'm only talking about providing hints that can be used to skip parts of the described process, not getting rid of it altogether.
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by leeoniya on Friday August 30, 2019 @03:27PM
(#20841770)
i always wondered why it wasn't possible to use a js app in "record" mode and then export any witnessed type & profiling information from the JIT and deliver it alongside the source (like a sourcemap).
Re:The Baseline Interpreter: A Faster JavaScript Interpreter...
by antiuniverse on Friday August 30, 2019 @04:24PM
(#20842323)
That might be considered an example of profile-guided optimization: https://en.wikipedia.org/wiki/Profile-guided_optimization