search for: gcalloc

Hi, I can't seem to get VMKit to compile correctly. I'm on a 64 bit Jaunty system. I compiled llvm and llvm-gcc from the subversion source no problem, but when I try to compile VMKit I get some issue with GCAllocator: /home/mmwu/Download/llvm$ ./configure /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 install ... /home/mmwu/Download/$ sudo apt-get install classpath ... /home/mmwu/Download/vmkit$ ./configure --with-llvmsrc=/home/mmwu/Download/llvm -...

...Quoting Michael Wu <mmwu at princeton.edu>: > Hi, > > I can't seem to get VMKit to compile correctly. I'm on a 64 bit > Jaunty system. I compiled llvm and llvm-gcc from the subversion source > no problem, but when I try to compile VMKit I get some issue with > GCAllocator: > > /home/mmwu/Download/llvm$ ./configure > /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 > /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 install > > ... > > /home/mmwu/Download/$ sudo apt-get install classpath > > ... > > /home/mmwu/Download/vmkit$...

...ESEARCH/classpath-0.97.2/lib I get: llvm[1]: Compiling vmjc.cpp for Release build llvm[1]: Linking Release executable vmjc (without symbols) /home/zoewolk/RESEARCH/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In function `mvm::Collector::destroy()': gcinit.cpp:(.text+0x24): undefined reference to `GCAllocator::~GCAllocator()' gcinit.cpp:(.text+0x2c): undefined reference to `GCAllocator::operator delete(void*)' /home/zoewolk/RESEARCH/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In function `mvm::Collector::initialise()': gcinit.cpp:(.text+0x93): undefined reference to `GCAllocator::operator...

...kit/vmkit/tools/vmjc' llvm[1]: Compiling vmjc.cpp for Debug build llvm[1]: Linking Debug executable vmjc /home/mn/tests/VMkit/vmkit/Debug/lib/libGCMmap2.a(gcinit.o): In function `mvm::Collector::initialise()': /home/mn/tests/VMkit/vmkit/lib/Mvm/GCMmap2/gcinit.cpp:22: undefined reference to `GCAllocator::operator new(unsigned long)' /home/mn/tests/VMkit/vmkit/lib/Mvm/GCMmap2/gcinit.cpp:22: undefined reference to `GCAllocator::GCAllocator()' /home/mn/tests/VMkit/vmkit/Debug/lib/libGCMmap2.a(gcinit.o): In function `mvm::Collector::destroy()': /home/mn/tests/VMkit/vmkit/lib/Mvm/GCMmap...

...the following error causes a large stream of errors and a fail: make[1]: Entering directory `/cs/student/kyleklein/vmkit/lib' make[2]: Entering directory `/cs/student/kyleklein/vmkit/lib/Mvm' make[3]: Entering directory `/cs/student/kyleklein/vmkit/lib/Mvm/Allocator' llvm[3]: Compiling gcalloc.cpp for Debug+Asserts build In file included from /cs/student/kyleklein/vmkit/include/mvm/Allocator.h:19, from /cs/student/kyleklein/vmkit/include/mvm/VirtualMachine.h:18, from gcchunk.h:13, from gcalloc.h:15, from gcalloc.cp...

...but Boehm working >>>> with vmkit release 2.6. >>>> >>>> >>>> Thanks for the help, >>>> Kyle >>>> >>>> Quoting nicolas geoffray <nicolas.geoffray at gmail.com>: >>>> >>>> Do you have a gcalloc.cpp file in lib/Mvm/Allocator? I guess you have >>>> >>>>> since >>>>> the makefile is outputting it. Try removing the PARALLEL_DIRS to the >>>>> Makefiles to see if that helps. >>>>> >>>>> Otherwise I can't...

