An Approach to Static Performance Guarantees for Programs with Run-time Checks

Instrumenting programs for performing run-time checking of properties, such as regular shapes, is a common and useful technique that helps programmers detect incorrect program behaviors. This is specially true in dynamic languages such as Prolog. However, such run-time checks inevitably introduce run-time overhead (in execution time, memory, energy, etc.). Several approaches have been proposed for reducing such overhead, such as eliminating the checks that can statically be proved to always succeed, and/or optimizing the way in which the (remaining) checks are performed. However, there are cases in which it is not possible to remove all checks statically (e.g., open libraries which must check their interfaces, complex properties, unknown code, etc.) and in which, even after optimizations, these remaining checks still may introduce an unacceptable level of overhead. It is thus important for programmers to be able to determine the additional cost due to the run-time checks and compare it to some notion of admissible cost. The common practice used for estimating run-time checking overhead is profiling, which is not exhaustive by nature. Instead, we propose a method that uses static analysis to estimate such overhead, with the advantage that the estimations are functions parameterized by input data sizes. Unlike profiling, this approach can provide guarantees for all possible execution traces, and allows assessing how the overhead grows as the size of the input grows. Our method also extends an existing assertion verification framework to express "admissible" overheads, and statically and automatically checks whether the instrumented program conforms with such specifications. Finally, we present an experimental evaluation of our approach that suggests that our method is feasible and promising.Comment: 15 pages, 3 tables; submitted to ICLP'18, accepted as technical communicatio

Rubyに対するGradual typingの導入

　プログラミング言語Rubyは，広く使用されている動的型付け言語である．　Rubyは実行時に型チェックを行うため，プログラムを実行し型エラーを含む部分に実行が及ばなければ型エラーは報告されない．　このことは，プログラム中に型エラーによるバグが潜在的に残り，バグの発見が遅れたり，バグを見逃したりする要因となっている．　このような動的型付けの欠点を補う方法として，Gradual typingが提案されている．　Gradual typingとは，型注釈の有無により型付けの手法が異なるような型システムである．　型注釈がある部分については静的に型付けをし，実行前に型チェックを行う．　型注釈がない部分については動的型として型付けをし，実行時に型チェックを行う．　本研究の目的は，Rubyの動的型付けによる柔軟性を残しつつ，プログラムの型エラーによるバグの発見を容易にすることである．　その方針として，RubyにGradual typingを導入することで，静的型エラーの検出と，Rubyの柔軟性を両立させることを目指す．　本論文では，Gradual typingに基づく動的型と型注釈の構文を加えたRubyのサブセットを考え，そのサブセットについて型付け規則と評価規則を与え，実装に向けての基本的な考え方を示す．　さらにその正当性を，進行定理と保存定理を証明することで示す．電気通信大学201

Type Checking and Inference for Dynamic Languages

Object-oriented dynamic languages such as Ruby, Python, and JavaScript provide rapid code development and a high degree of flexibility and agility to the programmer. Some of the their main features include dynamic typing and metaprogramming. In dynamic typing, programmers do not declare or cast types, and types are not known until run time. In addition, an object’s suitability is determined by its methods, as opposed to its class. Metaprogramming dynamically generates code as the program executes, which means that methods and classes can be added and modified at run-time. These features are powerful but lead to a major drawback of dynamic languages: the lack of static types means that type errors can remain latent long into the software development process or even into deployment, especially in the presence of metaprogramming. To bring the benefits of static types to dynamic languages, I present three pieces of work. First, I present the Ruby Type Checker (rtc), a tool that adds type check- ing to Ruby. Rtc addresses the issue of latent type errors by checking all types during run time at method entrance and exit. Thus it checks types later than a purely static system, but earlier than a traditional dynamic type system. Rtc is implemented as a Ruby library and supports type annotations on classes, methods, and objects. Rtc provides a rich type language that includes union and intersection types, higher-order (block) types, and parametric polymorphism, among other features. We applied rtc to several apps and found it effective at checking types. Second, I present Hummingbird, a just-in-time static type checker for dy- namic languages. Hummingbird also prevents latent type errors, and type checks Ruby code even in the presence of metaprogramming, which is not handled by rtc. In Hummingbird, method type signatures are gathered dynamically at run-time, as those methods are created. When a method is called, Hummingbird statically type checks the method body against current type signatures. Thus, Hummingbird provides thorough static checks on a per-method basis, while also allowing arbitrarily complex metaprogramming. We applied Hummingbird to six apps, including three that use Ruby on Rails, a powerful framework that relies heavily on metaprogramming. We found that all apps type check successfully using Hummingbird, and that Hummingbird’s performance overhead is reasonable. Lastly, I present a practical type inference system for Ruby. Although both rtc and Hummingbird are very effective tools for type checking, the programmer must provide the type annotations on the application methods, which may be a time-consuming and error-prone process. Type inference is a generalization of type checking that automatically infers types while performing checking. However, standard type inference often infers types that are overly permissive compared to what a programmer might write, or contain no useful information, such as the bottom type. I first present a standard type inference system for Ruby, where constraints on a method is statically gathered as soon as the method is invoked at run-time, and types are resolved after all constraints have been gathered on all methods. I then build a practical type inference system on top of the standard type inference system. The goal of my practical type inference system is to infer types that are concise and include actual classes when appropriate. Finally, I evaluate my practical type inference system on three Ruby apps and show it to be very effective compared to the standard type inference system. In sum, I believe that rtc, Hummingbird, and the practical type inference system all take strong steps forward in bringing the benefits of static typing to dynamic languages