X hits on this document

PDF document

Program Transformations for Light-Weight CPU Accounting and Control in the Java Virtual Machine A ... - page 11 / 40





11 / 40


classes of JVM bytecode instructions varies significantly. This al- lows to calibrate the accounting for a particular JVM, which enables a better modeling of the effective CPU load on the given JVM.

3.3. Refining getCurrentAccount()

The functionality of the getCurrentAccount() method is to return the ThreadCPUAccount associated with the currently executing thread. To this end, getCurrentAccount() first obtains a reference to the thread via the standard Thread.currentThread() method. Then, using this reference, it could obtain the associated CPU account through a hash table.5 This is however a costly solution, since it has to occur at each method entry of the rewritten application. A far more efficient ap- proach taken here is to patch the real Thread class and add the needed reference directly to its set of instance fields.6

The required functionality of getCurrentAccount() is unfortu- nately hard to implement during the bootstrapping of the JVM. During this short, but crucial period, there is an initial phase where Thread.currentThread() pretends that no thread is executing and re- turns the value null (this is in fact because the Thread class has not yet been asked by the JVM to create its first instance). As a consequence, in all code susceptible to execution during bootstrapping (i.e., in the JDK, as opposed to application code) we have to make an additional check whether the current thread is undefined; for those cases, we have to provide a dummy, empty ThreadCPUAccount instance, the role of which is to prevent all references to the consumption variable in the rewritten JDK from generating a NullPointerException. This special functionality is provided by the jdkGetCurrentAccount() method, which replaces the normal getCurrentAccount() whenever we rewrite JDK classes.

As this article focuses on the optimization of bytecode transforma- tion schemes, we will not discuss further the issues related to rewriting the JDK. Interested readers can find more information on this subject in [3].

5 Using the predefined ThreadLocal class of Java also amounts to searching in hash tables.

6 We investigated also another approach, which was to make the standard Thread class inherit from a special class provided by us, and thus receive the required additional field by inheritance. This elegant alternative, however, does not conform to the Java API, which stipulates that Thread is a direct subclass of Object.

Document info
Document views66
Page views66
Page last viewedTue Oct 25 07:27:23 UTC 2016