a2800276_
|
Posted: June 09, 2010 15:02 by a2800276_
|
|
Hi all! is there a place (mailing list or forum) where more active discussion is taking place? There was some talk about moving to java.net in another post, but the java.net btrace page mentions "!!! We have moved !!!" .... to kenai. In case this is the place to ask questions: Is there some way to add probes to all methods on every object? I'd like to do something like this: @OnMethod(clazz="/.*/", method="/.*/") but it seems to either take an exorbitant amount of time, or --I assume-- it recurses across itself and all sorts of evil stuff happens, anyway, there's no feedback. With debugging turned on, you can see: DEBUG: received com.sun.btrace.comm.RetransformationStartNotification@4bd53f5b the RetransformationStartNotification arrive, but no `OkayCommand` ever arrives confirming Transformation is finished. It seems like wanting to trace every method (e.g. to generate a callgraph) would be a relatively common thing to want to do, this feature is also available in dtrace, so I feel I'm missing something very obvious... |
Current Home / Discussion
8 posts
Replies: 7 - Last Post: August 04, 2011 07:16
by: Jaroslav Bachorik
by: Jaroslav Bachorik
showing 1 - 8 of 8
m_hess
|
Posted: June 10, 2010 11:07 by m_hess
|
|
Hi, I think that you have the correct configuration, but the wrong expectations towards BTrace. As BTrace uses ASM to inject itself into the matching probespots, this means, that it creates lots and lots of overhead if you do so for every method you ever encounter. I don't think that BTrace recurses into itself, but it simply takes a very long time to setup this up. Also, you might want to check out your permgen. As BTrace has to create a new class definition for any class you want to probe, this means for your setup you need twice the PermGen space. Maybe you are simply running out of permgen, or at least your VM starts to do more and more garbage collection on the PermGen effectively slowing things down to almost a halt. Other than that, just be patient. Maybe also check the "AllCalls" examples Jaroslav has provided. But as said before, I think you are doing it the right way. Just also make sure, you don't do anything expensive (cpu- or memory-wise) in your probe method. Triggering code for EVERY method, means a lot of runs through that code, so you better be sure you do not simply wreck the System with it. About the wrong expectations: I don't think that creating a call graph is very common. I think the more common thing you want to do, is to trigger at spefic spots and more specific to do measurements. This also somewhat seems like the intended purpose, as BTrace has several helpers that support time measuring, like e.g. the Aggregations. In our project we use BTrace to measure the time it takes for specific subroutines to complete. The values are historized and plotted by the build server, and therefore allow us to quickly see if a change messed with the performance. Hope this gives you an idea of how it can be used. bye, Michael |
|
a2800276_
|
Posted: June 10, 2010 13:30 by a2800276_
|
|
Hi Michael, thanks for the response. > I don't think that BTrace recurses into itself, but it simply takes a very long time to setup this up. You're right, it doesn't, I checked and BTrace skips instrumentation of any class it considers dangerous (mostly btrace classes and sun.reflect.*). So in theory, what I'm doing should work, albeit slowly. It seems that instrumenting every class does cause considerable stress to the VM which then has a tendency to crash or for wire communications to get out of sync.* I'll try to file a proper bug report once I get better acquainted.t > About the wrong expectations: I don't think that creating a call graph is very common. Triggering a probe for every function in the system is sort of the "Hello World" of DTrace, and the relationship "Btrace is Dtrace for Java" is emphasized quite heavily. I agree that generating call-graphs may not be common, but I think something like generating profiling data for the vm would be. To get a better understanding of what I'm trying to do: I'd like to generate _specific_ callgraphs, e.g. trace all calls from the current thread as soon as e.g. some servlets `doGet` method is called. And since the instrumentation can be configured dynamically, all calls need to be instrumented, but the code only gets executed under specific conditions. For starters, I'd be fine with aggregations, as long as _all_ method calls between entry and return of one specific function are aggregated  Cheers, -tim * on ubuntu, it seems to effect openjdk more than sun's... |
Jaroslav Bachorik
|
Posted: June 17, 2010 07:19 by Jaroslav Bachorik
|
|
Hi Tim, wouldn't specifying @Location(value=Kind.CALL) help you? Check out the AllCalls1.java sample for the usage. Regarding the instrumentation of all the methods of all the loaded classes - yes, this will bring *significant* overhead, especially when doing the class retransformation, and I wouldn't recommend it. I am considering transplanting the root method functionality from NetBeans Profiler but it won't be any time soon. Cheers, JB |
|
markjwebb
|
Posted: August 03, 2011 22:55 by markjwebb
|
|
I also came across exactly the same problem. I have an issue in a large system where occasionally large amounts of objects are being allocated during a short period of time and then are almost immediately being garbage collected. Dumping the heap will not help since there are no references to these objects so I want to use btrace to discover: 1) What are the class names of the objects being created 2) The points in the code responsible for the excess object creation I tried to use @OnMethod(clazz="/.*/", method="<init>") but with debug true I can see btrace never gets past the RetransformationStartNotification message. Would it be possible for btrace in debug mode to print out a progress of how many classes it has completed instrumenting e.g. Instrumented 100 out of 10000 classes ... Instrumented 200 out of 10000 classes ... ... Completed instumentation Without this you have no clue as to how many classes you are going to instrument and how long you might have to wait. Even worse is that if you press Ctrl-C before instrumentation is finished then it seems that your method is never called at all. It makes me wonder whether perhaps btrace gives up completely if the number of classes that must be instrumented exceeds a particular number? I even tried including the location=@Location(value=Kind.CALL, clazz="/.*/", method="/.*/") but still the second OkayCommand never appears. I also found through experimentation that if your regex expression matches with a certain class under java.util.concurrent (I could find out the exact class if anyone is interested) then it causes an exception to be thrown in the target process. So I had to modify my regex to exclude this package as follows clazz="/(?!^java\\.util\\.concurrent..*)(.*)/" |
|
markjwebb
|
Posted: August 03, 2011 23:14 by markjwebb
|
I just found another log file that seems to contain output from btrace. The script that I've created is called "AllocationTracker" and it looks from the log file that multiple runs of btrace can be instrumenting the classes at the same time which sounds undesirable. I can see entries in this log file for AllocationTracker, AllocationTracker$0, AllocationTracker$1, etc etc.btrace DEBUG: calling retransformClasses (657 classes to be retransformed) btrace DEBUG: client AllocationTracker$0: got com.sun.btrace.comm.RetransformationStartNotification@4f643703 btrace DEBUG: client AllocationTracker: skipping transform for java/io/PrintWriter btrace DEBUG: client AllocationTracker$0: instrumenting java/io/PrintWriter btrace DEBUG: client AllocationTracker: instrumenting java/lang/RuntimeException btrace DEBUG: client AllocationTracker$0: instrumenting java/lang/RuntimeException btrace DEBUG: client AllocationTracker: skipping transform for java/util/Collections$EmptyList btrace DEBUG: client AllocationTracker$0: instrumenting java/util/Collections$EmptyList btrace DEBUG: client AllocationTracker: skipping transform for java/util/regex/Pattern$CharPropertyNames$20 btrace DEBUG: client AllocationTracker$0: instrumenting java/util/regex/Pattern$CharPropertyNames$20 I think it would be better if btrace could cancel the instrumentation of classes when the btrace script exits so that we don't get into this situation where concurrent instrumentations are overwriting each other. This is the last entry in the log file: # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000002a959302b6, pid=2550, tid=1085491552 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0_01-b06 mixed mode) # Problematic frame: # V [libjvm.so+0x2aa2b6] # # An error report file with more information is saved as hs_err_pid2550.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # |
Jaroslav Bachorik
|
Posted: August 04, 2011 07:16 by Jaroslav Bachorik
|
|
Multiple instrumentation for different clients should work fine - they should not overwrite each other, they are stacked on top each other instead. The error message has much more likely to do with the fact that you are using JDK6u01. JDK6u10 would be the lowest recommended version since most of the dynamic instrumentation related bux have been fixed till then. -JB- |
showing 1 - 8 of 8
Replies: 7 - Last Post: August 04, 2011 07:16
by: Jaroslav Bachorik
by: Jaroslav Bachorik
