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

101–110 of 117 posts

Re: JIT-Less V8

#101

Post by olliej »

mbel wrote: post #66
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.

JIT code for JS is /huge/ at the lower optimization levels, dramatically larger than an interpreter's byte code by something in the order of 10x - many megs of code are generated by relatively small amounts of JS code.

Re: JIT-Less V8

#103

Post by olliej »

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.

If I recall correctly every browser security bug in recent years has used the RWX blocks to get full RCE. If a process is not able to ever get RWX memory your code has to be entirely ROP/JOP based which is a much higher barrier.

Re: JIT-Less V8

#104

Post by chrisseaton »

abstractcontrol wrote: post #85
curtis wrote: post #55

Earlier quoted context omitted.

People were using Ruby and Python (and before that Perl and PHP) on the backend in many cases. I think it's likely that those are the kinds of projects which are using JS on the backend now, while the Java and C# people are continuing to do their backends in Java and C#. One of JavaScript's big advantages over Ruby and Python was performance, both because the standard runtime is faster (JITing JavaScript turned out t…

> JITing JavaScript turned out to be a lot easier than JITing Ruby and Python Why was this the case?

JavaScript is a relatively small and simple language with relatively constrained semantics that allow it to be implemented relatively simply.

Ruby and Python are the opposite of that. Ruby and Python are I'd say literally a thousand times more complicated to compile than JavaScript.

Re: JIT-Less V8

#105

Post by olliej »

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…

Most of the time they're not bugs in the JIT - they're bugs in other parts of the software, basically your path to exploit is:

1. Find bug that gives you arbitrary read

2. and a bug that lets you write to some arbitrary location

3. Find bug the lets you jump to some location

4. Use [1] to find the location of the RWX region

5. use [2] to copy your exploit code into [4]

6. use [3] to jump to [4]

7. Profit

Often times a single use after free gives you 1, 2, and 3. Essentially you use the UaF to get multiple different objects pointing to the same place, but as different types. e.g You get a JS function allocated over the top of a typed array's backing store, then from JS you have an object that the runtime thinks is a typed array, but the pointer to its backing store is actually pointing to part of the RWX heap. Then all you have to do is copy your shell code into the corrupted typed array, and call the function object.

(This requires a GC related use after free, and most of the JS runtimes have gotten progressively more aggressive about validating the heap metadata, but fundamentally if there's a GC bug it's mostly likely just a matter of how much work will be needed to exploit it)

Re: JIT-Less V8

#106

Post by Klathmon »

samcday wrote: post #32

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!

I believe this was also (at least partially) done for performance reasons!

In general, compared to a JIT, an interpreter is faster to start executing code, and can more quickly (and efficiently!) execute code that will only run once.

V8's "Ignition" started as a way to replace the "baseline" JIT in their engine. It can begin executing code while the optimizing compiler gets up to speed and analyzes what needs to be optimized and it can execute code that is extremely likely to only run once (like top level javascript).

The bytecode representation they use for Ignition is also used by their optimizing compiler "TurboFan", which means that they throw away the actual source code after it's been converted to bytecode, saving quite a lot of memory!

All together this means that the Ignition+TurboFan pipeline is faster to start executing, has lower resource usage, and is much simpler than the old stack of a "baseline" JIT (full-codegen) and their old optimizing compiler (crankshaft).

Being able to disable the optimizing JIT entirely is just another bonus of the architecture!

Re: JIT-Less V8

#107

Post by CamperBob2 »

bpye wrote: post #53
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.

I quite like Duktape because it is really simple to embed as well. The V8 API is comparitively pretty complicated.

I'd like to check that out. Unfortunately, like other projects that idiotically adopt a generic name that can't be Googled without returning an endless swamp of irrelevant results, I can't seem to find any info on "duct tape" as it relates to JavaScript interpreters. Any good pointers?

The use case in question: a few years ago I embedded V8 in a Win32 app with a single .DLL and header file, but V8 has exploded in complexity since then and no longer appears suitable for lightweight applications, meaning anything smaller than a full-fledged Web browser. I need to upgrade that interpreter at some point, so I'm definitely in the market for something comparable to what V8 used to be.

Kind of unfortunate, but I'm hardly the user the V8 team has in mind.

Re: JIT-Less V8

#108

Post by jjnoakes »

CamperBob2 wrote: post #107
bpye wrote: post #53

Earlier quoted context omitted.

I quite like Duktape because it is really simple to embed as well. The V8 API is comparitively pretty complicated.

I'd like to check that out. Unfortunately, like other projects that idiotically adopt a generic name that can't be Googled without returning an endless swamp of irrelevant results, I can't seem to find any info on "duct tape" as it relates to JavaScript interpreters. Any good pointers? The use case in question: a few years ago I embedded V8 in a Win32 app with a single .DLL and header file, but V8 has exploded in com…

Google duktape, not duct tape.

Re: JIT-Less V8

#109

Post by bpye »

CamperBob2 wrote: post #107
bpye wrote: post #53

Earlier quoted context omitted.

I quite like Duktape because it is really simple to embed as well. The V8 API is comparitively pretty complicated.

I'd like to check that out. Unfortunately, like other projects that idiotically adopt a generic name that can't be Googled without returning an endless swamp of irrelevant results, I can't seem to find any info on "duct tape" as it relates to JavaScript interpreters. Any good pointers? The use case in question: a few years ago I embedded V8 in a Win32 app with a single .DLL and header file, but V8 has exploded in com…

For anyone that is interested, duktape ( https://www.duktape.org/ ).

The API docs are at https://www.duktape.org/api.html , it's a C API and it's pretty easy to work with and bind native code. I kinda wish that more JIT compiled languages had an API as nice as LuaJIT.

Re: JIT-Less V8

#110

Post by CamperBob2 »

bpye wrote: post #109
CamperBob2 wrote: post #107

Earlier quoted context omitted.

I'd like to check that out. Unfortunately, like other projects that idiotically adopt a generic name that can't be Googled without returning an endless swamp of irrelevant results, I can't seem to find any info on "duct tape" as it relates to JavaScript interpreters. Any good pointers? The use case in question: a few years ago I embedded V8 in a Win32 app with a single .DLL and header file, but V8 has exploded in com…

For anyone that is interested, duktape ( https://www.duktape.org/ ). The API docs are at https://www.duktape.org/api.html , it's a C API and it's pretty easy to work with and bind native code. I kinda wish that more JIT compiled languages had an API as nice as LuaJIT.

Thanks, that was the trick I was missing. Will have a look.
Post reply on HN