...know. thanks Z ... llvm[1]: Compiling vmjc.cpp for Debug build llvm[1]: Linking Debug executable vmjc /home/zoewolk/RESEARCH/vmkit/Debug/lib/libGCMmap2.a(gcinit.o): In function `mvm::Collector::initialise()': /home/zoewolk/RESEARCH/vmkit/lib/Mvm/GCMmap2/gcinit.cpp:22: undefined reference to `GCAllocator::operator new(unsigned long)' /home/zoewolk/RESEARCH/vmkit/lib/Mvm/GCMmap2/gcinit.cpp:22: undefined reference to `GCAllocator::GCAllocator()' /home/zoewolk/RESEARCH/vmkit/Debug/lib/libGCMmap2.a(gcinit.o): In function `mvm::Collector::destroy()': /home/zoewolk/RESEARCH/vmkit/lib/Mvm/...

Hi Zoe, maybe you've already solved your problem with VMKit configuration, but here you can find a mini-tutorial that I've done to guide people on VMKit installation. http://www2.dcc.ufmg.br/laboratorios/llp/wiki/doku.php?id=afpf Best regards, Alysson On Wed, Jun 30, 2010 at 1:34 PM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Zoe, > > Unfortunately, I

Hi Zoe, Unfortunately, I don't have access to a x64 machine anymore, so I can't test that architecture on vmkit. Could you install a virtual machine on your machine that is x86_32? I know it has been successfully built and ran on x86_32 on different systems. Cheers, Nicolas On Wed, Jun 30, 2010 at 7:49 AM, Zoe Wolk <zoewolk at gmail.com> wrote: > Hi again Nicolas, > >

...directory `/cs/student/kyleklein/vmkit/lib' make[2]: Entering directory `/cs/student/kyleklein/vmkit/lib/Mvm' make[3]: Entering directory `/cs/student/kyleklein/vmkit/lib/Mvm/Allocator' make[3]: *** No rule to make target `/cs/student/kyleklein/vmkit/lib/Mvm/Allocator/Release+Asserts/gcalloc.ll', needed by `/cs/student/kyleklein/vmkit/lib/Mvm/Allocator/Release+Asserts/gcalloc.bc'. Stop. make[3]: Leaving directory `/cs/student/kyleklein/vmkit/lib/Mvm/Allocator' make[2]: *** [all] Error 1 make[2]: Leaving directory `/cs/student/kyleklein/vmkit/lib/Mvm' make[1]: ***...

On May 16, 2008, at 7:50 AM, Joachim Durchholz wrote: > > Am Freitag, den 16.05.2008, 06:54 -0700 schrieb Chris Lattner: >> On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: >> >>> On May 13, 2008, at 18:28, Dan Gohman wrote: >>> >>> I wonder if it would be worthwhile to have a flag on loads to mark >>> them as immutable. A flag from the

Am Freitag, den 16.05.2008, 06:54 -0700 schrieb Chris Lattner: > On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: > > > On May 13, 2008, at 18:28, Dan Gohman wrote: > > > > I wonder if it would be worthwhile to have a flag on loads to mark > > them as immutable. A flag from the source language stating "this load > > never aliases any subsequent

...r their address was passed to some other > function where there was no way of knowing what the function did to it.  It is > easy to construct toy examples where tracking AllocaInst's helped, but in real > code it did not. > > Ciao, > > Duncan. I'm working on something (gcalloc removal) that would actually be easier if I could easily answer the question "what loads from memory *might* return a given pointer value or a pointer derived from it?" I don't care if it's guaranteed to return the value, but it would be helpful to be able to prove (for instance)...

...variables, or reloading from the gcroot? Copying collectors require that you reload before each use (or, more specifically, between each call that could invoke the collector). e.g., ; object obj; %root = alloca call void llvm.gcroot(%root) ; obj = new Object; %obj.1 = gcalloc() store %obj.1 -> %obj.root ; danger(); // Could invoke the collector! call void danger() ; use(obj); %obj.2 = load %obj.root call void use(%obj.2) ; Not %obj.1! ; danger(); // Could invoke the collector! call void danger() ; use(obj); %obj.3...

Hi I'm using a GC that's pretty similar to the OCaml one. It records stack locations using llvm.gcroot, and dumps out a frametable describing the live stack offsets so that the GC runtime can walk them as required. I'm on 2.3, not svn head. I'm having some trouble with pointers being cached in registers across function calls (at least x86 backend, haven't tried others yet).

Hi Stephan, > I am trying to retrieve all instructions from a function's body that > are dependent on a specific argument. The strategy I am currently > using for that is to follow all uses of the argument and record them. > Also, whenever I encounter a store of a dependent value, I try to find > loads in the function that are dependent on that store and resume >

Hello! I am trying to retrieve all instructions from a function's body that are dependent on a specific argument. The strategy I am currently using for that is to follow all uses of the argument and record them. Also, whenever I encounter a store of a dependent value, I try to find loads in the function that are dependent on that store and resume use-tracking from there. For this purpose I am