You will get numbers that are unrealistically good. You are allocating objects that need no initialization and dropping them on the floor instantly. Real programs do allocate a fair number of short-lived temporary objects, but they also hold on to some objects for longer than this simple test program. The HotSpot storage manager does more work for the objects that are retained for longer, so beware of trying to scale up numbers from tests like this to real systems. I've tried it on HotSpot and it doesn't seem to perform much better than the Java 2 SDK, and only slightly better than on JDK1.1.x implementations.
Graphics programs spend a lot of their time in native libraries.
The speed of the underlying hardware and operating system HotSpot is a replacement for the Java 2 SDK virtual machine. The virtual machine is responsible for byte code execution, storage allocation, thread synchronization, etc. Running with the virtual machine are native code libraries that handle input and output through the operating system, especially graphics operations through the window system. The HotSpot virtual machine uses the same native code libraries that the Java 2 SDK uses, so programs that spend significant portions of their time in those native code libraries will not see their performance on HotSpot improved as much as programs that spend most of their time executing byte codes. In addition, HotSpot is a Java 2 virtual machine, and so graphics operations go through the new Java2D APIs.