<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">The behavior was not ok before my change: available_externally</div>
functions loaded lazily from bitcode would infinite-loop if you ever<br>
actually called them. This change avoided that infinite loop at the<br>
cost of loading one extra layer of functions from bitcode. It doesn't<br>
load the whole transitive call graph, just one layer down from the<br>
function you actually need to compile, and unless I did something<br>
wrong it doesn't compile that extra layer. Nick and I intend to fix<br>
PR5737 before 2.7 comes out, but trading some extra memory and time to<br>
get rid of an infinite loop seemed like a decent short-term option.<br>
<br></blockquote><div><br></div><div>It's not just about memory and time. See my comment below.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Now, if it's costing vmkit more memory or time than I expected, I'm<br>
certainly willing to reconsider the order of these two fixes. What did<br>
this actually break for you? How much extra time or memory is it<br>
costing?<br>
<div class="im"><br></div></blockquote><div><br></div><div>The problem is not memory nor time. It's just that materializeFunction in Java includes calling applicative code to actually load the class that will be transformed to llvm instructions. However, in Java/vmkit everything must be done lazily, especially loading a class :) </div>
<div><br></div><div>Nicolas</div></div>