Method Inlining, Dynamic Class Loading, and Type Soundness.

Abstract

Method inlining is an optimisation that can be invalidated by later class loading. A program analysis based on the current loaded classes might determine that a method call has a unique target, but later class loading could add targets. If a compiler speculatively inlines methods based on current information, then it will have to undo the inlining when later classes invalidate the assumptions. The problem with undoing inlining is that the optimised code might be executing at the time of undo and therefore require a complicated, on-the-fly update of the program state. Previous work presented techniques for dealing with invalidation including on-stack replacement, preexistence analysis, extant analysis, and code patching. Until now, it has been an open question whether such operations can be done in a type-safe manner, and no formal proof of correctness exists in the literature. In this paper we present a framework for reasoning about method inlining, dynamic class loading, and type soundness. Our example language has both a nonoptimising and an optimising semantics. At the point of dynamically loading a class, the optimising semantics does a whole-program analysis, inlines calls in the newly loaded code, and patches the invalidated inlinings in all previously loaded code. The patching is based on a new construct that models in-place update of machine code-a technique used by some virtual machines to do speculative method inlining. The two semantics are equivalent and both have a type soundness property-proving correctness and type safety of the optimisation. Our framework can form the basis of virtual machines that represent optimised code in a typed low-level language.

Type-safe method inlining

“…How effective this might be is beyond the scope of this paper. More recent work [11] has extended our ideas to a dynamic class loading environment with a just-in-time compiler. Note also that our flow analyses are context insensitive and we leave context-sensitive flow analyses to future work.…”

JShrink: in-depth investigation into debloating modern Java applications

“…The former ensures that JShrink does not introduce code duplication during inlining, while the latter is crucial for semantic preservation in case of polymorphism. Type safety of method inlining is widely discussed in the compiler literature [24,25]. To ensure type safety, JShrink applies three constraints.…”

World age in Julia: optimizing method dispatch in the presence of eval

“…Further research looked at performing dependency analysis to identify which methods are affected by the newly added definitions, to be then recompiled on demand [Nguyen and Xue 2005]. Glew [2005] describes a type-safe means of inlining and devirtualization: when newly loaded code is reachable from previously optimized code, these optimizations must be rechecked.…”

“…For example, Politz et al [2012] described the ECMAScript 5.1 semantics for eval, among other features. Glew [2005] formalized dynamic class loading in the framework of Featherweight Java, and Matthews and Findler [2008] developed a calculus for eval in Scheme. These works formalize the semantics of dynamically modifiable code in their respective languages, but, unlike Julia, the languages formalized do not have features explicitly designed to support efficient implementation.…”