{"action":"created","issue":{"url":"https://api.github.com/repos/JuliaLang/julia/issues/14272","labels_url":"https://api.github.com/repos/JuliaLang/julia/issues/14272/labels{/name}","comments_url":"https://api.github.com/repos/JuliaLang/julia/issues/14272/comments","events_url":"https://api.github.com/repos/JuliaLang/julia/issues/14272/events","html_url":"https://github.com/JuliaLang/julia/pull/14272","id":120501604,"number":14272,"title":"Use ORC JIT for better compile time and runtime performance","user":{"login":"Keno","id":1291671,"avatar_url":"https://avatars.githubusercontent.com/u/1291671?v=3","gravatar_id":"","url":"https://api.github.com/users/Keno","html_url":"https://github.com/Keno","followers_url":"https://api.github.com/users/Keno/followers","following_url":"https://api.github.com/users/Keno/following{/other_user}","gists_url":"https://api.github.com/users/Keno/gists{/gist_id}","starred_url":"https://api.github.com/users/Keno/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Keno/subscriptions","organizations_url":"https://api.github.com/users/Keno/orgs","repos_url":"https://api.github.com/users/Keno/repos","events_url":"https://api.github.com/users/Keno/events{/privacy}","received_events_url":"https://api.github.com/users/Keno/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/JuliaLang/julia/labels/codegen","name":"codegen","color":"d4c5f9"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-12-04T22:43:43Z","updated_at":"2015-12-05T17:35:31Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/JuliaLang/julia/pulls/14272","html_url":"https://github.com/JuliaLang/julia/pull/14272","diff_url":"https://github.com/JuliaLang/julia/pull/14272.diff","patch_url":"https://github.com/JuliaLang/julia/pull/14272.patch"},"body":"This is somewhat of a rewrite of the way we use MCJIT + a move to ORC JIT to avoid a) some runtime overhead related to MCJIT not reusing the pass manager and b) the memory overhead of MCJIT requiring you to hold onto the LLVM IR, both of which will not be fixed upstream, because they are fixed in the C API. The new ORC based jit is in jitlayers.cpp, but the intention is that both the old jit and MCJIT continue working for now. As a result the code is slightly more messy than it should be in a number places because there are now three possible JITs that could run over it.\r\n\r\nThere are two core aspects of this rewrite:\r\n1) Attempting to combine multiple functions into a single module in order to reduce per-module overhead in the compiler. The primary difficulty here is that sometimes we need to compile functions while we're in the middle of IRgening another function (most notably in inference and in staged functions). As a result, we cannot simply have just one module into which everything gets emitted, because that way LLVM would attempt to generate code for a partially IRgened function, which is not what we want. Instead what this IR does is to temporarily put all functions into a global module (technically they could be parentless, but some of LLVM's APIs don't like dealing with parentless functions), which then get reparented to a single active module as soon as all function in a given call cycle are complete.\r\n2) Being more aggressive about freeing memory at all stages of using LLVM. This includes freeing the IR module, as soon as the native code is generated and freeing the native code as soon as it's moved to the executable pages (both of which we were holding on to). The one caveat to this is that there is an additional copy of the native code for the debugger (for the debug sections, in the future I will make sure that copy does not include the actual generated code). Our backtracing code now shares that copy for reading DWARF information.\r\n\r\nI have two more patches pending upstream (1 accepted but not landed, one pending review) before this will actually work with an unmodified copy of LLVM, but I expect to be able to land them shortly. Once that's done, I'll create a backported version for LLVM 3.7.1, which we can then officially activate in a separate pull request.\r\n\r\nAs I mentioned, this should run on all three JITs, so the transition should be relatively smooth. The idea is to run on ORC JIT for LLVM 3.8 and LLVM 3.7.1 with patches, MCJIT on LLVM 3.5+ without patches (this will have some of the known performance problems) where distributions refuse to ship our patches and the old JIT on LLVM 3.3. I'm anticipating keeping the 3.3 JIT around for at least a little while longer in case we encounter any major issues (e.g. in packages) after switching people over, but hopefully we'll be able to remove support for it soon. I imagine the most like scenario is that we wait for the release of 0.5/LLVM 3.8 and go full ORC jit on master, at which point we'll be able to delete quite a bit of code."},"comment":{"url":"https://api.github.com/repos/JuliaLang/julia/issues/comments/162226906","html_url":"https://github.com/JuliaLang/julia/pull/14272#issuecomment-162226906","issue_url":"https://api.github.com/repos/JuliaLang/julia/issues/14272","id":162226906,"user":{"login":"Keno","id":1291671,"avatar_url":"https://avatars.githubusercontent.com/u/1291671?v=3","gravatar_id":"","url":"https://api.github.com/users/Keno","html_url":"https://github.com/Keno","followers_url":"https://api.github.com/users/Keno/followers","following_url":"https://api.github.com/users/Keno/following{/other_user}","gists_url":"https://api.github.com/users/Keno/gists{/gist_id}","starred_url":"https://api.github.com/users/Keno/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Keno/subscriptions","organizations_url":"https://api.github.com/users/Keno/orgs","repos_url":"https://api.github.com/users/Keno/repos","events_url":"https://api.github.com/users/Keno/events{/privacy}","received_events_url":"https://api.github.com/users/Keno/received_events","type":"User","site_admin":false},"created_at":"2015-12-05T17:35:31Z","updated_at":"2015-12-05T17:35:31Z","body":"After the rebase, there's a heisenbug on OS X when using this branch. Posting here in case something jumps out to anybody:\r\n```\r\nframe #2: 0x0000000100025b74 libjulia-debug.dylib`jl_lam_vinfo(l=0x000000010a1a85f0) + 212 at ast.c:706\r\n   703 \t{\r\n   704 \t    assert(jl_is_expr(l));\r\n   705 \t    jl_value_t *le = jl_exprarg(l, 1);\r\n-> 706 \t    assert(jl_is_array(le));\r\n   707 \t    jl_value_t *ll = jl_cellref(le, 0);\r\n   708 \t    assert(jl_is_array(ll));\r\n   709 \t    return (jl_array_t*)ll;\r\n(lldb) p le\r\n(jl_value_t *) $1 = 0x0000000108022470\r\n(lldb) p jl_(le)\r\n22\r\n(lldb) p l\r\n(jl_expr_t *) $2 = 0x000000010a1a85f0\r\n(lldb) p jl_(l)\r\nExpr(:lambda, <?#0x109d31e10::TypeName(name=:DataType, module=Core, names=svec(:name, :super, :parameters, :types, :instance, :size, :abstract, :mutable, :pointerfree, :ninitialized), primary=DataType, cache=svec(), linearcache=svec(), uid=3)>, 22, TypeName(name=:NTuple, module=Core, names=svec(), primary=NTuple, cache=svec(), linearcache=svec(), uid=20))::Any\r\n```"}}