Selective Ahead of Time Compilation using Annotations

Question

I'm writing a music composition application.
Only once compiled by the JIT, does code run at the speed I need to playback and highlight notes as they are played. That is, rendering takes 3 ms and painting takes 1ms. The first few dozen iterations, rendering takes 22 ms and painting 6 ms.
Interesting, the Hotspot VM has the JVMSPI_IsPrecompilationTarget available for embedded systems.
Why can't SUN create an annotation to precompile, Ahead-of-Time (AOT), certain methods and all the code called up its object chain? It could be done after class loading and before execution or, an alternate annotation could request that the VM run a low priority thread to compile it. Perhaps with a order priority number. For my application, users often edit scores while CPU cycles sit idle. Ideally, developpers could interact programmatically, receiving a listener event when compilation is done. For my app, if a user presses play and compilation isn't done, the developper could inform the user "preparing for play" and increase the thread priority or at least wait for the "compilation done" event before proceeding. I don't know why SUN hasn't added this to the Java language and VM reference implementation yet. It would make GCJ and Excelsior JET redundant.
The garbage collector is very well behaved at its low priority and because I use pools of permanent objects, reuse as much as possible. ( http://java.sys-con.com/read/37613.htm )
-XX:CompileThreshold=# is useless to me.
Unfortunately, Sun's Java Real Time environment is not available for Mac OS X.

Answer 1

connections. The VM code (text) is loaded only once in
mem by the OS. So would the precompiled classes,
instead of going into the heap of every VM or
something.Code implemented as native methods will also be in a shared library and will be shared among all VM instances that use that particular shared library implementation. Lots of the classes in the Java 2 Platform already have some/most/all of their implementation in the form of native methods.
There's no real concept of shared objects for class files, though. In fact a class file, once compiled to machine code by the JIT, may not even result in the same machine code in more than one running VM. The VM needs to work with bytecode for class definitions in order to support class loaders, serialization, JIT compilation, class verification, and maybe other things too.
I don't think the memory savings would really be that much. Java bytecode is pretty compact and classes are only loaded on-demand anyway.