4 ms·

> Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for i

> Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions" Hardware moves slowly and can't be fixed easily. Browsers should just be doing this (which they are with site isolation) instead of hardware trying to hack in patches to cover up bad software architecture. And you can't fix a bug you didn't know about anyway, so why would you have expected ARM to fix something nobody knew was real in the first place?

monocasa 8y ago
Running untrusted code in the same process isn't "bad software architecture". And we've been doing that for as long as microprocessors have had OoOE. Java got big right when the first consumer OoOE chips came out in the 90s.
- kllrnohj 8y ago
  > And we've been doing that for as long as microprocessors have had OoOE Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? > Java got big right when the first consumer OoOE chips came out in the 90s. Java doesn't do this, so how is that relevant?
  - monocasa 8y ago
    > Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? BPF has existed since the mid 90s for one example. > Java doesn't do this, so how is that relevant? Java and the client web were next to inseparable concepts at the time. Java ran their VM as a shared library in the browser process for applets.
- stubish 8y ago
  The JVM took responsibility for sandbox isolation. It took until Spectre/Meltdown to widely demonstrate that this was a poor decision, because it turned out in process sandbox isolation is a promise that cannot be kept. And the point of the JVM was to run the same code on all sorts of hardware, so it doesn't get to blame the Intel or Spark or Motorola CPU it happens to be running on.

monocasa 8y ago

Running untrusted code in the same process isn't "bad software architecture". And we've been doing that for as long as microprocessors have had OoOE. Java got big right when the first consumer OoOE chips came out in the 90s.

kllrnohj 8y ago
> And we've been doing that for as long as microprocessors have had OoOE Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? > Java got big right when the first consumer OoOE chips came out in the 90s. Java doesn't do this, so how is that relevant?
- monocasa 8y ago
  > Prior to web browsers when was such a thing ever widespread? And if you eliminate web browsers from the picture, how many usages are even left? BPF has existed since the mid 90s for one example. > Java doesn't do this, so how is that relevant? Java and the client web were next to inseparable concepts at the time. Java ran their VM as a shared library in the browser process for applets.
stubish 8y ago
The JVM took responsibility for sandbox isolation. It took until Spectre/Meltdown to widely demonstrate that this was a poor decision, because it turned out in process sandbox isolation is a promise that cannot be kept. And the point of the JVM was to run the same code on all sorts of hardware, so it doesn't get to blame the Intel or Spark or Motorola CPU it happens to be running on.