|
From: Xin T. <tre...@gm...> - 2014-07-29 16:53:15
|
I am planning to use valgrind to experiment some of the self modifying code handling ideas I have. but i got a crash when running a java benchmark under valgrind built by myself. Also i see the CPU usage of the valgrind process always below 100, which means only one CPU is occupied. Is valgrind serializing the execution of the threads in the JVM ? Xin xtong@socrates:~/valgrind-3.9.0/build/bin$ ./valgrind --smc-check=all --tool=cachegrind java -jar ~/benchmarks/DACAPO/dacapo-9.12-bach.jar h2 ==7599== Cachegrind, a cache and branch-prediction profiler ==7599== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote et al. ==7599== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==7599== Command: java -jar /home/xtong/benchmarks/DACAPO/dacapo-9.12-bach.jar h2 ==7599== --7599-- warning: L3 cache found, using its data for the LL simulation. --7599-- warning: pretending that LL cache has associativity 24 instead of actual 16 Using scaled threading model. 16 processors detected, 16 threads used to drive the workload, in a possible range of [1,4000] # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (sharedRuntime.cpp:814), pid=7599, tid=68437760 # guarantee(cb->is_adapter_blob() || cb->is_method_handles_adapter_blob()) failed: exception happened outside interpreter, nmethods and vtable stubs (1) # # JRE version: OpenJDK Runtime Environment (7.0_55-b14) (build 1.7.0_55-b14) # Java VM: OpenJDK 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/xtong/valgrind-3.9.0/build/bin/hs_err_pid7599.log # # If you would like to submit a bug report, please include # instructions on how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # ==7599== ==7599== I refs: 2,092,356,742 ==7599== I1 misses: 11,059,607 ==7599== LLi misses: 49,197 ==7599== I1 miss rate: 0.52% ==7599== LLi miss rate: 0.00% ==7599== ==7599== D refs: 932,164,115 (645,948,209 rd + 286,215,906 wr) ==7599== D1 misses: 74,115,777 ( 24,329,462 rd + 49,786,315 wr) ==7599== LLd misses: 740,728 ( 133,298 rd + 607,430 wr) ==7599== D1 miss rate: 7.9% ( 3.7% + 17.3% ) ==7599== LLd miss rate: 0.0% ( 0.0% + 0.2% ) ==7599== ==7599== LL refs: 85,175,384 ( 35,389,069 rd + 49,786,315 wr) ==7599== LL misses: 789,925 ( 182,495 rd + 607,430 wr) ==7599== LL miss rate: 0.0% ( 0.0% + 0.2% ) Killed xtong@socrates:~/valgrind-3.9.0/build/bin$ |
|
From: Eliot M. <mo...@cs...> - 2014-07-29 17:31:45
|
On 7/29/2014 12:53 PM, Xin Tong wrote: > I am planning to use valgrind to experiment some of the self modifying code handling ideas I have. > but i got a crash when running a java benchmark under valgrind built by myself. > > Also i see the CPU usage of the valgrind process always below 100, which means only one CPU is > occupied. Is valgrind serializing the execution of the threads in the JVM ? Dear Xin -- There are a couple of issues you may be dealing with here. The immediate problem may be that Java is a little unusual in that it generates code on the fly. You need to tell valgrind some of that kind of thing. Here are the flags I used with the JDK: --smc-check=all --vexiropt-precise-memory-exns=yes I also have a custom modification of valgrind that allows me to collect separate trace files for different child processes; maybe not essential here, but I had some use for it. In terms of flags passed to the JVM, I used: -XX:+UseSerialGC This was a while ago, so I can;'t recall if this was necessary or just a preference, but it might be necessary. In terms of DaCapo (something I also have to do with that!), h2 is likely to run into timeouts and stuff. If you encounter that, I can perhaps give you some advice off of this list. Regards -- Eliot Moss |