with current aspect languages. Therefore, from a technical point of view, a tool with the same bytecode manipulation capabilities as ours is required. We are considering defining an aspect-oriented language in order to factor out the parameters of the rewriting process, and make our current tool more user-friendly. This lan- guage would enable the developer to more conveniently define the sites where accounting is needed and what actions should be taken there. We are aware of no prior work on aspect languages for CPU management, and resource management in general.
Whereas our bytecode transformations are currently implemented as a distinct tool, there are also other deployment opportunities, depend- ing on the needs of the envisaged application. The JDK 1.5.0 platform introduced services that allow Java agents to instrument programs running on the JVM. Such Java agents exploit the instrumentation API (package java.lang.instrument) to let users install bytecode transformations that are integrated with the JVM instead of being provided by a separate tool. Java agents are invoked after the JVM has been initialized, but before the real application. They are even allowed to redefine already loaded system classes.
However, JDK 1.5.0 imposes several restrictions on the transforma- tion of previously loaded classes. For instance, new fields or methods cannot be added, and method signatures cannot be changed. Therefore it is not compatible with our most advanced transformations. Nonethe- less, if all JDK classes are rewritten according to the Simple scheme, where each method obtains the ThreadCPUAccount instance of the calling thread upon method entry, our bytecode transformations can be packaged as a standard Java agent for JDK 1.5.0. This approach also requires that the transformations themselves do not take too long, as the rewriting would be done on the fly. As an indication, a rewriting of the 2443 classes of IBM JDK 1.4.2 with the Simple scheme takes 40 seconds on our benchmarking machine.
Our previous work on J-RAF2 has shown that we can account for other basic resources, such as heap memory  and network band- width , within a single homogeneous conceptual and technical framework. More research is needed to advance the management of these resources to the same level of maturity as the CPU. However, from the perspective of studying program transformations, they are not quite as challenging, since the corresponding consumption sites are easy to locate in the bytecode and can therefore be essentially handled with wrapper techniques, and they are less critical – again purely from a program transformation point of view – because they are consumed at a slower pace than the CPU.