HAT History and Release Notes


First Version

HAT started in October or November of 1997, when I was on the HotJava team. I was looking into a suspected bug with unintentional object retention, and at staff I was basically whining about the tools that we had (e.g. println). John Pampuch piped up with, "Well, why don't you do something about it? You can program in C, and you have the JDK sources." For that, John gets a lot of credit for kick-starting HAT.

Here are parts of the first e-mail in my archive on the subject. Back then, the name "HAT" hadn't been invented yet; the file that it read was called a "bof" file, for "Binary Object File." We hadn't come up with the term "unintentional object retention;" at the time we were informally using the imprecise and inaccurate term "memory leak."

    Subject: Memory Leak Finding Tool
    Date: Mon, 10 Nov 1997 02:41:50 -0800 (PST)
    From: Bill Foote <billf@doppio>

    I've hacked together the oft-threatened preliminary version of a 
    memory-leak finding tool, based on JDK-pumpkin.  Despite it's hacky
    nature, it seems to work pretty well, and definitely gives essential
    information for debugging memory leaks.

    If you're curious about the code, I modified these JDK files:


    This makes it so that ^\ generates a dump file (dump1.bof, then dump2.bof, ...).

    The thing that reads these files and implements a simple HTTP server to
    let you browse the content is in ~billf/work/bofServer/

By mid-November, Sheng Liang on the VM team had seen what was now called "bodServer" (for "Binary Object Dump"). At the time, the experimental .hprof file for profiling data was being created. Based on the ideas in .bod, Sheng made the much better HPROF_HEAP_DUMP format within a .hprof file, and added support to the JDK 1.2 VM. That's when we started planning our JavaOne '98 talk on the subject.

Jeff Nisewanger in the JDK networking team made some important improvements that November. He cleaned up the HTML and HTTP support, and added the "new instances" query.

I guess one other e-mail from November merits quoting:

    Subject: Re: Core Dump for the 90's
    Date: Wed, 26 Nov 1997 12:26:14 -0800
    From: James Gosling <jag@eng.sun.com>
    Organization: Sun Microsystems
    To: Bill Foote <billf@doppio>

    Bill Foote wrote:
    > A couple of weekends ago, I came up with a cool hack I thought you
    > might like to see.  I've re-invented the core dump, by hacking code
    > into JDK-pumpkin to dump out the heap, complete with meta-information.
    > This dump (a .bod file, for "binary object dump") can be read by an
    > analysis tool that presents itself as an http server.

    Seriously cool.  I'd love to see it (or something like it) become real.

That December, Ann Sunhachawee on the HotJava team came up with the inspired name "HAT". Thank you, Ann!

JDK 1.2 and HotSpot

The .hprof file format worked beautifully in JDK 1.2, but it was an experimental feature that was a part of the experimental JVMPI (JVM Profiling Interface). It was also built around the structure of the VM at that time, which we now call the "classic VM." With the introduction of HotSpot, generating this kind of profiling information became more difficult. The result was that the experimental .hprof file generated by various versions of JDK 1.2 through 1.4 weren't always readable by HAT. I tried some to make the parser robust with different files, but HAT generally languished.

In September of 2004, I heard that a new profiling interface called JVMTI was a supported feature of JDK 1.5. The .hprof file format is still officially unsupported, but the agent that generates it is using a standard interface. Kelly O'Hair did all the hard work of writing that; when I fired up hat for the first time in years on a new .hprof file, it worked. Now that the supported JVMTI has supplanted the experimental JVMPI, HAT should work much more reliably. Thanks to Tom Ball, Alan Bateman and Janet Koenig for remembering about HAT after all this time!

Release Notes

HAT 1.1

HAT 1.0.5

HAT 1.0.4

HAT 1.0.3

HAT 1.0.2