V8 is going to switch to a new compiler architecture after 5.8 branch cut | Hacker News Reader

V8 is going to switch to a new compiler architecture after 5.8 branch cut

groups.google.com

128 pointsilkkao35 comments

I am curious about the possibility of this leading to source code protection in Electron.

The Electron team declined to support source code protection, judging it too difficult to implement. [0] NW.js supports the feature but with severe limitations that the Electron team understandably did not want to replicate. [1]

Roger Wang of NW.js fame recently tweeted that the NW.js implementation is about to get a whole lot better due to this new compiler landing in V8. [2]

Could this new development in V8 put source code protection back on the table for Electron? I posted this question to the official Electron discussion forums too a few days back, but I'd be curious to hear more input on the topic, thus posting it here as well. [3]

[0]: https://github.com/electron/electron/issues/3041

[1]: https://github.com/nwjs/nw.js/wiki/protect-javascript-source...

[2]: https://twitter.com/wwr/status/831691865850130432

[3]: https://discuss.atom.io/t/source-code-protection-via-new-v8-...

You'll always be able to decompile electron (and other JS) apps. As the problem becomes more common, better tools will be available and any "protection" will be moot.

Source code protection amounts to bad DRM, and I should hope it doesn't need to explained on HN the ways DRM doesn't work.

My understanding is that the proposals being bandied about to do source code protection involve compiling the JS code into binary, so it's analogous to the protection offered by writing native code rather than mere minification/obfuscation or JIT bytecode stuff.

Obviously no compilation process offers 100% protection, but it would be enough for most people's purposes if it occupied a space that was more secure (or more obfuscated) than Java, but less so than, say, C++.

Disclaimer: I started that github issue for source code protection with Electron.

