| Re: [omr-dev] No deoptimizations? |
Hi Raffaello,
Thanks for your great question. Before I respond, I just wanted to point out that this question would have been more properly addressed to the OpenJ9 community since the need for recompilation/deoptimization depends on the language and you are clearly asking in a Java context. That being said, there is no reason to not answer so here, we go.
Slide 52 in the deck you pointed to is showing the optimization levels and their progressions in our compiler. The optimization level is simply a choice of how much compile-time we want to invest in a given method based on how likely we think it is to run. In general, the default level of optimization is warm – some methods downgrade to cold (often when the compilation queue is growing quickly or we need to save compile-time for some reason) and others can upgrade to hot or higher based on the amount of time spent in the method. Once we pick an optimization level we will maintain at least that level – it is a statement about the amount of compilation resources to invest. At present, once we have chosen to upgrade a method we will maintain at least that level of optimization in future compilations.
Now the term ‘deoptimization’ is a bit overloaded. We do not employ ‘deoptimization’ if you define deoptimization to mean reducing the amount of compilation resources to invest in a method. We do, however, employ speculative optimization and assumptions made at compile-time can be violated at runtime. As a result, we do need to compensate for these invalidations. Our compiler can do this a number of different ways. Historically, the compiler has tended to generate fallback code paths in the compiled bodies – for example, if we inlined a method that was subsequently invalidated we would patch the compiled code to begin calling the method via the VM rather than throwing the whole compiled body away. In the last year we have been working to enhance our On Stack Replacement (OSR) infrastructure to allow us to transition the execution of a compiled body to the interpreter when an assumption is violated. At present we are using this mostly for Hot Code Replace to handle method invalidations, but we are going to be expanding its use over the next year to additional cases.
I hope that answers your question. If there is anything else I can expand on for you do let me know and thanks again for your interest in OpenJ9.
Kind regards,
| Andrew Craik Testarossa JIT Common Optimizer and x86 Code Generation Team Lead JIT Compiler Development and Performance IBM Canada Lab |
| Phone: 1-905-413-3620 E-mail: ajcraik@xxxxxxxxxx Find me on:  |  8200 Warden Ave Markham, ON L6G 1C7 Canada |