<div dir="ltr"><div dir="ltr" style="font-family:arial,sans-serif;font-size:13px">Hey Sean,<div><br></div><div>I'm sure Andy.K will have some thoughts on this but</div><div>I don't imagine any major API changes being required.</div>
<div>The changes that I have been making are really very </div><div>minor, all the work is already done.</div><div><br></div><div>However I can imagine some client side fallout due to the</div><div>multi-module nature of the proposed solution. The client</div>
<div>side problem being that I imagine that many people are</div><div>using a single monolithic module for various bookkeeping</div><div>purposes on the client side - function signature lookups </div><div>for example.</div>
<div><br></div><div>One slightly dubious way around this might be to have a</div><div>monolithic module 'just for bookkeeping' which is managed</div><div>persistently in 'parallel' to the individual object modules - </div>
<div>which I'm currently throwing away after each "compile".  </div><div>Ultimately though it's probably better for the client to manage</div><div>this kind of bookkeeping outside of LLVM anyway?</div><div>
<br></div><div>Another solution might be to add some additional meta-data </div><div>to the runtime memory manager - although I can't imagine</div><div>people liking this idea very much as it would be a fairly</div><div>
gross violation of the current mem-mgr interface.</div><div><br></div><div>Anyway, I'm sure that Andy will have a much better handle</div><div>on what solutions might or might not be appropriate.</div><div><br></div><div>
Cheers,</div><div>Andrew. </div></div><div class="" style="font-family:arial,sans-serif;font-size:13px"></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 16, 2013 at 7:38 AM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is great news!<br>
<br>
Does it seem like it will be possible to develop an actual coherent<br>
API that we can point people to? (e.g. for old JIT users to migrate<br>
to). Or is this solution best packaged as pure documentation "this is<br>
how you accomplish this; adapt the ideas to your use case"?<br>
<br>
I would prefer having an actual API for clients to use. We have no<br>
shortage of people waiting for MCJIT lazy compilation, so it probably<br>
won't be hard to collect feedback to iterate the API design.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Sean Silva<br>
</font></span></blockquote></div><br></div>