RFR: Remove obsolete and unused reduce-storeval-barrier optimization code

[Roman Kennke]

Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. 
Everything else should be ok:

http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/ 
<http://cr.openjdk.java.net/%7Erkennke/remove-reduce-storeval/webrev.01/>

Ok?

Roman

> Don't bother reviewing this. I made a mistake. I removed the newval in 
> some cases, but we do need it for the matrix barrier that is part of 
> our C2 pre-barrier code path. I'll post an updated webrev soon (not 
> today I guess... it's late here and almost weekend...)
>
> Roman
>
>> This is an almost 1:1 revert of an earlier changeset that attempted 
>> to optimize storeval barriers. The idea back then was that when we 
>> check for conc-mark-in-progress anyway, we could just as well only 
>> invoke the storeval (i.e. read) - barrier if conc-mark is active. It 
>> never worked very well (and we never turned it on by default) and 
>> gained us anything significant. But now it's even worse: 
>> updating-refs now also happens outside conc-mark, and thus the whole 
>> idea is obsolete. In fact, maybe we can do something smarter once all 
>> the X_in_progress flags have been folded into the gc-phase-field 
>> (need to see this when it's there). The patch removes the code, and 
>> thus reduces our upstream diff.
>>
>> Test: hotspot_gc_shenandoah
>>
>> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Erkennke/remove-reduce-storeval/webrev.00/>
>>
>> Ok?
>>
>