<div dir="ltr"><div>Hi Dibyendu,<br></div><div><br></div><div><span style="color:rgb(80,0,80);font-size:13px">> Sincere apologies for the name typo below!</span><br style="color:rgb(80,0,80);font-size:13px"></div><div><br></div><div>No worries. :)</div><div><br></div><div>Regarding the choice of JITs: MCJIT is more mature, and we have an ongoing commitment to support it. That's not the case for Orc, which is still experimental.  Since you're writing an abstraction layer anyway you could choose either approach. They share a lot of fundamental ideas, and it should be reasonably easy to move from one to the other later. Two big points of distinction: MCJIT has some basic thread-safety, Orc does not (though I'd love to see it added). Orc has some in-tree support for lazy-compilation, which MCJIT does not (you'll have to build that on top of MCJIT yourself).</div><div><br></div><div>You mentioned being able to garbage collect functions: Orc lets you remove Modules from the JIT out-of-the-box (see HandleTopLevelExpression in the Kaleidoscope tutorials for an example), in MCJIT you would do it implicitly by throwing away the MCJIT instance (and the associated RTDyldMemoryManager).</div><div><br></div><div>> <span style="font-size:13px">BTW a newbie question - once I have compiled a function - is there a</span></div><span style="font-size:13px">> need to retain the module and engine - apart from the fact that the</span><br style="font-size:13px"><span style="font-size:13px">> memory allocated to the JITed function is presumably managed by the</span><br style="font-size:13px"><span style="font-size:13px">> engine?</span><br style="font-size:13px"><div><br></div><div>There's no fundamental barrier to throwing away the ExecutionEngine. The memory allocated to JIT'd functions is managed by whatever RTDyldMemoryManager you build the ExecutionEngine with. You could write a custom RTDyldMemoryManager that allowed you to take ownership of the allocated memory before the ExecutionEngine was destroyed. Note however that each ExecutionEngine holds the symbol table for the modules it JITs. If you throw away the execution engine you'll want to make sure that you've already got all the function/global pointers you need out of it.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 10, 2015 at 3:15 PM, Dibyendu Majumdar <span dir="ltr"><<a href="mailto:mobile@majumdar.org.uk" target="_blank">mobile@majumdar.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">Hi Lang,<br>
<br>
Sincere apologies for the name typo below!<br>
<br>
Regards<br>
<br>
</span><span class="im HOEnZb">On 10 February 2015 at 22:46, Dibyendu Majumdar <<a href="mailto:mobile@majumdar.org.uk">mobile@majumdar.org.uk</a>> wrote:<br>
</span><div class="HOEnZb"><div class="h5">> Hi James,<br>
><br>
> On 10 February 2015 at 22:28, Lang Hames wrote:<br>
>><br>
>> A single MCJIT instance can notionally manage multiple modules, but there<br>
>> are caveats (which I'm afraid I don't remember off the top of my head) that<br>
>> make it unattractive in practice. I believe most clients opt for something<br>
>> like the ExecutionEngine-per-Module model used in the Kaleidoscope<br>
>> tutorials.<br>
><br>
> I see. That's good to know.<br>
><br>
>> As Dave mentioned, I'm also working on some new JIT APIs (Orc) that are<br>
>> intended to be more feature-rich and easier to use than MCJIT. If you would<br>
>> like to try them out and have any questions about how they work please don't<br>
>> hesitate to ask. You'll need to live on the bleeding edge for those though -<br>
>> they're not available on 3.5.<br>
>><br>
><br>
> I am at an early stage of development so I can use Orc provided there<br>
> is some assurance that this will be mainstream in future. Else I can<br>
> use the MCJIT replacement that uses Orc. If I wanted to do this should<br>
> I clone the latest code from github?<br>
><br>
> In any case I am abstracting the creation and management of engines,<br>
> modules etc in my code so that I can change this in future if<br>
> necessary.<br>
><br>
> Thanks and Regards<br>
><br>
> Dibyendu<br>
</div></div></blockquote></div><br></div>