[9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[Thomas Wuerthinger]

This is why Graal’s inlining heuristics are not based on the number of bytecodes, but the complexity of the compiler graph after applying canonicalisation. Adding asserts to the bytecodes should not influence peak performance when they are disabled. Same for expressing the same logic with a different number of bytecodes.

- thomas

On 05 Sep 2014, at 08:59, Remi Forax <forax at univ-mlv.fr> wrote:

> 
> On 09/03/2014 07:46 PM, John Rose wrote:
>> On Sep 3, 2014, at 10:35 AM, Mark Roos <mroos at roos.com> wrote:
>> 
>>> From Morris
>>> 
>>>         All that assert laden code is nice to see.
>>> 
>>> I just finished watching a video from Doug Lea where he mentioned that having asserts can
>>> inhibit inlining due to the additional byte codes.  So he sadly does not use them due to
>>> performance issues.
>>> 
>>> Does anyone have any insights on this?
>> Yep.
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028450.html
>> https://bugs.openjdk.java.net/browse/JDK-6316156
> 
> yes, sadly, it's sometimes a real problem, here is a thread on core-lib [1] about removing an assert in Integer.valueOf that allow JDart to have acceptable perf.
> 
>> 
>> — John
> 
> Rémi
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/010007.html
> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev