• On the Jimple, Grimp and Baf level, invokedynamic instructions appear as DynamicInvokeExpr with a static SootMethodRef that has class java.dyn.InvokeDynamic as target class. This is in accordance with the internal handling in JDK 7.
• SootMethodRefs which have java.dyn.InvokeDynamic as target class may not be resolved: calling resolve() will throw an exception
• On the Jasmin level, invokedynamic instruction appear in the form “invokedynamic <methodName>(<methodParams>)<methodRetType>“. In particular, there is no target class given.
• Jasmin translates this into an invokedynamic instruction with two arguments:
  • a NameAndType attribute referring to <methodName>(<methodParams>)<methodRetType> and
  • the constant “0″ (two zero bytes, i.e., a short); according to the VM spec this is reserved for future use.

The above is an experimental design. Comments are welcome! In the near future we plan to extend TamiFlex to handle invokedynamic as well.

Abstract: Researchers have developed a number of runtime verification tools that generate runtime monitors in the form of AspectJ aspects. In this work, we present Clara, a novel framework to statically optimize such monitoring aspects with respect to a given program under test. Clara uses a sequence of increasingly precise static analyses to automatically convert a monitoring aspect into a residual runtime monitor. The residual monitor only watches events triggered by program locations that the analyses failed to prove safe at compile time. In two-thirds of the cases in our experiments, the static analysis succeeds on all locations, proving that the program fulfills the stated properties, and completely obviating the need for runtime monitoring. In the remaining cases, the residual runtime monitor is usually much more efficient than a full monitor, yet still captures all property violations at runtime.

Dear all, for all of those of you who happened to be in Chile in November: I will be giving a lecture about the latest techniques in analyzing Java programs with Soot at the 3rd Summer School on Programming Languages, which is co-located with the Chilean Computing Week. You can find more information here. At the same even, I will moreover be giving a hands-on tutorial on Clara (“Partially evaluating finite-state runtime monitors ahead-of-time”), which is likely going to be similar to my RV tutorial.

Toronto promises to be an exciting venue and our excellent program committee will certainly do its best to provide an great program. However, a conference is nothing without strong research papers! You are invited to submit technical papers describing original research in testing or analysis of computer software. Papers describing theoretical or empirical research, new techniques, or in-depth case studies of testing and analysis methods and tools are welcome.

You can download the full call for papers on the right. Workshop proposals are due Friday, November 19, 2011 and research papers on Friday, February 4, 2011.

Finally, if you wish to promote ISSTA yourself, you can download a web banner here.

The NASA Formal Methods Symposium is a forum for theoreticians and practitioners from academia, government and industry, with the goals of identifying challenges and providing solutions to achieving assurance in mission- and safety-critical systems. The focus of the symposium is on formal methods, and aims to foster collaboration between NASA researchers and engineers and the wider aerospace and academic formal methods communities. The symposium will be comprised of a mixture of invited talks by leading researchers and practitioners, presentation of accepted papers, and panels.

Important Dates

Submission deadline: December 19, 2010
Notification of acceptance/rejection: January 21, 2011
Final version due: February 18, 2011
Conference: April 18-20, 2011

Topics of Interest

• Theorem proving
• Model checking
• Real-time, hybrid, stochastic systems
• SAT and SMT solvers
• Symbolic execution
• Abstraction
• Compositional verification
• Program refinement
• Static analysis
• Dynamic analysis
• Automated testing
• Model-based testing
• Model-based development
• Fault protection
• Security and intrusion detection
• Application experiences
• Modeling and specification formalisms
• Requirements specification and analysis

Abstract: A software product line is a family of programs where each program is defined by a unique combination of features. Product lines, like conventional programs, can be checked for safety properties through execution monitoring. However, because a product line induces a number of programs that is potentially exponential in the number of features, it would be very expensive to use existing monitoring techniques: one would have to apply those techniques to every single program. Doing so would also be wasteful because many programs can provably never violate the stated property. We introduce a monitoring technique dedicated to product lines that, given a safety property, statically determines the feature combinations that cannot possibly violate the property, thus reducing the number of programs to monitor. Experiments show that our technique is effective, particularly for safety properties that crosscut many optional features.

Download the paper here.