Type-safe method inlining

Glew, Neal; Palsberg, Jens

doi:10.1016/j.scico.2004.03.009

Cited by 6 publications

(9 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…First of all, as already described, the flow analysis used during class loading and JIT compilation is CHA. As demonstrated by Glew and Palsberg [7], CHA is the simplest flow analysis which supports typesafe method inlining in a setting without class loading. Moreover, CHA is fast and therefore an attractive choice for a JIT compiler.…”

Section: Our Resultsmentioning

confidence: 99%

“…Our own previous work [7] shows how traditional whole program devirtualisation techniques can be done in a typeability preserving manner without sacrificing performance. Our paper and other work in this area (see [7] for references) has addressed only whole program analysis and optimisation-it does not address dynamic class loading.…”

Section: Type Preservationmentioning

confidence: 99%

“…The language and its presentation follow the original FJ paper as closely as possible, and is modeled after our previous paper on type-safe method inlining [7]. In this extended abstract, we limit the informal explanations to static dispatch, dynamic class loading, and dynamic patching.…”

Section: The Languagementioning

confidence: 99%

“…The semantics is the same as for FJ and our previous paper [7], except for the two new constructs and labels on the reduction relation. A reduction is optionally labeled with a class definition and list of field initialiser expressions.…”

Section: Standard Operational Semanticsmentioning

confidence: 99%

See 3 more Smart Citations

Method Inlining, Dynamic Class Loading, and Type Soundness.

Glew

Palsberg

2005

JOT

Self Cite

View full text Add to dashboard Cite

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.

show abstract

Section: Our Resultsmentioning

confidence: 99%

Section: Type Preservationmentioning

confidence: 99%

Section: The Languagementioning

confidence: 99%

Section: Standard Operational Semanticsmentioning

confidence: 99%

See 2 more Smart Citations

Method Inlining, Dynamic Class Loading, and Type Soundness.

Glew

Palsberg

2005

JOT

Self Cite

View full text Add to dashboard Cite

show abstract

“…Moreover, a declaration of a method with the same signature as M must occur in a supertype of the type of E. This latter fact is expressed in rule (4) using Definition 2 by way of an or-constraint. For cast expressions of the form (C)E, rule (21) defines the type of the cast to be C. Moreover, rule (12) states the requirement that the type of E must be a supertype of C 12 . Rules (18)- (22) define the types of variables, parameters, fields, method return types, casts, and allocation sites in the original program.…”

Section: Inferring Type Constraintsmentioning

confidence: 99%

Customization of Java Library Classes Using Type Constraints and Profile Information

Sutter

Tip

Dolby

2004

ECOOP 2004 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. The use of class libraries increases programmer productivity by allowing programmers to focus on the functionality unique to their application. However, library classes are generally designed with some typical usage pattern in mind, and performance may be suboptimal if the actual usage differs. We present an approach for rewriting applications to use customized versions of library classes that are generated using a combination of static analysis and profile information. Type constraints are used to determine where customized classes may be used, and profile information is used to determine where customization is likely to be profitable. We applied this approach to a number of Java applications by customizing various standard container classes and the omnipresent StringBuffer class, and measured speedups up to 78% and memory footprint reductions up to 46%. The increase in application size due to the added custom classes is limited to 12% for all but the smallest programs.

show abstract

Efficient compilation strategy for object‐oriented languages under the closed‐world assumption

Sonntag

Colnet

2012

Softw Pract Exp

View full text Add to dashboard Cite

SUMMARYReaching the best level of runtime performance from a high‐level, object‐oriented language is often considered challenging if not unattainable. The closed‐world assumption involves considering all of the source code of an application together at compile time. That assumption makes it possible to produce an efficient code. For instance, multiple inheritance can be implemented as efficiently as single inheritance. Our compilation strategy is the result of a prolonged project, tying together several compilation techniques: call graph analysis, dead code elimination, type flow analysis, code customization, implementation of dynamic dispatch, inlining, pointer optimization, switch optimization, objects layout, and so on. Merging all of these techniques into a global strategy appears to be quite problematic. Throughout the paper, two real‐world compilers are used as benchmarks to provide measurements for compiler writers to evaluate the applicability of our approach. Type flow analysis is a fundamental aspect of our strategy to resolve method calls. We have extended type flow analysis to deal with the content of arrays, enabling us to process additional expressions and thus making it possible to obtain a true global analysis. Typically, more than 90% of method call sites are statically resolved. Our experience indicates that the closed‐world assumption is suitable for numerous applications. Surprisingly, even library‐defined control statements from dynamic languages are perfectly processed with our strategy. The Smalltalk ifTrue:ifFalse:, whileTrue:, to:do:, and so on are, for the very first time, perfectly translated. Copyright © 2012 John Wiley & Sons, Ltd.

show abstract

Type-safe method inlining

Cited by 6 publications

References 29 publications

Method Inlining, Dynamic Class Loading, and Type Soundness.

Method Inlining, Dynamic Class Loading, and Type Soundness.

Customization of Java Library Classes Using Type Constraints and Profile Information

Efficient compilation strategy for object‐oriented languages under the closed‐world assumption

Contact Info

Product

Resources

About