
V8 is going to switch to a new compiler architecture after 5.8 branch cut - ilkkao
https://groups.google.com/forum/#!topic/v8-dev/YXpjhVeHlbI
======
kethinov
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](https://github.com/electron/electron/issues/3041)

[1]: [https://github.com/nwjs/nw.js/wiki/protect-javascript-
source...](https://github.com/nwjs/nw.js/wiki/protect-javascript-source-code-
with-v8-snapshot)

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

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

~~~
bastawhiz
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.

~~~
kethinov
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++.

~~~
penagwin
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!).

~~~
kuschku
> 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!

~~~
theprotocol
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.

~~~
kuschku
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.

~~~
theprotocol
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.

~~~
sqeaky
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.

~~~
theprotocol
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?

~~~
kuschku
> 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...](https://prototypefund.de/2017/02/22/german-prototype-fund-grants-
up-to-30-000-for-open-source-projects/)

> 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)

~~~
theprotocol
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.

------
fmap
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?

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

[https://twitter.com/bmeurer/status/834677090381348865](https://twitter.com/bmeurer/status/834677090381348865)

and

[https://twitter.com/bmeurer/status/834668611180625921](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.

~~~
fmap
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. :)

------
petercooper
And this is how you can try it out now in Chrome Canary:
[https://v8project.blogspot.com/2017/02/help-us-test-
future-o...](https://v8project.blogspot.com/2017/02/help-us-test-future-
of-v8.html)

------
MikeKusold
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?

~~~
s3th
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](https://twitter.com/bmeurer/status/834677090381348865)

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

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

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

------
floatboth
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.

------
nimos
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....

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

[https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIP...](https://docs.google.com/document/d/11T2CRex9hXxoJwbYqVQ32yIPMh0uouUZLdyrtmMoL44/)

------
dahart
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?

~~~
azakai
> 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...](http://arewefastyet.com/#machine=29&view=breakdown&suite=octane)

