Re: [omr-dev] No deoptimizations?

["Andrew Craik" <ajcraik@xxxxxxxxxx>]

Hi Raffaello,

So OSR in this context is a general notion of transitioning execution back to the interpreter mid-method execution and not the more restricted form you referred to. OpenJ9 employs Dynamic Loop Transfer to transition executing loops into compiled bodies mid-execution - our use of the term OSR always refers to transitions from compiled bodies back to the interpreter.

OMR is a different approach to supporting the polyglot from Graal/Truffle since it is not JVM specific and is not formulaic in how you should optimize your language. You could build a JIT for a language which behaves in a manner similar to Graal/Truffle where you aggressively speculate and OSR when your assumptions are not met. The framework can also support other styles of compilation (method-based, trace-based etc) where the compiled body may contain more fallback code. OMR is a collection of components that can be combined in a a variety of different ways depending on your language semantics, how much time and resource you are willing to invest in compilation, etc. You are right that if you were to employ a Graal/Truffle style of compilation our OSR technology would be what you would use to get from compiled code back to the interpreter.

Cheers,

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

raffaello.giulietti---28-03-2018 13:52:24---Hi Andrew, while my question indeed mentioned OpenJ9, its context is more general,

From:        raffaello.giulietti@xxxxxxxx
To:        omr-dev@xxxxxxxxxxx
Date:        28-03-18 13:52
Subject:        Re: [omr-dev] No deoptimizations?
Sent by:        omr-dev-bounces@xxxxxxxxxxx

---

Hi Andrew,

while my question indeed mentioned OpenJ9, its context is more general,
so I'm glad you answered on this mailing list.

I'm interested in implementing dynamic languages on a polyglot-aware
JVM. I'm familiar, at least in a broad sense, with Oracle Labs'
Truffle/Graal approach, which looks really promising, both in terms of
steady-state performance and the ease of inter-language communication
(zero-overhead access to foreign objects).

Since Graal's foundations lie in partial evaluation to produce optimized
machine code, it uses deoptimization to switch back to the interpreter
when compile-time assumptions are violated at runtime. The interpreted
code always implements the full semantics of a language, while partially
evaluated code needs not. On the other hand, partially evaluated code is
speculative, allowing aggressive optimizations.

So, if I understand you correctly, when the work is ready, OMR will make
use of OSR when compile-time assumptions are violated at runtime. In a
sense, OSR is to OMR what the deoptimizer is to Graal, right? (I ask
because sometimes the meaning of "OSR" is more restricted: interpreted
methods that happen to execute long running loops are optimized
on-the-fly, while "on stack".)


Greetings
Raffaello





On 2018-03-28 18:32, Andrew Craik wrote:
> 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@xxxxxx.com_ <mailto:ajcraik@xxxxxxxxxx>*
> Find me on:*LinkedIn: https://urldefense.proofpoint.com/v2/url?u=http-3A__linkedin.com_in_andrewcraik&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yhUm_2pJnvSwAJtPKyqqgfonntQ2dc7E84tRh9H2V_g&m=lAUd4oVTBvd2Ha5_Y0ZRUYGHopeVa1eE4FjBZj5WgNY&s=b90zfmPXVARXMGaUM-O6Xu4YjqI9-0_mJXmDjSqcw84&e=
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__linkedin.com_in_andrewcraik&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yhUm_2pJnvSwAJtPKyqqgfonntQ2dc7E84tRh9H2V_g&m=lAUd4oVTBvd2Ha5_Y0ZRUYGHopeVa1eE4FjBZj5WgNY&s=b90zfmPXVARXMGaUM-O6Xu4YjqI9-0_mJXmDjSqcw84&e=>                 
> IBM
> 
> 8200 Warden Ave
> Markham, ON L6G 1C7
> Canada
> 
>>
>> From: raffaello.giulietti@xxxxxxxx
>> To: omr-dev@xxxxxxxxxxx
>> Date: 2018/03/28 09:13 AM
>> Subject: [omr-dev] No deoptimizations?
>> Sent by: omr-dev-bounces@xxxxxxxxxxx
>>
>> Hi,
>>
>> looking at slide 52 in
>> https://urldefense.proofpoint.com/v2/url?
>>
> u=https-3A__www.slideshare.net_DanHeidinga_javaone-2D2017-2Declipse-2Dopenj9-2Dunder-2Dthe-2Dhood-2Dof-2Dthe-2Djvm&d=DwICAg&c=jf_iaSHvJObTbx-
>> siA1ZOg&r=sRHanByzmnMvzj5obfIeXw&m=hucroLP7FbxMJQlWhc7v8cac7UZbKt4FZETZ-
>> LR5OMQ&s=DcNwncxJZeh1k96QNQRBOmHh4hVabMmilXw41laiDjk&e=,
>> as all arrows point downwards it seems to me that there are never
>> deoptimization phases.
>>
>> Is my understanding correct? Does that mean that deoptimization phases
>> are never needed in OpenJ9?
>>
>> Greetings
>> Raffaello
>> _______________________________________________
>> omr-dev mailing list
>> omr-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://urldefense.proofpoint.com/v2/url?
>>
> u=https-3A__dev.eclipse.org_mailman_listinfo_omr-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-
>> siA1ZOg&r=sRHanByzmnMvzj5obfIeXw&m=hucroLP7FbxMJQlWhc7v8cac7UZbKt4FZETZ-
>> LR5OMQ&s=xZKPYdmMIdC8dk3zy6VIrsX6WpI6rNpTG_eYgnP7rRM&e=
>>
> 
> 
> 
> _______________________________________________
> omr-dev mailing list
> omr-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_omr-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yhUm_2pJnvSwAJtPKyqqgfonntQ2dc7E84tRh9H2V_g&m=lAUd4oVTBvd2Ha5_Y0ZRUYGHopeVa1eE4FjBZj5WgNY&s=_H-RE7qpBO72u9fDGhlk0O93qrT-wmd3hhdkxVbmui8&e=
> 

_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_omr-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=yhUm_2pJnvSwAJtPKyqqgfonntQ2dc7E84tRh9H2V_g&m=lAUd4oVTBvd2Ha5_Y0ZRUYGHopeVa1eE4FjBZj5WgNY&s=_H-RE7qpBO72u9fDGhlk0O93qrT-wmd3hhdkxVbmui8&e=