similar to: [LLVMdev] JIT and garbage collection

Yes, the JIT implementation was recently improved to add support for this. There's nothing you need to do (or emit). The JIT implementation will automatically collect memory that is not being used. See the JITMemoryManager in lib/ExecutionEngine/JIT/JITEmitter.cpp for details. Reid. On Sun, 2006-08-06 at 14:30 -0400, Hendrik Boom wrote: > If I recall correctly, the garbage collector

On Sun, 6 Aug 2006, Reid Spencer wrote: > Yes, the JIT implementation was recently improved to add support for > this. There's nothing you need to do (or emit). The JIT implementation > will automatically collect memory that is not being used. See the > JITMemoryManager in lib/ExecutionEngine/JIT/JITEmitter.cpp for details. The JIT doesn't automatically do this. I don't

On Sun, 06 Aug 2006 12:04:31 -0700, Chris Lattner wrote: > On Sun, 6 Aug 2006, Reid Spencer wrote: >> Yes, the JIT implementation was recently improved to add support for >> this. There's nothing you need to do (or emit). The JIT implementation >> will automatically collect memory that is not being used. See the >> JITMemoryManager in

Hi, here are some minor patches that for various reasons I've not submitted yet - I'm just trying to clear my list of differences before christmas... First of all the clear.patch file contains a patch that enables the JIT to drop all global mappings. I need this because when I have N threads I compile N different versions of my functions using different memory areas for global

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

Q. What resource do readers recommend for referencing regarding best practices for form construction in Rails? I have the following situation: location_type of Locations may have one of five (5) possible codes. Presently I have these codes listed in a drop-down select constructed thusly: <p> <b>Location type</b><br /> <%= f.select :location_type,

Hi all, I'm using LLVM to generate a fairly large number of separate functions at run-time. To minimize the memory overhead, I'd like to delete the IR and everything else that is no longer needed after a function has been generated (I don't use lazy compilation or anything like that). I noticed that deleting the ExecutionEngine deletes everything (Module, Function(s),

Hi Evan, Thanks a lot for the information! It's a viable solution to write my own JITMemoryManager, however I noticed that the JIT doesn't know the length of the binary function before it is actually emitted. This is a bit inconvenient especially since I have to generate new functions at irregular times. I'm not too keen on using the non-standard _expand function to resize

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the

Hello, I've tracked down a new memory leak which started happening when I enabled constant propagation (I created my own passmanager which I run before calling getPointerToGlobal to JIT the function I have generated - is this OK?). The reason is that FP constants are being spilled to memory as there is no immediate fp load available. In my case this is a bit unnecessary since the

Gordon Henriksen wrote: > On 2007-09-15, at 23:55, Talin wrote: > >> Gordon Henriksen wrote: >> >>> Can you be more specific the algorithm for which you need type >>> metadata in a write barrier? No algorithms I am aware of perform any >>> tracing from a write barrier. >> >> This one does: >> >>

I'm still (slowly) working on the project of creating a concurrent garbage collector that works with LLVM. I want to ask a little bit more about object tags and write barriers and so on. Let's start with the assumption that a particular language does not use per-object type tags. The code generator knows the types of all objects, however, and can pass along that type information to

Gordon Henriksen wrote: > Can you be more specific the algorithm for which you need type > metadata in a write barrier? No algorithms I am aware of perform any > tracing from a write barrier. > This one does: http://citeseer.ist.psu.edu/cache/papers/cs2/442/http:zSzzSzwww.cs.technion.ac.ilzSz~erezzSzPaperszSzms-sliding-views.pdf/an-on-the-fly.pdf > Write barriers are

Hi Evan, Evan Cheng wrote: > 1) How are you computing size of the method being > jitted? I add a new pass with addSimpleCodeEmitter, with the emitter being a SizeEmitter. Since the target calls the emitter with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the

Chris Lattner wrote: > On Mon, 6 Dec 2004, Morten Ofstad wrote: >> I guess what I'd like to know is if the process of spilling constants >> to memory could be a bit more controlled, maybe using the JIT memory >> manager and putting it in with the function stubs? > > Yes, this can and should definitely be improved. If you look at >

On 2007-09-15, at 18:01, Talin wrote: > I'm still (slowly) working on the project of creating a concurrent > garbage collector that works with LLVM. I want to ask a little bit > more about object tags and write barriers and so on. > > Let's start with the assumption that a particular language does not > use per-object type tags. The code generator knows the types

When JITEmitter is teared down, it also deletes the JITMemoryManager instance. That in turns release the memory of the generated functions. Is this what you are referring to? The DefaultJITMemoryManager is pretty simple. You can obviously write your own memory manager class that maps the memory in a way that's persistent. Then all you have to do is to pass a handle of it to