4 ms·

Thanks, I was aware of canaries actually, and I've been using XO (execute-only) which makes code unreadable, which is a better version of what you call W xor X

Thanks, I was aware of canaries actually, and I've been using XO (execute-only) which makes code unreadable, which is a better version of what you call W xor X in my own emulation. Code should simply not be readable, as it never contains any data that I have seen. It might have been the case in the hand-written assembly days when people put data and constants close to the code, but I recently read that GCC considers it a bug if there is data in the code segment. I realize I am taking some minor flack for my questions, but that is how you get people to answer. You have to be a little bit controversial. So, As far as JITs go, I've been thinking about how Rust just took something C++ people took for granted: You can't have certain safeties because it would cost you performance, and prove it completely wrong. But it required moving completely away from C and rethinking things from the ground up. So, who is to say you can't do the same with dynamic languages? I mean, why do we even have JIT to begin with? It's largely for these highly dynamic JS, Python-like languages, which are extremely popular because of it. Is there really a good reason to believe that these types of languages will never be compiled to native code? Even if only at near-native speeds?

johncolanduoni 6y ago
In principle there’s no reason why you can’t profile the code ahead of time with a representative benchmark of the application and perform most of the important optimizations that a JIT performs, and then save that generated code. In fact V8’s snapshot mechanism effectively does that with the Chromium APIs. However you’re losing one of the significant benefits of these languages (that is pretty much crucial in the JS case): the ability for them to be written independently of the particular runtime and architecture of the execution environment. Code generated for JS (just as an example) has to be intimately aware of the runtime’s native bindings and GC implementation to be as efficient as it is in modern browser engines. You would also lose the ability to software sandbox untrusted code. Basically, the JIT platform for which exploits are the most valuable by a large margin wouldn’t be able to use this solution, and the other JIT platforms aren’t often used in ways that make this kind of issue relevant in practice.
pjc50 6y ago
Lots of the popular languages have "eval", which can't be compiled ahead of time. Even if you did compile Javascript ahead, before delivery, what would you compile _to_? It would have been a huge uphill struggle for the smartphone era if all websites had been x86-only. AOT compilation forces you to pick your customer hardware. JIT leaves that choice to the customer. Mind you, there are situations where I'd quite like AOT for Python, or at least advance _linking_, as it would solve a lot of the distribution problems and virtualenv hassles.

johncolanduoni 6y ago

In principle there’s no reason why you can’t profile the code ahead of time with a representative benchmark of the application and perform most of the important optimizations that a JIT performs, and then save that generated code. In fact V8’s snapshot mechanism effectively does that with the Chromium APIs. However you’re losing one of the significant benefits of these languages (that is pretty much crucial in the JS case): the ability for them to be written independently of the particular runtime and architecture of the execution environment. Code generated for JS (just as an example) has to be intimately aware of the runtime’s native bindings and GC implementation to be as efficient as it is in modern browser engines. You would also lose the ability to software sandbox untrusted code. Basically, the JIT platform for which exploits are the most valuable by a large margin wouldn’t be able to use this solution, and the other JIT platforms aren’t often used in ways that make this kind of issue relevant in practice.

pjc50 6y ago

Lots of the popular languages have "eval", which can't be compiled ahead of time. Even if you did compile Javascript ahead, before delivery, what would you compile _to_? It would have been a huge uphill struggle for the smartphone era if all websites had been x86-only. AOT compilation forces you to pick your customer hardware. JIT leaves that choice to the customer. Mind you, there are situations where I'd quite like AOT for Python, or at least advance _linking_, as it would solve a lot of the distribution problems and virtualenv hassles.