Live data from Hacker News

V8 has optimized new JavaScript language features (2018)

github.com

51–53 of 53 posts

Re: V8 has optimized new JavaScript language features (2018)

#51

Earlier quoted context omitted.

> You'd get extremely slow code with this approach! You must be interpreting that differently than I meant it. The approach I'm suggesting is "pretend debuggers don't exist when optimizing". It gives you the fast code. A debugger can break any assumption you make. Even unoptimized code could crash if a debugger messes with it. The fear of a debugger should never make you decide not to do an optimization. How would yo…

I think it's just a case of me using more generalised terminology. 'pretend X doesn't exist' is in my mind 'speculate that X isn't enabled'. It really means the same thing doesn't it? You don't need a guard between every instruction, as attaching the debugger is an async option - it's already non-deterministic when the application will receive the instruction to move to debug mode, so as long as it checks frequently…

> 'pretend X doesn't exist' is in my mind 'speculate that X isn't enabled'. It really means the same thing doesn't it?

Not when you're talking about needing "dynamic analysis", which is what made me not understand the way you were using that word.

> It does make compilation more complicated because you need to be able to restore the full debug state of the application, which means storing some results you may not choose to do otherwise, and storing extra meta-data.

You don't need to, in the general case.

> Debuggers can be a formally or informally specified part of the language, and their behaviour may have to follow rules about which intermediate results are visible which may constrain your compilation.

> My argument is: if you do treat debugging as speculation then your model is simpler and easier to work with and you don't need two kinds of deoptimisation. Real languages are implemented this way.

I suppose, but that's only one option. You could make the deoptimization for debugging much weaker or nonexistent, and that would be a valid option too, without having to give up simplicity.

And separately, wanting to change the value of a const while debugging is a valid use case too. But once you support that, there's no reason a never-written let needs to be optimized differently from a const.

Re: V8 has optimized new JavaScript language features (2018)

#52
post #12
post #6

Earlier quoted context omitted.

JavaScript is very dynamic. Here I define a variable with `let` and then change it: let foo = 10; eval("fo"+"o = 10"); I could "obfuscate" that eval assignment as much as I like. So you can't completely statically analyse `let` variables. That said, it's likely you'd end up with perf very close to `const` in a very "hot" part of your code, since a good JIT compiler like V8 will eventually make "assumptions" about you…

An interesting point, however direct "eval" is a special case. It's already known that functions containing direct "eval" are not subject to the same level of performance optimisations as other functions. There is no way to obscure the call to direct "eval" itself; the compiler knows clearly whether it occurs. Without "eval" appearing syntactically inside a function's scope, there is no dynamic access to "let" variab…

> There is no way to obscure the call to direct "eval" itself; the compiler knows clearly whether it occurs.

I must be misunderstanding you, because you've stated that very confidently.

window["e"+"val"](...)

Re: V8 has optimized new JavaScript language features (2018)

#53
post #30

"entirely new approach to how bound function exotic objects are implemented" Does anyone have information on using the term "exotic"? I haven't heard that before and not sure how to understand what they meant by that.

It's a specific term used in the ECMAScript specification [1]. That refers to any object for which at least one internal method does not behave like for a standard object created for example with `{}`. [1] http://www.ecma-international.org/ecma-262/

Thank you!!
Post reply on HN