LRB midpath code quality

[Roman Kennke]

>> But can you explain to me why it should be needed at all? If a
>> dominating (implicit?) null-check before the in-cset-check should catch
>> all nulls on that path already? Why does it matter?
> 
> That dominating check was removed so we can have an implicit null check
> so we don't execute any null check instruction.

Ok, but why has it been removed?
1. In case C2 has proven the value to be not-NULL, I suppose we can just
as well not null-check in the fwd ptr load?
2. In case it has been turned into an implicit NULL-check I argue that
this is wrong: we don't want an NPE or SEGV there, we want to skip the
whole path. Also, wouldn't the annotated assembly say so like 'implicit
exception: dispatches to ...' ?

> That doesn't quite work
> as the conversion to an implicit null check fails. But assuming that
> works, isn't it better to not execute a test for null?

Sure. But that would only ever throw an NPE? Or can it be made to branch
back too? And if so, it would have to be done *before* the cset check,
not after, otherwise it would go BOOM there.

Roman