To add to this since other people will come commenting, yes I know that if somebody REALLY wants to they can get to the code (although I'd argue that Denuvo worked for a while).

However there is a huge difference between having hard to read code that needs to be decompiled and unobfuscated to code that is in plain text! Any script kiddy can modify any electron application (The code is in freaking text files!).

> Any script kiddy can modify any electron application (The code is in freaking text files!).

And what's so bad about that?

The copyright law of the EU even was written with the intention that someday everyone would have the source code to everything, and everyone — even your grandparents — could modify any application, because the source would be in freaking text files!

Every project has different requirements. It's not for you to say whether something is good or not for others.

I don't mean to sound like a prick, but while I personally love open source, I tire of the evangelism of its virtues.

So, you’re advocating that you should be able to sell products that are impossible to repair, impossible to modify, with 0 days warranty period, and then expect people to accept that?

I’m sorry, but there’s a reason we don’t allow that for physical things either.

> Every project has different requirements.

That might be. But that doesn’t change the problem I mentioned above.

Yes, you should be able to create any kind of product you want as long as it's within the law. You're not the authority on what constitutes a problem. It's certainly debatable and far from settled, contrary to the definitive character of your indignation. And it's far more nuanced than your ungenerous characterization of it - this is part product, part intellectual property.

What's great is you are free to exercise your philosophy in your products, and if you're right, then that will make your products superior.

I don't feel the need to utterly destroy my ideological "enemies" to the point that I need closed source software to die, just because I believe in open source. Nor can I claim to have an indisputable moral high ground that just goes without saying.

In isolation I agree with you, but software does not exist in isolation. It exists in market places, on pacemakers, in airplanes, on voting machines and everywhere else.

Right now the default way to release "of the shelf" products is without source code. It is not a real business decision for many, so they default to what everyone else does. For no real reason, then they defend this with lobbyist and lawyers. This includes airplanes, pacemakers, etc...

I really do think closed source software should be illegal, because I think that is the only way that I will be able to verify there are no issues something I use, like a medical device. I cannot verify my grandmother's pacemaker and if there is a bug she dies. Currently, the source code doesn't need to be shared with her or me, just because its a trade secret. Why should a trade secret be more important than the lives of users of a product.

But its not just the one life threatening extreme. Look at the Vizio TV news for the past few weeks. These entertainment should be about as innocuous as possible. Vizio has enough data to know the political leanings of 90% of Vizio TV owners. How would you feel if they sold that to people in a political party that opposes you? This is software on entertainment devices, and it has this kind of power. To make it worse, they got away with it for 18 months before anyone figured it out. They might have gotten away with entirely if they used a bit of encryption.

Forget the virtues of open source, I firmly believe closed source software is not compatible with the basic freedoms required the long term for any democracy.

You've picked some pretty dangerous subjects in healthcare and privacy. It's no coincidence that these areas are focal points for regulatory legislation - this is serious stuff, but that's why we have laws and other mechanisms in place to deal with these things. The regulatory environment is precisely what addresses the fact that software does not exist in isolation.

It's ludicrous though to suggest that all closed source software become illegal. Talk about throwing out the baby with the bathwater! You'll be hard pressed to find any regulatory justification for such a blanket measure.

This is overreaching, entitled ideological authoritarianism. The danger is that you don't see it because it all sounds so ethical on the surface, especially when framed through the dramatic lens of your grandmother's pacemaker. Maybe I do think there needs to be more transparency in healthcare products, and I think that what Vizio did is despicable - but we can't just knee-jerk all the way to the other extreme of outright banning all closed source.

What you're essentially advocating for is the application of absolute power on everyone in order to prevent some from abusing their power. Do you not see the dangerous escalation of the stakes once you take this approach? I'm almost more afraid of you than I am of Vizio.

I wrote some code yesterday and didn't share it - are you going to justify forcibly prying it from me?

> I wrote some code yesterday and didn't share it - are you going to justify forcibly prying it from me?

No, but some realistic proposals include forcing developers to release their source as soon as they stop providing fixes for bugs to all people who bought a license.

Another proposal that’s currently demoed is the government paying a wage to all open source devs: https://prototypefund.de/2017/02/22/german-prototype-fund-gr...

> outright banning all closed source.

I’m not sure where you see the problem? With patents we already require you to publish the entire process to get protection – as algorithms are not protected by copyright, and most not by patents, a possible solution for software protection that’s discussed is providing copyright protection for software under the restriction that the source is published after a few years (and until then held by a trustee)

The scenarios you're presenting obfuscate the simplicity of my point: you shouldn't blanket ban something because it's at odds with your philosophy. Exceptions will certainly exist, but that's beside the point and I don't see the value in descending into the minutiae of the exceptions and consequently not being able to see the forest for the trees.

Your view of your ideological opponents is very ungenerous. You accord it absolutely no merit, as it seems you deem it completely wrong and advocate for its banning outright.

Instead I would urge you to understand why some people and organizations have un-nefarious reasons for making closed-source software. To put the burden of justification on them so that they can be allowed to do their own thing is, well, pretty unfair. You seem to operate with the assumption that your ideological opponents are objectively guilty.

And I write this as an advocate for open source (a 100% personal and debatable belief, not an absolute moral claim): you are not being fair when you act like anyone making closed-source software has some obligation to prove to society that they're not being nefarious.

You're seriously willing to punish everyone either legislatively or through a stigma because Vizio did something unethical? The presumption of innocence is fundamental in our society, and your arguments just casually trample all over it, as if it's settled and you're right by default.

> Yes, you should be able to create any kind of product you want as long as it's within the law.

Exactly. And what if the law says "anyone has the right to repair or modify any software product they have a license to"?

And what if the law says that makers may "not try to discourage users with technical or legal means from using their rights"?

That’s the point where we’re at, and intentionally making it hard for users to modify the software just for that purpose is something you only do to prevent users from using their rights.

> You're not the authority on what constitutes a problem

No, but the people who wrote above laws are.

> this is part product, part intellectual property.

Which, luckily, EU law has settled even more definitely than anything else: If you can buy a license for something, then you own that product for which you bought the license in the same way as if you had bought a physical product. And you can create private copies for yourself, you can modify it like you can repaint your IKEA table, you can return it within of 14 days and get all the money back, and you can resell it to others.

Morality is arbitrary, neither point of view is more valid than the other one.

Take your text, and replace FOSS with berries and closed source with banana, and you'll feel even more right. Do it with freedom and slavery, you'll feel so wrong.

Wow, I think you just articulated something that I've definitely felt, but have a hard time explaining – I feel like I am some kind of traitor to open source software for feeling this way.

I don't understand why this change would have anything at all to do with source code obfuscation. Can you explain why this is related? Are you hoping the new architecture exposes some kind of intermediate representation to the front end which would be stable enough for something like Electron to serialize?

See the tweet from Roger Wang. He implied that Ignition and Turbofan will dramatically improve the source code protection feature already present in NW.js by removing the need for many of the painful compromises that make it work today. My main question is whether or not it is likely the Electron team will agree with this assessment and consider supporting the feature as well.

Source code protection is a horrible idea and antithesis to what has made JavaScript work so far. Source-code-only is the future of software distribution. One of my long-term goals involves building a new dynamic language runtime - the plan is no ABI and AGPL licensing to only allow Free Software to use the runtime.

Finally! Congratulations to the V8 team for completing the switch to a sane compilation pipeline. :)

