Glenn Vanderburg

: Blog

5 of 5 articles
Ajaxian on Tamarin
Thu, 08 Feb 2007 (16:53) #
My friends at Ajaxian invited me along as a podcast guest again, and I’m so pleased with the result. Audible Ajax, Episode 20 focuses on Project Tamarin, the high-performance JavaScript VM donated by Adobe to the Mozilla project.

This episode is a bit of a change for the Ajaxians; rather than being an interview with one person or team, it’s a more formally produced analysis piece, with comments from several JavaScript and Ajax experts, only some of whom are really associated with the project. I lead off with a discussion about why current implementations of JavaScript are rather slow, but then Brendan Eich and Kevin Lynch (from and Adobe, respectively) talk about the project, along with Alex Russell and representatives from the IE team and Zimbra.

Ben and Dion are planning to use a similar format for upcoming episodes, and I’m thrilled—I think it works really well, providing a continuity and depth of analysis that you just don’t get from a single interview. Bravo, guys!

One Big Happy Family
Tue, 10 Jun 2003 (19:52) #
(via my blog)

I remember being at JavaOne in 1999 (I think) when I first heard the terms "J2SE", "J2EE", and "J2ME". I understood the reasoning for such a move, but at the same time I hoped they wouldn't go too far with the distinction.

It was both amusing and refreshing to hear Jonathan Schwartz acknowledge in this morning's keynote that Sun has been guilty of pushing multiple, separate platforms rather than emphasizing Java as a single platform. He promised that they would do better.

Of course, they aren't in a full retreat from the multiple editions, and such a retreat wouldn't make sense anyway. There are real distinctions between those environments, and the facilities available on them need to reflect that. But I do hope they spend more time focusing on what all the editions have in common.

Unfortunately, for those of us who like to stay informed about what's coming in future releases, it's necessary to pick an edition. This afternoon at 3:30, the "Overview and Roadmap" sessions for J2SE and J2EE are scheduled opposite one another.

Long overdue ...
Tue, 10 Jun 2003 (19:52) #

Sun's finally ready to really support a free and open community of Java developers in a real way (or so it seems. Check out

Java 1.4.1 for OS X, and the first bug
Wed, 12 Mar 2003 (12:29) #
While I was downloading 1.4.1 yesterday, Greg Vaughn was reading the release notes and IMing me about them:
Known issues: no incremental gc :-(

What about concurrent?

It doesn't say

That's OK, really ... incremental GC had serious problems in 1.3, and they weren't fixed for 1.4; instead, nearly all of the GC work went into the concurrent collector, which arrived with Sun's 1.4.1.

But I started wondering about the concurrent collector. It occurred to me that I could probably tell whether the concurrent collector was included by turning on verbose GC output and watching.

First, I ran the SwingSet2 demo with the default collector. I saw what I expected: lots of young generation collections, with full heap collections occurring just under 10% of the time. Then I tried -Xincgc, and saw the same behavior; the release notes were telling the truth about the incremental collector.

With the -Xconcgc option, I saw very different behavior. In some cases I've seen up to 500 young collections before any attempt is made at a full sweep. Looks like the concurrent collector is there.

But there's a race condition. On 3 out of 4 runs, roughly, when it did finally attempt a full GC, I saw this:

[GC 14014K->14001K(58108K), 0.0069902 secs]
[GC 13975K->13975K(58944K), 0.0093674 secs]
[Full GC[Unloading class sun.reflect.GeneratedMethodAccessor4]
[Unloading class sun.reflect.GeneratedMethodAccessor3]
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# Java VM: Java HotSpot(TM) Client VM (1.4.1_01-14 mixed mode)
# ShouldNotReachHere()
# Error happened during: generation collection for allocation
# Error ID: /SourceCache/HotSpot14/HotSpot14-14/src/share/vm/memory/generation.hpp, 346
# Problematic Thread: prio=3 tid=0x0fd9ecf0 nid=0xedc8c70 waiting on condition
Abort trap

A weird Java2D bug under OSX
Mon, 14 Oct 2002 (18:58) #
Java2D circle bugLast week I was playing with my toy line drawing editor again, and I noticed a very strange bug in the Java 2D graphics support under MacOS X. I wrote a tool to draw ovals, and it worked great. Then I wrote a tool to draw circles; it was just a subclass of the oval tool that constrained the vertical and horizontal axes to be the same dimension. It worked great, too, but I noticed that all my ovals (and other shapes, for that matter) were nicely antialiased, and all of the circles were jaggy.

At first I thought I'd done something wrong, but the circle tool doesn't change any of the drawing code from the oval tool.

It turns out that if you draw a circle using Java2D under MacOS X (at least using Java 1.3.1 under Jaguar) it does not do antialiasing at all. If you choose the oval tool and start sweeping out the bounding box, you can see it suddenly switch to jaggy pixels as the dimensions become completely circular, and then back to antialiased mode as you keep going. In the picture, both shapes were drawn with the oval tool; the only difference is that the one on the left has a square bounding box.

It doesn't happen with Java on other platforms, or with Cocoa. My theory: there's an optimization path in the Carbon port of Java2D. When it notices that it's drawing a true circle, that optimization path kicks in, and there's a bug so that it loses the quality hints.