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

61–70 of 117 posts

Re: JIT-Less V8

#61

Post by s_y_n_t_a_x »

whatshisface wrote: post #60
efdee wrote: post #56

Earlier quoted context omitted.

It sounds like you read a lot of articles about why JS is bad, but don't have a lot of experience with it. * 10-day design? Nobody is using Javascript 1.0 anymore. * Typing is available to various extents thanks to Flow and/or Typescript. * Slowness... I don't know what you're referring to. Javascript isn't slow. * null vs undefined. What about them? They are two different things with different meanings. * Dependency…

> NPM insecurity NPM packages can contain malicious code. There's no NPM review process, and you can't point to specific versions to lock in your own reviews (package administrators can change whatever files they'd like). There's no such thing as a verified-safe dependencies list because the file you reviewed last month might not be downloaded today.

>and you can't point to specific versions

Yes you can.

>no such thing as a verified-safe dependencies list

There are audits.

Re: JIT-Less V8

#62

Post by gok »

JIT-less should really be the default on the web. The security implications of RWX memory are just so bad, and the amount of time that an exotic JIT meaningfully improves behavior of real world web browsing (as opposed to JavaScript benchmarks) is limited. For the rare web app where a JIT is critical, a simple "Do you really trust this web page to perform a lot of computation?" dialog would mitigate a lot of zero-click/one-click attacks.

Re: JIT-Less V8

#63

Post by childintime »

I'd like to try this on the desktop. The difference in memory usage is probably an order of magnitude. That could make my 2GB laptop usable again. I doubt I'll see the difference on any site I care about (no facebook for example). I remember when Java could make the browser totally unusable for several minutes. An interpreter would have avoided that.

Re: JIT-Less V8

#64

Post by mises »

efdee wrote: post #56
mises wrote: post #52

I keep wondering what the deal is with JS on the backend? Why does everyone love it so much? Let's not forget the 10-day design, dynamic typing (and weakly typed, compared with python), slowness, null vs. undefined, etc. JS is a scripting language; they're supposed to be for controlling the behavior of applications (i.e. browsers), not writing applications in and of themselves. Not to mention the dependency hell, NPM…

It sounds like you read a lot of articles about why JS is bad, but don't have a lot of experience with it. * 10-day design? Nobody is using Javascript 1.0 anymore. * Typing is available to various extents thanks to Flow and/or Typescript. * Slowness... I don't know what you're referring to. Javascript isn't slow. * null vs undefined. What about them? They are two different things with different meanings. * Dependency…

NPM insecurity: lots of malicious packages discovered. Also, left-pad.

Slowness: Yes, it is. Look at all the benchmarks comparing it to, say, go.

Re: JIT-Less V8

#65

Post by coder543 »

childintime wrote: post #63

I'd like to try this on the desktop. The difference in memory usage is probably an order of magnitude. That could make my 2GB laptop usable again. I doubt I'll see the difference on any site I care about (no facebook for example). I remember when Java could make the browser totally unusable for several minutes. An interpreter would have avoided that.

the difference in memory usage is 1.7%, according to the article.

Re: JIT-Less V8

#66

Post by mbel »

childintime wrote: post #63

I'd like to try this on the desktop. The difference in memory usage is probably an order of magnitude. That could make my 2GB laptop usable again. I doubt I'll see the difference on any site I care about (no facebook for example). I remember when Java could make the browser totally unusable for several minutes. An interpreter would have avoided that.

From the article:

> Memory consumption only changed slightly, with a median of 1.7% decrease of V8’s heap size for loading a representative set of websites.

What makes you believe is should be anything significant? After all the JIT-compiled code cannot be that large.

Re: JIT-Less V8

#67

Post by bodyfour »

schuay wrote: post #51
bastawhiz wrote: post #49

I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript. I assume this also doesn't support WASM when the JIT is disabled (or rather, when you can't write to executable memory), b…

> I'm curious if the runtime flag to enable JITless mode could also be enabled at compile time, removing the JIT compiler from the binary entirely. That could be really useful for projects where memory comes at a premium (and performance is not a major concern), like micropython but for JavaScript. Theoretically yes, but this is not implemented. It should not be too hard to drastically reduce binary size with a build…

> It should not be too hard to drastically reduce binary size with a build-time flag.

And then how portable would the code be? Would this be a path to running node on CPUs without JIT support? Or does it still have to mess with the calling convention at an assembly level?

Re: JIT-Less V8

#68

Post by jayshua »

gok wrote: post #62

JIT-less should really be the default on the web. The security implications of RWX memory are just so bad, and the amount of time that an exotic JIT meaningfully improves behavior of real world web browsing (as opposed to JavaScript benchmarks) is limited. For the rare web app where a JIT is critical, a simple "Do you really trust this web page to perform a lot of computation?" dialog would mitigate a lot of zero-cli…

Anyone know how common attacks that take advantage of the JIT technology actually are?

Re: JIT-Less V8

#69

Post by firethief »

childintime wrote: post #63

I'd like to try this on the desktop. The difference in memory usage is probably an order of magnitude. That could make my 2GB laptop usable again. I doubt I'll see the difference on any site I care about (no facebook for example). I remember when Java could make the browser totally unusable for several minutes. An interpreter would have avoided that.

It still runs the bloated JavaScript programs, just slower

Re: JIT-Less V8

#70

Post by hashseed »

gok wrote: post #62

JIT-less should really be the default on the web. The security implications of RWX memory are just so bad, and the amount of time that an exotic JIT meaningfully improves behavior of real world web browsing (as opposed to JavaScript benchmarks) is limited. For the rare web app where a JIT is critical, a simple "Do you really trust this web page to perform a lot of computation?" dialog would mitigate a lot of zero-cli…

V8 already employs W^X, i.e. memory pages allocated for V8's heap are either writable or executable, but not both at the same time.
Post reply on HN