Which of my Transient Type Checks are not (Almost) Free?
One form of type checking used in gradually typed language is transient type checking: whenever an object `flows’ through code with a type annotation, the object is dynamically checked to ensure it has the methods required by the annotation.
Although naive implementations of transient type checks have a high runtime overhead, just-in-time compilation and optimisation in virtual machines can eliminate much of this overhead. Unfortunately the improvement is not uniform: while most type checks can be optimised away, some will significantly decrease a program’s performance, and some may even increase it.
In this paper, we refine the so called ``Takikawa'' protocol, and use it to identify which type annotations have the greatest effects on performance. In particular, we show how graphing the performance of such benchmarks when varying which type annotations are present in the source code can be used to discern potential patterns in performance. We demonstrate our approach by testing the Moth virtual machine: for many of the benchmarks where Moth’s transient type checking impacts performance, we have been able to identify one or two specific type annotations that are the likely cause. Without these type annotations, the performance impact of transient type checking becomes negligible.
Using our technique programmers can optimise programs by removing expensive type checks, and VM engineers can identify new opportunities for compiler optimisation.
Tue 22 Oct Times are displayed in time zone: Beirut change
|11:00 - 11:30|
|Which of my Transient Type Checks are not (Almost) Free?|
|11:30 - 12:00|
|Efficient Fail-Fast Dynamic Subtype Checking|
|12:00 - 12:15|
|Towards Gradual Checking of Reference Capabilities|
Kiko Fernandez-ReyesUppsala University, Isaac Oscar GarianoVictoria University of Wellington, James NobleVictoria University of Wellington, Tobias WrigstadUppsala UniversityPre-print
|12:15 - 12:30|
|Formal Verification of JIT by Symbolic Execution|