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