Skip to main content

Update to the Allocation Instrumenter

A couple of years ago, I open-sourced a tool that lets you instrument all of the allocations in your Java program. Some quick updates today:
  1. It now supports JDK7.
  2. You can now optionally use it to instrument constructors of a particular type, instead of allocations. So, if you wanted to find out where your Threads were being instantiated, you could instrument them with a callback that invokes Thread.dumpStack().

I know that most of the readers of this blog are more interested in concurrency, and that it has been a very, very long time since I posted. The spirit is willing, but the flesh is insanely busy... I have it in mind to do a post that discusses a bunch of strategies for doing efficient non-blocking concurrency in C++, because the attempts are very amusing, but I haven't had the chance to sit down and do it.
Labels:

Comments

Vladimir Dolzhenko said…
I do really like that instrumenter - I've made garbage-free logger and prove using it that it's really garbage-free.

It's very specific for latency critical execution path only and it's definitely not a general purpose logger as log4j or so.

( going to release it under apache license soon )
February 7, 2012 at 4:39 AM
Anonymous said…
Welcome back Jeremy!

It would be great if you write a few blogposts on effective use of java collections. I saw that you were able to use them effectively to improve performance , scalability in a google paper about scala/c++/java

Vignesh
February 8, 2012 at 1:36 AM
Jeremy Manson said…
@Vladimir: Glad it helps. I've used it to track down excess garbage in our applications, too. I've since replaced it with something that would be difficult to open-source right now, but it is still pretty useful.

@Vignesh: I'm probably not as back as I would like. My life is getting busier, rather than less busy, and there are complications that prevent me from posting everything I might like right now.

Having said that, I did talk about the Scala paper here:

http://jeremymanson.blogspot.com/2011/06/scala-java-shootout.html
February 8, 2012 at 8:19 AM
Jeremy Manson said…
Cool! Glad it could be of help.
April 15, 2012 at 12:18 AM
mchr said…
I just came across this post and thought you might be interested to know about a similar tool which I wrote to track object allocation and object lifetimes: http://mchr3k.github.com/org.inmemprofiler/
November 29, 2012 at 3:16 AM
Post a Comment

Popular posts from this blog

Double Checked Locking

I still get a lot of questions about whether double-checked locking works in Java, and I should probably post something to clear it up. And I'll plug Josh Bloch's new book, too. Double Checked Locking is this idiom: // Broken -- Do Not Use! class Foo {   private Helper helper = null;   public Helper getHelper() {     if (helper == null) {       synchronized(this) {         if (helper == null) {           helper = new Helper();         }       }     }   return helper; } The point of this code is to avoid synchronization when the object has already been constructed. This code doesn't work in Java. The basic principle is that compiler transformations (this includes the JIT, which is the optimizer that the JVM uses) can change the code around so that the code in the Helper constructor occurs after the write to the helper variable. If it does this, then after the constructing thread writes to helper, but before it actually finishes constructing the object,
107 comments
Read more

What Volatile Means in Java

Today, I'm going to talk about what volatile means in Java. I've sort-of covered this in other posts, such as my posting on the ++ operator , my post on double-checked locking and the like, but I've never really addressed it directly. First, you have to understand a little something about the Java memory model. I've struggled a bit over the years to explain it briefly and well. As of today, the best way I can think of to describe it is if you imagine it this way: Each thread in Java takes place in a separate memory space (this is clearly untrue, so bear with me on this one). You need to use special mechanisms to guarantee that communication happens between these threads, as you would on a message passing system. Memory writes that happen in one thread can "leak through" and be seen by another thread, but this is by no means guaranteed. Without explicit communication, you can't guarantee which writes get seen by other threads, or even the order in whic
176 comments
Read more

Date-Race-Ful Lazy Initialization for Performance

I was asked a question about benign data races in Java this week, so I thought I would take the opportunity to discuss one of the (only) approved patterns for benign races. So, at the risk of encouraging bad behavior (don't use data races in your code!), I will discuss the canonical example of "benign races for performance improvement". Also, I'll put in another plug for Josh Bloch's new revision of Effective Java (lgt amazon) , which I continue to recommend. As a reminder, basically, a data race is when you have one (or more) writes, and potentially some reads; they are all to the same memory location; they can happen at the same time; and that there is nothing in the program to prevent it. This is different from a race condition , which is when you just don't know the order in which two actions are going to occur. I've put more discussion of what a data race actually is at the bottom of this post. A lot of people think that it is okay to have a data
53 comments
Read more