> De: "mechanical-sympathy" <mechanical-sympathy@googlegroups.com>
> À: "mechanical-sympathy" <mechanical-sympathy@googlegroups.com>
> Envoyé: Mardi 23 Avril 2019 18:23:48
> Objet: Re: Exotic classes

> Replies inline

> On Monday, April 22, 2019 at 12:37:19 PM UTC-7, Remi Forax wrote:
>>> De: "mechanical-sympathy" < [ javascript-blocked: |
>>> mechanica...@googlegroups.com ] >
>>> À: "mechanical-sympathy" < [ javascript-blocked: | 
>>> mechanica...@googlegroups.com
>>> ] >
>>> Envoyé: Lundi 22 Avril 2019 20:25:01
>>> Objet: Re: Exotic classes

>>> These classes (especially MostlyConstant) are pretty cool. I have some 
>>> questions
>>> about them:
>>> 1. In MostlyConstant I noticed that modifying the constant doesn't call
>>> MutableCallSite.syncAll(). Should it?

>> yes, you're right from a spec POV i should call syncAll(),
>> the thing is that the current OpenJDK implementation doesn't need syncAll, 
>> but
>> it may change in the future or for another implementation.

>>> 2. A followup to #1: MutableCallSite.syncAll() doesn't actually seem 
>>> implemented
>>> in OpenJDK. Is it correct to call it?

>> yes, it's not implemented because the native part of setTarget() do the 
>> deopt,
>> but it's an implementation detail.

>>> 3. In my non-scientific JMH measurements, it seems like modifying the call 
>>> site
>>> takes about 1us. Does that sound about right? From what I can tell modifying
>>> the constant is akin to deoptimizing the code and recompiling it, which 
>>> means
>>> that 1us seems really fast.

>> it's quite fast but it may be because
>> - it may be not optimized yet
>> - the VM mark all the different generated assembly codes that reference the
>> constant as should be removed from the code cache and will do it later,
>> - the VM will not re-optimize directly if a code is deoptimized, but jump in 
>> the
>> interpreter and re-optimize later.

> I was running this in a JMH benchmark, and I inspected the Assembly and 
> Compiler
> output; I believe it was reaching c2 before swapping.

> A followup question: does deoptimization mean it reverts to a C1 copy of the
> code, or directly back to the interpreter? i.e. how much work does it have to
> undo?

no, for a method, the code generated by c1 is often long gone at the time the 
code generated by c2 detects that it should deopt. 
And c1 like c2 generates the code optimistically so even if the code generated 
by c1 was around, there is a good chance it will have to be de-optimized too. 

BTW, i've just added a way to have equals and hashCode automatically 
implemented to exotic [1]. 

Rémi 
[1] 
https://github.com/forax/exotic/blob/master/src/main/java/com.github.forax.exotic/com/github/forax/exotic/ObjectSupport.java#L38
 

>> so there is a good chance that what you are measuring is not all 
>> de-optimization
>> cost.

>> Rémi

>>> On Monday, February 26, 2018 at 11:29:19 AM UTC-8, Remi Forax wrote:
>>>> Hi all,
>>>> i'm preparing a talk at DevoxxFR on how to make a field value, a returned 
>>>> value,
>>>> etc constant for any decent JITs (everything but c1), so i've bundled 
>>>> together
>>>> several patterns i use for implementing dynamic language runtimes into an 
>>>> Java
>>>> API

>>>> [ https://github.com/forax/exotic | https://github.com/forax/exotic ]

>>>> I would like to have your comments about those exotic classes (it's 
>>>> already has
>>>> been done, it's stupid, it's not thread safe, etc)

>>>> regards,
>>>> Rémi

> --
> You received this message because you are subscribed to the Google Groups
> "mechanical-sympathy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email
> to [ mailto:mechanical-sympathy+unsubscr...@googlegroups.com |
> mechanical-sympathy+unsubscr...@googlegroups.com ] .
> For more options, visit [ https://groups.google.com/d/optout |
> https://groups.google.com/d/optout ] .

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to