[llvm-commits] [llvm] r91626 - in /llvm/trunk: lib/ExecutionEngine/JIT/JIT.cpp lib/ExecutionEngine/JIT/JIT.h lib/ExecutionEngine/JIT/JITEmitter.cpp unittests/ExecutionEngine/JIT/JITTest.cpp

[nicolas geoffray]

>
> The behavior was not ok before my change: available_externally
> functions loaded lazily from bitcode would infinite-loop if you ever
> actually called them. This change avoided that infinite loop at the
> cost of loading one extra layer of functions from bitcode. It doesn't
> load the whole transitive call graph, just one layer down from the
> function you actually need to compile, and unless I did something
> wrong it doesn't compile that extra layer. Nick and I intend to fix
> PR5737 before 2.7 comes out, but trading some extra memory and time to
> get rid of an infinite loop seemed like a decent short-term option.
>
>
It's not just about memory and time. See my comment below.



> Now, if it's costing vmkit more memory or time than I expected, I'm
> certainly willing to reconsider the order of these two fixes. What did
> this actually break for you? How much extra time or memory is it
> costing?
>
>
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 :)

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20091222/0c52dbe1/attachment.html>