Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JIT-Less V8

v8.dev

Post reply on HN
Print view View original

31–40 of 117 posts

Re: JIT-Less V8

#31

Post by schuay »

mcphage wrote: post #16
irrational wrote: post #8

Apple requires browsers on iOS to use the same rendering engine as Safari, but would it allow a browser to use a different JavaScript engine? Or is this a loophole that Apple didn't forsee that they will be closing in the future? Are the rendering engine and JavaScript engine so separated that you could use the Safari rendering engine, but a different JS engine?

If it were allowed, you could use V8 for other, non-browser apps.

I think that should be possible. The main restriction seems to be

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

Using V8 to execute JS without 'browsing the web' sounds okay.

And perhaps also this, although it is not clear to me whether downloaded JS scripts are considered 'code':

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. [...]

https://developer.apple.com/app-store/review/guidelines/

Anything else? I'm curious to learn more..

Re: JIT-Less V8

#32

Post by samcday »

For a team that has been pushing the cutting edge of Javascript VM performance for many years, it must feel pretty weird to ship a feature that allows one to willingly regress performance so much!

Re: JIT-Less V8

#33

Post by bjourne »

saagarjha wrote: post #24
bjourne wrote: post #20

I'm skeptical of the claim of improved security. Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit.

> Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. This is very possible: just do a search for ${your favorite JIT} arbitrary code execution, and you'll almost certainly see a real-world vulnerability. > At least HotSpot has been JIT:ing code for decades and no one has been…

But the feature the exploit takes advantage of isn't just in time compilation, it is compilation! An ahead of time java compiler would have suffered from the exact same problem. In fact, any language compiling to machine code would be just as vulnerable.

Re: JIT-Less V8

#34

Post by xuejie »

cromwellian wrote: post #17

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev…

Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines.

Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.

Re: JIT-Less V8

#35

Post by CGamesPlay »

michaelcampbell wrote: post #4
ape4 wrote: post #2

"V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++." from its home page. I didn't immediately know

And?

A common (and, in my opinion, legitimate) complaint about blog posts that appear here often is that the company publishing the post doesn't say what it is they are or are doing, and as a result, why anyone should care about the about the blog post.

Re: JIT-Less V8

#36

Post by ricardobeat »

xuejie wrote: post #34
cromwellian wrote: post #17

For very security sensitive embedded applications, this could be a huge boon, since it reduces attack area surface, both from the point of view of executable pages, to the simplicity of the interpreter vs full JIT. Granted, there are many JS interpreters already available, like Ducktape, that fulfill the same benefits, but the immediate upside of this is compatibility with the full Node/ES6+ ecosystem and Chrome Dev…

Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines. Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.

“Very slow compared to” is still as fast, or faster than, many other dynamic language runtimes. In my case I saw a 2x-10x difference between V8 and Duktape, which is acceptable given the trade-offs.

Re: JIT-Less V8

#37

Post by aasasd »

bjourne wrote: post #20

I'm skeptical of the claim of improved security. Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. At least HotSpot has been JIT:ing code for decades and no one has been able to find such an exploit.

Aside from the other replies, I'm baffled as to how you decided that Hotspot being safe would mean V8 is safe.

Re: JIT-Less V8

#38

Post by xuejie »

ricardobeat wrote: post #36
xuejie wrote: post #34

Earlier quoted context omitted.

Definitely agree duktape is a decent attempt at low memory situation, but one additional point is that duktape is very slow compared to modern JavaScript engines. Hence I wonder if we can split ignition off v8 to create a standalone fast JavaScript interpreter at the cost of (possibly) more memory consumptions than duktape, that could prove to be useful in many scenarios.

“Very slow compared to” is still as fast, or faster than, many other dynamic language runtimes. In my case I saw a 2x-10x difference between V8 and Duktape, which is acceptable given the trade-offs.

Agreed, and I'm not saying duktape doesn't have a use case, I'm merely saying having a standalone ignition interpreter might enable different use cases.

Re: JIT-Less V8

#39

Post by pitaj »

bjourne wrote: post #33
saagarjha wrote: post #24

Earlier quoted context omitted.

> Theoretically, if there were some horrible bugs in the JIT, one could craft malicious input data causing the JIT to insert arbitrary code in the code heap. In practice, it doesn't seem possible. This is very possible: just do a search for ${your favorite JIT} arbitrary code execution, and you'll almost certainly see a real-world vulnerability. > At least HotSpot has been JIT:ing code for decades and no one has been…

But the feature the exploit takes advantage of isn't just in time compilation, it is compilation! An ahead of time java compiler would have suffered from the exact same problem. In fact, any language compiling to machine code would be just as vulnerable.

Yes, but when pre-compiling, you implicitly trust the code. JITs like V8 are used to execute arbitrary code on your device, where such an exploit is much more harmful.

Re: JIT-Less V8

#40

Post by mark-r »

Just another indication of Google trying to take over the world. There's a class of machines where Chrome can't run? We need to fix that, stat!
Post reply on HN