similar to: [LLVMdev] LLVM JIT + Boehm's GC, Need I Worry?

I'm hoping to have a stab at getting a tiny language implementation up and running soon. I assume I can just pull in Boehm's GC to get a very rudimentary collector up and running. However, can this work using JIT compilation from OCaml or will the new GC try to traverse the OCaml program's own stack? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd.

Hi, I'm running LLVM bitcode generated by my compiler under lli. The bitcode is linked against Boehm GC (lli -load=/usr/lib/libgc.so). It looks like Boehm GC isn't scanning global variables and as a result objects referenced only through globals are being prematurely collected. I understand that Boehm GC needs to see the data segment containing my global variables as a root. For native

I've implemented this by adding calls to GC_add_roots(<first global in module>,<last global in module>+1) to the llvm.global_ctors before any other static initialization code for the module. This should be safe assuming that: - global variables are laid out in memory in the order they appear in their module (and ideally contiguously without being interleaved with any other values)

You should look at http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ExecutionEngine/JITMemoryManager.h?view=markup and see if inheriting from that and overriding allocateGlobal() will do what you want. I'm a little surprised the boehm gc doesn't already see the globals, since there's a reference to their memory from the JMM, but maybe it doesn't scan mmap regions by

Hi, I want to use LLVM as replacement code generator for an existing self hosting compiler. I hope to replace the existing BURS code generator with LLVM in order to take advantage of LLVM's JIT, optimizations and wider range of targets. I'm planning on ditching my existing IR completely and using my language's native call mechanism to call the LLVM C bindings. I've got a couple

Forgive my top post but I hate Windows. J I am surprised you (Talin) say that "we know conservative collectors work" because my experience has very much been of them not working. Indeed, if you have 400Mb of allocated heap blocks on a 32-bit machine is there not a 10% chance of *each* random 32-bit int "pointing" into your heap, i.e. a false positive? I just did a simple

Basile STARYNKEVITCH wrote: > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? > > (I mean that I want several mutator threads; the collector can be > stoptheworld or concurrent ....) > > H.Boehm's conservative GC is multithread compatible, but seems quite > slow (allocation is

Hello All Does any know about some opensource multithread-compatible (or concurrent) garbage collector library, if possible suitable for LLVM? (I mean that I want several mutator threads; the collector can be stoptheworld or concurrent ....) H.Boehm's conservative GC is multithread compatible, but seems quite slow (allocation is about the time of a C malloc). And it is well known that

I'm implementing a JIT and getting some strange crashes. I'm unsure exactly what's causing them, but it seems to occur when I call the getReturnType() method on some LLVM function objects. More precisely, I'm registering some native C++ functions as LLVM functions through the addGlobalMapping method of an execution engine object. I then keep a pointer to those LLVM function

Hi Nyx, > I'm implementing a JIT and getting some strange crashes. I'm unsure exactly > what's causing them, but it seems to occur when I call the getReturnType() > method on some LLVM function objects. More precisely, I'm registering some > native C++ functions as LLVM functions through the addGlobalMapping method > of an execution engine object. I then keep a

I saw some unexpected behavior in the interaction of hosts allow and hosts deny on Samba 3.0.28. I built Samba 3.2.4 just to be sure it wasn't something that had been fixed. I saw the same behavior. I'm not sure if it is a bug or a failure on my part to understand the documentation or misleading documentation. If I have a share defined as [export] comment = exported

Hello, I've been able to get J3 working with the single and multimap garbage collectors but have hit several snags with Boehm and MMTk. For MMTk I get here: Buildfile: /cs/student/kyleklein/vmkit/mmtk/java/build.xml main: [mkdir] Created dir: /cs/student/kyleklein/vmkit/mmtk/java/classes [javac] Compiling 373 source files to /cs/student/kyleklein/vmkit/mmtk/java/classes

As the Boehm GC is an available option, do I take that to mean it's beneficial for some users but not most? -- Daniel

That sounds rather cumbersome, is there no simpler way to get the actual size of a struct? John Criswell wrote: > > Nyx wrote: >> Hello, >> >> I would just like to ask if it's possible to explicitly free allocas. >> This >> is because I need to call functions that take structs of different sizes >> as >> input, (possibly inside of loops) and I

I'm a bit puzzled. I am able to map an account without any problem on Samba 2.2.8a (security=domain). However, access fails with Samba 3.0.14a when everything else is the same (same configuration files). Any advice as to the cause of the problems (and its solution) would be appreciated. >From 2.2.8a logs [2005/08/24 14:59:51, 3, pid=7767] smbd/reply.c:(880) Domain=[americase]

In the TargetData class (available from you ExecutionEngine), you have some informations available (such as StructLayout...). On Thu, Jun 18, 2009 at 5:08 PM, Nyx <mcheva at cs.mcgill.ca> wrote: > > That sounds rather cumbersome, is there no simpler way to get the actual > size > of a struct? > > > John Criswell wrote: > > > > Nyx wrote: > >>

>> You need to figure out how to pass -rdynamic to the linker, like I said before. http://llvm.org/docs/tutorial/OCamlLangImpl7.html mentions it, but I don't know enough about the ocaml build process to say whether that'll work. I believe I'm already doing that, properly by passing -ccopt -rdynamic to ocamlopt: ocamlopt -cc g++ -ccopt -rdynamic -linkall $(LIBFILES) -o alpha

I'm coding a JIT compiler for C source in OCaml, using LLVM. I'm pretty much done with the LLVM code generation. The problem is that I can't seem to call C library functions. I was told that all I needed to do to be able to link with libc functions was to declare them in my module and give them external linkage, but this does not seem to work. Please note that this is a JIT compiler. I

On Mon, Jun 29, 2009 at 5:54 AM, Nyx<mcheva at cs.mcgill.ca> wrote: > As you can see, I allocate two structs, one taking 16 bytes (containing two > i64 values), and one taking 12 bytes (containing a pointer and an i64 value, > this is on a 32-bit machine) Are you sure that's right? If the target data specifies that a pointer is 64 bits or that i64 has an alignment of 64 bits,

I was simply surprised because some C++ code I implemented/translated into LLVM IR ran significantly slower in the JIT than the C++ version. The code in question was mean to implement the "plus" operator in my scripting language, and had different behaviors depending on the type of the objects being added. I expected it to run faster as I was eliminating a call to a C++ function by