search for: poisonmemori

The patch looks good to me. But we cannot allow 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

On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> wrote: > The patch looks good to me. But we cannot allow AllocateGVsWithCode to > be initialized to be false yet. Can you add a mechanism to define the > behavior when the JIT is created / initialized? That makes four optional arguments to ExecutionEngine::create. Do you mind if I go ahead and add an

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,

On Jul 2, 2009, at 5:20 PM, Reid Kleckner wrote: > On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> The patch looks good to me. But we cannot allow AllocateGVsWithCode >> to >> be initialized to be false yet. Can you add a mechanism to define the >> behavior when the JIT is created / initialized? > > That makes four

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,