Browse Prior Art Database

Dataflow optimization to remove redundant guards in cooperatively multithreaded code

IP.com Disclosure Number: IPCOM000200609D
Publication Date: 2010-Oct-20
Document File: 3 page(s) / 33K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a bitvector dataflow analysis combined with a code transformation to detect and eliminate redundant Hot Code Replacement (HCR) guards. The key observation is that with cooperative multitasking, in the absence of a yield point, HCR cannot occur, so there is no need to check for it. Therefore, if there are two consecutive (nested) HCR guards with no intervening yield point, the second (inner) guard is redundant and can be eliminated. Interestingly, this approach uses dataflow analysis to analyze the effects of asynchronous events outside the control of the code being analyzed--a domain where one would not expect dataflow analysis to apply.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 01 of 3

Dataflow optimization to remove redundant guards in cooperatively multithreaded code

Disclosed is a process for a bit-vector dataflow analysis combined with a code transformation to detect and eliminate redundant hot code replacement (HCR) guards. In cooperative multitasking, and an absence of a yield point, HCR cannot occur, therefore there is no need to check for HCR. Accordingly when there are two consecutive (nested) HCR guards without an intervening yield point, the second (inner) HCR guard is redundant and can be eliminated. The disclosed process uses dataflow analysis to analyze effects of asynchronous events outside control of the code being analyzed, which is a domain where one would not expect dataflow analysis to apply.

Hot code replacement (HCR) is a feature offered by the Java® Virtual Machine (JVM)1 that allows a user to re-define classes dynamically. The user attaches an agent to a JVM (usually on startup), and the agent issues requests to the JVM specifying which classes should be modified and in what manner.

To operate safely in a multithreaded environment, HCR first causes the JVM to enter a mode in which threads suspend themselves until a quiescent state is reached. After modifying desired classes, threads are allowed to resume. The current approach is similar to a stop the world technique used by a garbage collector during portions of garbage collection that would be hard to perform while application threads are running.

Thread suspension may be preemptive or cooperative. In preemptive suspension, the thread simply pauses between any two instructions. In cooperative suspension, the thread occasionally checks whether it should suspend itself. The disclosed process operates in an environment using cooperative suspension.

Java threads must occasionally execute yield points; they must not run indefinitely, thereby preventing necessary activities like garbage collection (GC) and HCR from occurring. In particular, compiled code must contain yield points. A compiler must insert sufficient yield points to ensure no compiled code can run indefinitely without encountering a yield point. Typically, explicit yield points are inserted in every method prologue and inside every loop, thereby preventing code from repeating indefinitely via recursion or iteration (respectively). Furthermore, because yield points are associated with garbage collection, all object allocations are also necessarily considered implicit yield points and because method prologues contain yield points, every method call is also an implicit yield point. Depending on a JVM, there may be further additional yield points. Together, these explicit and implicit yield points ensure that a stop the world event always occurs in a timely fashion.

In the cooperative suspension model, each application thread is exposed to effects of HCR only at yield

p

 oints, whether the yield points are explicit or implicit. When HCR causes a class to be modified, existing compil...