RFR: Concurrent code cache evacuation

[Aleksey Shipilev]

On 06/28/2017 12:40 PM, Roman Kennke wrote:
> Am 28.06.2017 um 12:31 schrieb Aleksey Shipilev:
>> On 06/28/2017 12:20 PM, Roman Kennke wrote:
>>> I would probably not couple conc codecache evac to
>>> ShenandoahConcurrentCodeRoots, but rather make a new flag (or rename
>>> ShenandoahBarriersForConst once again). The reason for this is that
>>> while concurrent code cache marking is unproblematic with regards to
>>> performance (no new barriers required), concurrent code cache evacuation
>>> is not. It requires more barriers and can thus affect performance.
>> I was thinking that ShenandoahConcurrentCodeRoots should act as global
>> killswitch for concurrent code cache ops, both scanning and evacuating. So this
>> would happen:
>>
>>  -ShConcCodeRoots ?ShBarriersForConst: scan at STW,       evac at STW
>>  +ShConcCodeRoots -ShBarriersForConst: scan concurrently, evac at STW
>>  +ShConcCodeRoots +ShBarriersForConst: scan concurrently, evac concurrently
>>
>> Maybe what is missing from equation is an option for disabling concurrent scan?
> 
> Concurrent code cache evacuation is a feature. ShBarriersForConst is a
> technical detail (much like +/-ShenandoahReadBarriers, etc).
> Concurrent code cache marking is technically separate. I have no problem
> putting these two under the same flag if performance and correctness are
> both ok. For conc codecache marking we are pretty certain at this point
> it is ok, conc codecache evac not so much (yet).

All right, fine. Let's keep it simple for now, and use only ShBarriersForConst:
 http://cr.openjdk.java.net/~shade/shenandoah/codecache-conc-evac/webrev.03/

-Aleksey