− Full portability. J-RAF2 is implemented in pure Java and all transformations follow a strict adherence to the specification of the Java language and virtual machine. It has been tested with several standard JVMs in different environments, including also the Java 2 Micro Edition .
− Platform-independent unit of accounting. A time-based measure- ment unit makes it hard to establish a contract concerning the resource usage between a client and a server, as the client does not exactly know how much workload can be completed within a given resource limit, since this depends on the hardware character- istics of the server. In contrast, the number of executed bytecode instructions is independent of system properties of the server environment.
− Flexible accounting/controlling strategies. J-RAF2 allows custom implementations of the CPUManager interface.
− Fine-grained control of scheduling granularity. The accounting de- lay can be adjusted within the constraints specified in Section 3.5: the CPUManager is allowed to dynamically adapt the granularity of each thread between the bounds defined by Integer.MAX VALUE and the MAXP AT H value chosen at rewrite time.
− Independence of JVM thread scheduling. The present CPU ac- counting scheme of J-RAF2 does not make any assumptions concerning the scheduling of threads. E.g., in contrast to other approaches to CPU management [7, 14], J-RAF2 does not rely on a dedicated supervisor thread running at the highest priority level.
− Moderate overhead. We have shown that our CPU accounting ap- proach results in moderate overhead. Whereas we have focussed on designing optimization algorithms that are specific to this bytecode rewriting scheme, it is also possible to apply prior general-purpose transformations to further increase the performance, such as loop unrolling, inlining or parallelization techniques, using a bytecode– to–bytecode optimization framework like Soot. We have also tried to target optimizations that promise a broad usability, i.e. that bring benefits on a large number of JVMs, and that do not result in excessive increase of code size.