RFR: 8202711: Merge tiered compilation policies

[Vladimir Kozlov]

On 5/7/18 12:59 PM, Claes Redestad wrote:
> Hi Vladimir,
> 
> On 2018-05-07 21:25, Vladimir Kozlov wrote:
>> Hi Claes,
>>
>> First, please explain why tiered compilation policies "should be 
>> merged into a single policy"?
> 
> so, from my understanding these two different tiered compilation 
> policies stem from a time when
> TieredCompilation (briefly) had a closed, commercial feature set, where 
> most (all?) tuning work
> went into the advanced (closed source) policy, which then quickly became 
> the default once it was
> all open sourced.

Right.

> 
> Using the simple compilation policy explicitly 
> (-XX:CompilationPolicyChoice=2, almost as obvious
> as -XX:SyncKnobs...) has barely any testing coverage, is highly likely 
> to be bit rot and buggy and
> not something we've tuned or benchmarked for in a long while. 
> Effectively this deprecates/obsoletes
> the specific choice, which doesn't seem to be documented anywhere but in 
> code, but does so
> gracefully.

Agree, this is good reason for change.

> 
>>
>> After these changes there is no difference between 
>> CompilationPolicyChoice 2 and 3. Why you kept both?
> 
> Would you prefer if the CompilationPolicyChoice == 2 case did an 
> Unimplemented() as if TIERED
> wasn't defined in the build?

I want to remove == 3 at all. Limit flag to 0,1,2 values. Where 2 is 
default and only option for Tiered.

> 
>>
>> Changes looks good but I wish all compilation policy files moved into 
>> hostpot/share/compiler directory. But it could be done separately 
>> otherwise current review will be difficult.
> 
> Right, renaming and moving this is easier to do separately as a 
> follow-up. Perhaps runtime folks
> have opinions..? Can I move memory/heap.c|hpp files to 
> share/compiler/codeHeap.c|hpp, too? ;-)
> 
> As mentioned I'd like to see this renamed to TieredCompilationPolicy (or 
> similar) since the
> simple-/advanced notation is as unclear as they come and has led many 
> (myself included) astray.

Yes, I totally agree with renaming.

Thanks,
Vladimir

> 
>> Good.
> 
> Thanks!
> 
> /Claes