Hopefully this will lead to many more simplifications in the future.

Does anyone know which optimizations finally catapulted Ignition+Turbofan ahead of FullCodeGen+Crankshaft in terms of performance?

I'm not sure if you are referring to a particular optimization, but speaking of

https://twitter.com/bmeurer/status/834677090381348865

and

https://twitter.com/bmeurer/status/834668611180625921

the "Bazinga!" event in both cases refers to two very specific fixes that addressed deoptimization loops in TurboFan. The more interesting steady increase in performance is due to long-term real-world performance work, especially in the area of data-driven ICs (inline caches) and function context specialization.

We will follow up with more details about Ignition and TurboFan, and the whole new code generation architecture soon.

Yes, that's what I had in mind. Another thing I seem to recall is that Turbofan used to be a lot slower than Crankshaft and spend a lot of its time in scheduling and register allocation. Has this changed recently?

In any case, I'm looking forward to the more in depth post. :)

And just to provide some context on the "sane" part.

[0] is their current architecture. [1] will be the architecture after this change goes into effect.

It's a massive simplification which should allow them to implement new changes to the language much faster, improve memory usage and startup speed, and will allow them to tackle web assembly much easier!

[0] http://i.imgur.com/M86wHy2.png

[1] http://i.imgur.com/Bmuxtdq.png

And this is how you can try it out now in Chrome Canary: https://v8project.blogspot.com/2017/02/help-us-test-future-o...

Can anyone speak to what sort of impact this might have on NodeJS? Will it be difficult for the project to migrate to that version? Is it expected to break packages that rely on C bindings?

This architecture switch will have no impact on the V8 API. We're working closely with the Node.js team to make sure that this is a smooth transition and early results look as though there are significant performance benefits [0].

Disclaimer: I work on the V8 team.

[0]: https://twitter.com/bmeurer/status/834677090381348865

Probably means I will finally give Atom editor another try. :)

Atom's performance will most likely be more constrained by the algorithms they use than by JS execution speed.

Since vscode is already pretty fast, you are probably right.

Based on what the article says, performance would be improved. Since theres no API changes, it would be safe for NodeJS team to try to upgrade to this new version without regression issues.

So far the feedback from Node.js users/developers indicates that the --future configuration is a net win. There are some cases where performance degrades, and we are actively working on those. Instructions how to test-drive --future with Node.js can be found here: https://medium.com/@bmeurer/help-us-test-the-future-of-node-...

Performance, performance, all the talk about performance. What about memory footprint?

Apparently Ignition helps a bit, but still… even the baseline memory usage of Node.js and Chromium is bad. Just open a node REPL, its resident set size is 2x the size of a ruby/python REPL, about 10x the size of luajit.

I wonder how this will effect performance for games/realtime stuff as that seems like the weak point for JS from the user side, although realistically it's probably more of a GC problem. Seems like most of the test websites are reasonably static - do a bunch of stuff once at startup/do a bunch of stuff on user input so your compilation overhead ends up being fairly large whereas with realtime stuff/games I'd expect it looks more like the octane benchmark....

I'm a sucker for interpreter designs, and the new Ignition bytecode interpreter looks nice:

https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIP...

Will performance improve across the board, or is the new architecture targeting common patterns believed to be slow, like heavy use of closures & promises, or getting functional calls like map into the same performance range as a for loop?

> Will performance improve across the board

Speaking very generally, I've never seen a major architecture change that led to a performance improvement across the board. In particular in JS which has so many corners. There are always going to be some things that improve, some that regress, and some that stay the same. You can see examples of all three here (compare lines with TurboFan+Ignition vs v8):

http://arewefastyet.com/#machine=29&view=breakdown&suite=oct...

Reply on news.ycombinator.com