Java Concurrency (&c)

Cliff Click gave a very good talk at Google last week. For your viewing enjoyment: The slides are available here . (For those who watched it: The inventors of bytecode were in the audience. I think he was just used to making that joke elsewhere.)

This is a followon to a blog post I made in 2007 about using signal handling to profile Java apps . I mentioned in another post why this might be a good idea , but I wanted to expand on the theme. Hiroshi Yamauchi and I are giving a talk at this year's JavaOne . Part of this talk will be about our experiences writing profilers at Google, and in preparing for it, I realized my previous entry on this subject only told half the story. The topic of the original post is that there is an undocumented JVMTI call in OpenJDK that allows you to get a stack trace from a running thread, regardless of the state of that thread. In Unix-like systems, you can use a SIGPROF signal to call this function at (semi-)regular intervals, without having to do anything to your code. The followon post, intended to describe why you would use this, described a couple of things that are true: That it tells you what is actually running on your CPU, not just what might be scheduled, which is what profilers ...

In which I ramble on at greater length about finalizers and multithreading, as well as applying that discussion to SoftReferences . Read Part 1 first . It explains why finalizers are more multithreaded than you think, and why they, like all multithreaded code, aren't necessarily going to do what you think they should do. I mentioned in the last entry that a co-worker asked me a question about when objects are allowed to be collected. My questioner had been arguing with his colleagues about the following example: Object f() { Object o = new Object(); SoftReference<Object> ref = new SoftReference<Object>(o); return ref.get(); } He wanted to know whether f() was guaranteed to return o , or whether the new Object could be collected before f() returned. The principle he was operating under was that because the object reference was still on the stack, the object would not be collected. Those of you who read the last entry will know better, of course. To put it in...

Cliff Click has a terrific post on Java-vs-native-code performance . Recommended. Cliff is the Chief JVM Architect at Azul Systems, was the lead designer behind Hotspot's server JIT compiler, and is an all-around smart guy. His main drawback is that he (apparently) gets dragged into flamewars on YouTube's comment section.

I got asked about this twice in one day, and I didn't know the answer, so I sat down and puzzled it out a bit. A SoftReference is a reference that the garbage collector can decide to clear if it is the only reference left to an object, and the GC decides (through some undefined process) that there is enough memory pressure to warrant clearing it. SoftReferences are generally used to implement memory-sensitive caches. A mistake many people make is to confuse it with a WeakReference , which is a reference that, if it is the only reference left to the object, the garbage collector will aggressively clear. I got asked how Hotspot's GC actually decides whether to clear SoftReferences. Twice. On the same day. (Hotspot is the Sun / OpenJDK JVM). The answer was that I had no idea, so I had to go look it up. Here is what I found out; I hope it is a useful reference for someone (pun intended). First, there is a global clock variable that is set with the current time (in millis)...

This is a follow up from my previous post about profiling with SIGPROF and JVMTI . There are, in fact, a very large number of ways of getting stack traces out of a JVM. If you send a system-dependent signal to your JVM process, it will spit out a stack dump of every currently live thread. On Solaris and Linux, the signal is a SIGQUIT, which you can get by using kill -3 on the JVM PID (or the PID of the parent JVM process under Linux 2.4), or hitting Control-\. On Windows, you can achieve the same effect by hitting Ctrl-Break on Windows. If you call Thread.dumpStack() , or create a new Throwable , and invoke getStackTrace() on it, you can get the current stack trace programmatically. If you use ThreadMXBean 's getThreadInfo methods, you can get stack traces out of any threads you want. If you use JVMTI 's GetStackTrace or GetAllStackTraces methods, you can get stack trace information in native code. Most of these methods will tell you if your thread can be scheduled by...

This post is not about the memory model, but, instead, is about being able to get, asynchronously, the stack trace of a currently executing thread out of Sun's Java VM. Getting one synchronously is easy, of course. I was trying to profile some Java applications under Linux, and I wanted to use SIGPROF and JVMTI to find out what code was running at any given second. This is just a posting to document how I did it, as I ended up using some undocumented JVM features, and I can't find a proper reference for them anywhere else. More information as to why you might want to do this is here . JVMTI is the Java Virtual Machine Toolkit Interface. It's a C/C++ interface to the virtual machine that allows you to hook in debuggers and profilers. More information can be found here . SIGPROF is a POSIX signal. The way it is set up under Linux is that you can set a timer that goes off at intervals, and, whenever the timer expires, the SIGPROF signal is sent to the application. The ...