I want to track all my public method calls under a certain condition. But I want this tracking to hurt the whole system performance as little as possible.
I would need a way how to "turn on" a pointcut dynamically to be executed just for a specified thread and this turning on (and off) would have to be dynamically callable from my code.
I.e. if my Java code finds out that a certain thing happened it would turn on a pointcut for it's own thread. This pointcut would log all public method calls and after some time (or some number of interceptions) the pointcut would turn itself off.
Of course, I could call a code in the advice like "...getCurrentThread().equals(myMonitoringThread) && monitoringEnabled" but that would mean that the advice would be run for all public method of all threads and always execute this code which would certainly hurt the performance of the whole application.
What I would like to have is isolating the performance penatly just for the selected thread for the enabled time and leave the rest of the threads unaffected.
Does anybody know about a technique how to do it?
Thanks
Tomas
When you use aspects, your classes are affected : the bytecode is modified to be aspect compliant (or in the case of Spring, your calls are proxied with a dedicated aspect compliant class).
In the case of AspectJ it can be done during compilation, just after the compilation or at load-time (have a look here). Instrumented classes are affected the way your aspects are defined (intercept all public methods for example) and that means they can't really be de-affected at runtime (even if I'm quite sure that a crazy coder could invent a load/unload class mecanism to handle that but it would be insane ;).
So to answer your question, I think you can't fully plug/unplug your aspects at runtime in a simple way (if it's only possible !).
Related
When we write synchronized(some_object){} we can see two JVM instructions monitorenter/monitorexit issued as the byte code.
When we write synchronized(some_object){some_object.wait()} i would expect to see special JVM instructions like wait, but none -- instead wait/notify are implemented as native C functions.
Why there is such inconsistency (either have them all as JNI or as java byte code)? Was there a particular (historical) reason or it is just a matter of taste?
Context: i am interested in this because having all monitorenter/monitorexit/wait/notify in the bytecode would allow 'JavaByteCode program correctness verifiers that do not handle JNI' to verify concurrent Java programs that do not use JNI. Currently, such hypothetical tool has to workaround wait/notify.
i would expect to see special JVM instructions like wait
I wouldn't. That would be inconsistent, in my view - in the source code, you're just calling a method, so it makes sense that you're just calling a method in the bytecode as well. Otherwise the compiler would have to have special knowledge of those methods, where it doesn't at the moment.
Arguably it would make more sense for monitorenter and monitorexit to be implemented via method calls as well (as they are in .NET, for example). Certain methods will always be native and deeply tied to the JVM itself - I don't see anything unreasonable about that, and I wouldn't want each of those to be implemented via a separate bytecode operation. However, I don't have too much issue with synchronized having special bytecode supporting it, given that it's a language construct (like try/catch/finally) rather than just a regular method call.
There is no need for a verification program to deal with JNI as the semantics of wait and notify calls are well-specified. That’s not different to dedicated bytecode instructions. The same applies to how the hot spot optimizer deals with a lot of well known method invocations, which may include wait and notify. It does not necessarily generate a costly JNI invocation but rather generate code performing these low-level operations directly. Methods handled this way are called intrinsic methods (see also here or here.
There are so many, that you couldn’t call it bytecode anymore if you tried to reserve an opcode for each of them. Further, which methods are handled this way, depends on the actual JVM implementation and the hardware architecture on which it runs. It might also change between versions so there is no sense to carve it in stone by defining bytecode instructions for them.
You wrote “Currently, such hypothetical tool has to workaround wait/notify”. In fact, handling these special methods is not a work-around. It’s what such an audit tool has to do with a lot of methods like these declared in Lock and Condition which have similar threading-related semantics but there are also a lot of other well-known concurrency tools nowadays which have to be handled.
The exact decision to create monitorenter and monitorexit instructions but make wait and notify methods on Object is historical (it dates back over 20 years ago). Today, the decision might look different if the developers had to make it again. But I guess it would rather go into the direction to make even monitorenter and monitorexit special methods that are invoked under the hood rather than bytecode instructions. First, they are not the only thread synchronization tool anymore. Second, it’s how most of the new feature were added in the recent JVMs, preferably as method, even if it’s expected to be intrinsified by most, if not all, implementations.
Wondering how to not limit connections (or anything) using a Semaphore.
So you might be thinking, "That sounds dumb." But, it simplifies my code a bit as it lets me treat the limited and unlimited cases uniformly.
Note I'm not looking for an advice on how to write something like
if(limited) {
semaphore.acquire();
}
I can come up with dozens of ways to do this forking with if-statements.
More specifically I'm looking for an Apache Commons or Java solution. This is just a simple situation in which I can write my own simple class to solve it, but when there are widely available utility solutions I prefer to use these.
Given that Semaphore is a class, not an interface, you will be forced to have some form of branching in the logic. In order to avoid sprinkling "if (flag)" checks all around your code, you could create an interface for use in your application that includes the acquire and release semantics of the Semaphore class. From that point, provide two implementations, one that is essentially a no-op, providing no protection whatsoever, and another class that delegates to java.util.concurrent.Semaphore - from this point you are in a position to use dependency injection to determine which implementation to use.
Again, the branching inevitably has to live someplace, this just moves it up and out of the business logic.
When writing microbenchmarks, one can observe a large difference in runtime depending on whether a method has been compiled or not. Is there a way to tell from within a program whether a particular method has been compiled? Alternatively, is there a way to request it, or to know how to warm it up adequately without any extra information about e.g. flags passed to the JVM? Obviously this will not necessarily be perfect (e.g. there may be some condition present that causes the JVM to fall back to interpreted code), but it would certainly be an improvement.
For Sun/Oracle JVM you can use the -XX:CompileThreshold=1000 setting.
This - as the official documentation states - defines:
Number of method invocations/branches before compiling
Then, just use the number to "warm up" the JVM.
You can also use the -XX:-PrintCompilation together with -XX:CompileThreshold in order to be notified (in the console) when a method is compiled.
I'm pretty sure you can turn on logging that will show when methods are JITCed. But I don't know of any way from within Java to tell.
And keep in mind that JIT compilation is not an event but a process -- a method may be recompiled several times, as more information about its characteristics becomes available.
Finally, note that "warming up" is iffy in the general case. While you can usually "warm up" a single method reliably, it's much harder with even a modestly large application, due to a number of factors.
(Though I don't know of any reason why the ability to read some sort of JITC status for a method could not be added to embedded debug tools.)
Added: One thing to beware of, when benchmarking code "snippets", is that the outer-most method that does all the looping is often not JITC-able (depending on how the JITC is implemented) due to the fact that it never returns and hence the JITCed version can never be called. So one should always place the "meat" of the code to be benchmarked in a separate method that is called repeatedly, vs putting the loop and the to-be-benchmarked code in the same method.
I've been caught by yet another deadlock in our Java application and started thinking about how to detect potential deadlocks in the future. I had an idea of how to do this, but it seems almost too simple.
I'd like to hear people's views on it.
I plan to run our application for several hours in our test environment, using a typical data set.
I think it would be possible to perform bytecode manipulation on our application such that, whenever it takes a lock (e.g. entering a synchronized block), details of the lock are added to a ThreadLocal list.
I could write an algorithm that, at some later point, compares the lists for all threads and checks if any contain the same pair of locks in opposite order - this would be reported as a deadlock possibility. Again, I would use bytecode manipulation to add this periodic check to my application.
So my question is this: is this idea (a) original and (b) viable?
This is something that we talked about when I took a course in concurrency. I'm not sure if your implementation is original, but the concept of analysis to determine potential deadlock is not unique. There are dynamic analysis tools for Java, such as JCarder. There is also research into some analysis that can be done statically.
Admittedly, it's been a couple of years since I've looked around. I don't think JCarder was the specific tool we talked about (at least, the name doesn't sound familiar, but I couldn't find anything else). But the point is that analysis to detect deadlock isn't an original concept, and I'd start by looking at research that has produced usable tools as a starting point - I would suspect that the algorithms, if not the implementation, are generally available.
I have done something similar to this with Lock by supplying my own implementation.
These days I use the actor model, so there is little need to lock the data (as I have almost no shared mutable data)
In case you didn't know, you can use the Java MX bean to detect deadlocked threads programmatically. This doesn't help you in testing but it will help you at least better detect and recover in production.
ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
long[] deadLockedThreadIds = threadMxBean.findMonitorDeadlockedThreads();
// log the condition or even interrupt threads if necessary
...
That way you can find some deadlocks, but never prove their absence. I'd better develop static checking tool, a kind of bytecode analizer, feeded with annotations for each synchronized method. Annotations should show the place of the annotated method in the resource graph. The task is then to find loops in the graph. Each loop means deadlock.
I'm wondering what good ways there would be make assertions about synchronization or something so that I could detect synchronization violations (while testing).
That would be used for example for the case that I'd have a class that is not thread-safe and that isn't going to be thread-safe. With some way I would have some assertion that would inform me (log or something) if some method(s) of it was called from multiple threads.
I'm longing for something similar that could be made for AWT dispatch thread with the following:
public static void checkDispatchThread() {
if(!SwingUtilities.isEventDispatchThread()) {
throw new RuntimeException("GUI change made outside AWT dispatch thread");
}
}
I'd only want something more general. The problem description isn't so clear but I hope somebody has some good approaches =)
You are looking for the holy grail, I think. AFAIK it doesn't exist, and Java is not a language that allows such an approach to be easily created.
"Java Concurrency in Practice" has a section on testing for threading problems. It draws special attention to how hard it is to do.
When an issue arises over threads in Java it is usually related to deadlock detection, more than just monitoring what Threads are accessing a synchronized section at the same time. JMX extension, added to JRE since 1.5, can help you detect those deadlocks. In fact we use JMX inside our own software to automatically detect deadlocks an trace where it was found.
Here is an example about how to use it.
IntelliJ IDEA has a lot of useful concurrency inspections. For example, it warns you when you are accessing the same object from both synchronised and unsynchronised contexts, when you are synchronising on non-final objects and more.
Likewise, FindBugs has many similar checks.
As well as #Fernando's mention of thread deadlocking, another problem with multiple threads is concurrent modifications and the problems it can cause.
One thing that Java does internally is that a collection class keeps a count of how many times it's been updated. And then an iterator checks that value on every .next() against what it was when the interator was created to see if the collection has been updated while you were iterating. I think that principle could be used more generally.
Try ConTest or Covertity
Both tools analyze the code to figure out which parts of the data might be shared between threads and then they instrument the code (add extra bytecode to the compiled classes) to check if it breaks when two threads try to change some data at the same time. The two threads are then run over and over again, each time starting them with a slightly different time offset to get many possible combinations of access patterns.
Also, check this question: Unit testing a multithreaded application?
You might be interested in an approach Peter Veentjer blogged about, which he calls The Concurrency Detector. I don't believe he has open-sourced this yet, but as he describes it the basic idea is to use AOP to instrument code that you're interested in profiling, and record which thread has touched which field. After that it's a matter of manually or automatically parsing the generated logs.
If you can identify thread unsafe classes, static analysis might be able to tell you whether they ever "escape" to become visible to multiple threads. Normally, programmers do this in their heads, but obviously they are prone to mistakes in this regard. A tool should be able to use a similar approach.
That said, from the use case you describe, it sounds like something as simple as remembering a thread and doing assertions on it might suffice for your needs.
class Foo {
private final Thread owner = Thread.currentThread();
void x() {
assert Thread.currentThread() == owner;
/* Implement method. */
}
}
The owner reference is still populated even when assertions are disabled, so it's not entirely "free". I also wouldn't want to clutter many of my classes with this boilerplate.
The Thread.holdsLock(Object) method may also be useful to you.
For the specific example you give, SwingLabs has some helper code to detect event thread violations and hangs. https://swinghelper.dev.java.net/
A while back, I worked with the JProbe java profiling tools. One of their tools (threadalyzer?) looked for thread sync violations. Looking at their web page, I don't see a tool by that name or quite what I remember. But you might want to take a look. http://www.quest.com/jprobe/performance-home.aspx
You can use Netbeans profiler or JConsole to check the threads status in depth