[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

[Jeffrey Yasskin]

On Mon, Dec 21, 2009 at 3:03 PM, nicolas geoffray
<nicolas.geoffray at gmail.com> wrote:
>> 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 :)

Ah, I see now. You have your own ModuleProvider, and it needs to know
precisely when the function is actually needed, right? Yeah, it sounds
like I need to roll back that part of this fix until PR5737 is fixed.

Could you please write some tests for the ways you're using
ModuleProviders and the other interfaces in LLVM? I keep breaking or
nearly breaking you, and I'd be much more likely to get this right if
a test broke when I got it wrong.