{"action":"created","issue":{"url":"https://api.github.com/repos/raptorjit/raptorjit/issues/137","repository_url":"https://api.github.com/repos/raptorjit/raptorjit","labels_url":"https://api.github.com/repos/raptorjit/raptorjit/issues/137/labels{/name}","comments_url":"https://api.github.com/repos/raptorjit/raptorjit/issues/137/comments","events_url":"https://api.github.com/repos/raptorjit/raptorjit/issues/137/events","html_url":"https://github.com/raptorjit/raptorjit/issues/137","id":278412568,"number":137,"title":"Goal: Ports to more architectures","user":{"login":"lukego","id":13791,"avatar_url":"https://avatars0.githubusercontent.com/u/13791?v=4","gravatar_id":"","url":"https://api.github.com/users/lukego","html_url":"https://github.com/lukego","followers_url":"https://api.github.com/users/lukego/followers","following_url":"https://api.github.com/users/lukego/following{/other_user}","gists_url":"https://api.github.com/users/lukego/gists{/gist_id}","starred_url":"https://api.github.com/users/lukego/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lukego/subscriptions","organizations_url":"https://api.github.com/users/lukego/orgs","repos_url":"https://api.github.com/users/lukego/repos","events_url":"https://api.github.com/users/lukego/events{/privacy}","received_events_url":"https://api.github.com/users/lukego/received_events","type":"User","site_admin":false},"labels":[{"id":564743096,"url":"https://api.github.com/repos/raptorjit/raptorjit/labels/goal","name":"goal","color":"5319e7","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2017-12-01T09:53:58Z","updated_at":"2018-02-08T11:59:48Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"RaptorJIT currently supports only x86-64. This is the dominant platform in server networking. However, the world moves forwards and in the future we will want to support more architectures like ARM64. Here are my thoughts on how to go about that.\r\n\r\nFirst, the reason that I removed the other platforms is maintainability. If the VM is hand-written in assembler for a half-dozen architecture then it is very difficult to modify. Likewise when it is #ifdef'd to work with either a 32-bit or a 64-bit address space. This is especially true when there is no CI infrastructure providing testing and benchmark coverage for the platforms. The initial broad platform support inherited from LuaJIT makes changing the VM very expensive, and this expense is not justified in the present server world with ~99% market share held by x86-64 CPUs.\r\n\r\nThe next step that I want to take is to rewrite the x86-64 bytecode interpreter from assembler into C. This will make it more feasible to implement potential killer features like a 96-bit word size (#93). I have done some preliminary hacking in this direction and it is enough to convince me that a rewrite in C is the way forward and that the tricky issues like unwinding a mixture of Lua/C stack frames are actually straightforward in C when following the PUC Lua approach. (Thanks @igelhaus for all the help on working this part out over at #110!)\r\n\r\nOnce the VM is written in C then the incremental cost of new platform support will be much less. The JIT backend will be needed but we won't need thousands of lines of hand-coded VM. This means that new ports will not be a drag on evolving the VM. I do propose that we stay somewhat conservative nevertheless, for example restricting ourselves to 64-bit architectures only.\r\n\r\nThere will be some overhead to running a C bytecode interpreter rather than an assembler one. I believe this will be massively outweighed by the benefits. One reason is that optimized programs don't spend any significant amount of time running the interpreter at all (\"don't optimize the idle loop.\") One more is that there are massive potential performance gains to be had from VM evolution, e.g. by supporting unboxed pointers and 64-bit integers so that `CNEWI` instructions don't heap-allocate and don't critically have to be sunk. (This last point is one of the worst problems in optimizing code today, I am *so* read to move on from giving a fig about whether my CNEWIs have always sunk or not... but I digress.)\r\n\r\nTLDR; RaptorJIT can support all important 64-bit server platforms in the future."},"comment":{"url":"https://api.github.com/repos/raptorjit/raptorjit/issues/comments/364090885","html_url":"https://github.com/raptorjit/raptorjit/issues/137#issuecomment-364090885","issue_url":"https://api.github.com/repos/raptorjit/raptorjit/issues/137","id":364090885,"user":{"login":"pygy","id":54515,"avatar_url":"https://avatars1.githubusercontent.com/u/54515?v=4","gravatar_id":"","url":"https://api.github.com/users/pygy","html_url":"https://github.com/pygy","followers_url":"https://api.github.com/users/pygy/followers","following_url":"https://api.github.com/users/pygy/following{/other_user}","gists_url":"https://api.github.com/users/pygy/gists{/gist_id}","starred_url":"https://api.github.com/users/pygy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pygy/subscriptions","organizations_url":"https://api.github.com/users/pygy/orgs","repos_url":"https://api.github.com/users/pygy/repos","events_url":"https://api.github.com/users/pygy/events{/privacy}","received_events_url":"https://api.github.com/users/pygy/received_events","type":"User","site_admin":false},"created_at":"2018-02-08T11:59:48Z","updated_at":"2018-02-08T11:59:48Z","author_association":"NONE","body":"No worries @lukego I can totally see where you're coming from. If interpreter perf is not a priority then you can totally ignore my comment :-)\r\n\r\nMy understanding of Spectre and Meltdown is pretty superficial too.\r\n\r\nAFAIU, Meltdown is the fact the memory protection is not enforced during speculation, which enables a rogue process to read RAM it isn't allowed to then, depending on the protected content, load some data it has access to in the cache. It avoids page faults by tricking the branch predictor into believing that some actually false condition is likely to be true. After that, it measures the time required to read the data that was put in cache.\r\n\r\nSpectre is about tricking the branch predictor into jumping into arbitrary code and use return-oriented programming while speculating then leave info about what happened by loading stuff in the cache. It is problematic for sandboxes like browsers, but also for processes that can be manipulated from the outside like the OS kernel. There is a Spectre PoC that uses the Linux eBPF interpreter to execute arbitrary kernel code (once again, defeating memory protection). There are also JS PoC that extract info from other tabs.\r\n\r\nIIUC, the Retpoline compiler fix prevents processors from doing ROP while speculating by preventing indirect branch prediction when returning from a function. It makes a program Spectre-resistant.\r\n\r\nAdding Retpoline to the JIT may or may not be a good idea, I don't know enough to judge."}}
{"actor":{"display_login":"pygy"}}