LRB midpath code quality

Roman Kennke rkennke at redhat.com
Wed Mar 6 13:12:58 UTC 2019


Ok. Bad me :-)

I'll run specjvm before/after let's see if we get improved performance 
from this patch.

Thanks!!
Roman


> 
>> Wow wtf. Is this only in sh/jdk ? When did that happen?! Does it mean it
>> foobar'ed *all* such implicit null-checks?
> 
> changeset:   54694:a97e6642b12d
> user:        rkennke
> date:        Fri Feb 15 18:58:37 2019 +0100
> summary:     Load reference barriers
> 
> diff -r db2675d861c0 -r a97e6642b12d src/hotspot/share/opto/lcm.cpp
> --- a/src/hotspot/share/opto/lcm.cpp	Thu Feb 14 20:52:50 2019 +0100
> +++ b/src/hotspot/share/opto/lcm.cpp	Fri Feb 15 18:58:37 2019 +0100
> @@ -182,9 +178,6 @@
>       case Op_LoadRange:
>       case Op_LoadD_unaligned:
>       case Op_LoadL_unaligned:
> -    case Op_ShenandoahReadBarrier:
> -      assert(mach->in(2) == val, "should be address");
> -      break;
>       case Op_StoreB:
>       case Op_StoreC:
>       case Op_StoreCM:
> 
> Yes, quite possible it broke more implicit null checks.
> 
> Roland.
> 


More information about the shenandoah-dev mailing list