Java Concurrency (&c)

Because I am a Google employee, my talks are not happening . Apologies to any interested parties. I'm going to try to give the talks in another venue, or at least to use the blog as a venue for some of the topics I wanted to cover.

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

A little while ago, I got asked a question about when an object is allowed to be collected. It turns out that objects can be collected sooner than you think. In this entry, I'll talk a little about that. When we were formulating the memory model, this question came up with finalizers. Finalizers run in separate threads (usually they run in a dedicated finalizer thread). As a result, we had to worry about memory model effects. The basic question we had to answer was, what writes are the finalizers guaranteed to see? (If that doesn't sound like an interesting question, you should either go read my blog entry on volatiles or admit to yourself that this is not a blog in which you have much interest). Let's start with a mini-puzzler. A brief digression: I'm calling it a mini-puzzler because in general, for puzzlers, if you actually run them, you will get weird behavior. In this case, you probably won't see the weird behavior. But the weird behavior is perfectl

I recently got a note on another blog post asking this question: I have a general question on the thread safety and this is not directly related with your blog. I would appreciate if you could post it on your blog. I have a class that has only one static method that accepts two string parameters and does some operation locally (as shown below). Do I need to synchronize this method? public class A {   public static boolean getDate(String str, String str2){     SimpleDateFormat formatter =       new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");     boolean isBefore = false;     Date date1;     Date date2;     try {       date1 = formatter.parse(str);       date2 = formatter.parse(str);       isBefore = date1.after(date2);     } catch (Exception e) {       e.getMessage();     }     return isBefore;   } } Since it had nothing to do with the blog post in question, I'll answer it here. The questioner is clearly asking about the well-documented lack of thread safety of the Format