search for: poisonmemory

...llow AllocateGVsWithCode to be initialized to be false yet. Can you add a mechanism to define the behavior when the JIT is created / initialized? Also, I am not crazy about this being moved to JITMemoryManager.h. This seems like implementation detail that should be kept hidden. + // If the PoisonMemory parameter is true, freed memory should be overwritten + // with garbage. This parameter is useful for testing and debugging. +#ifdef NDEBUG +#define POISON true +#else +#define POISON false +#endif Thanks, Evan On Jul 1, 2009, at 11:48 AM, Evan Cheng wrote: > Sorry I am late to the threa...

.../ initialized? That makes four optional arguments to ExecutionEngine::create. Do you mind if I go ahead and add an EngineBuilder? > Also, I am not crazy about this being moved to JITMemoryManager.h. > This seems like implementation detail that should be kept hidden. > > +  // If the PoisonMemory parameter is true, freed memory should be > overwritten > +  // with garbage.  This parameter is useful for testing and debugging. > +#ifdef NDEBUG > +#define POISON true > +#else > +#define POISON false > +#endif I wasn't crazy about it either, but it was hard to construc...

Hi Tanya, glad to see that 2.6 release is coming. :) After doing some testing with valgrind on this release, I have find a little "undefined memory" error in DefaultJITMemoryManager related to the PoisonMemory field. This bug has been corrected in trunk with revision r80192. Attached is a patch which cleanly apply same correction on the release-2.6 branch. Thanks, Olivier. On Sat, Oct 17, 2009 at 8:51 PM, Tanya Lattner <lattner at apple.com> wrote: > LLVMers, > 2.6 pre-release2 is ready...

...rguments to ExecutionEngine::create. Do you > mind if I go ahead and add an EngineBuilder? Please, thanks. > >> Also, I am not crazy about this being moved to JITMemoryManager.h. >> This seems like implementation detail that should be kept hidden. >> >> + // If the PoisonMemory parameter is true, freed memory should be >> overwritten >> + // with garbage. This parameter is useful for testing and >> debugging. >> +#ifdef NDEBUG >> +#define POISON true >> +#else >> +#define POISON false >> +#endif > > I wasn't cr...

Sorry I am late to the thread. I've been meaning to find the time to respond properly. 1. Yes, the default behavior is to keep GV and function in the same memory buffer. The reason is the JIT can be used in a client and server environment. This makes it possible without doing expensive relocation on the fly. In fact, the currently implementation doesn't allow the client to do

> We have been JITing kernels and having a memory manager for globals > would be a big win there (clean up a few hacks to make things go in > the correct locations). I'm also guessing that Dale's client at Apple is using a custom memory manager, since without doing that there's no way to get the size of the code block in order to send it over the wire. Adding an

LLVMers, 2.6 pre-release2 is ready to be tested by the community. http://llvm.org/prereleases/2.6/ If you have time, I'd appreciate anyone who can help test the release. To test llvm-gcc: 1) Compile llvm from source and untar the llvm-test in the projects directory (name it llvm-test or test-suite). Choose to use a pre- compiled llvm-gcc or re-compile it yourself. 2) Run make check,