[9 or 10?] RFR(M): 8176506: C2: loop unswitching and unsafe accesses cause crash

[Roland Westrelin]

Hi Vladimir,

Thanks for looking at this.

> I find it problematic to decide whether an unsafe access is always 
> on-heap or not during parsing. Considering we plan to remove membars 
> around suspicious accesses (as a fix for JDK-8176513), I would like to 
> avoid conservatively treating them as raw.

Isn't the plan to remove the membars for 9 and put it back in 10?
I think it's a problem that we build a broken graph and try to plug the
holes as we find them because there will always be holes that we are not
yet aware of. That's why my suggestion is to be conservative. I also
think we should use arguments profiling and a null check to
speculatively cast base to non null when it makes sense. We have the
machinery to do that and it's a very simple change.

> FTR I faced a similar problem before (JDK-8155635 [1]) and initially 
> experimented with a different approach: convert null-based oop pointers 
> to raw pointers [2], but after additional discussions decided to abandon it.

I noticed that discussion. When we hit a similar problem with Shenandoah
I used a fix similar to the one you suggested. If you read Vladimir K's
answer:

http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-April/022745.html

"I think we should track which pointers are really RAW when creating
them."

which is what the fix I'm proposing now is doing.

Roland.