RFR(L): 8005071: Incremental inlining for JSR 292

[Vladimir Kozlov]

On 12/19/12 9:31 AM, Roland Westrelin wrote:
>> While we are waiting Christian review, could you do some clean up in your changes?
>
> Sure.
>
>> Remove IncrementalInlineAfterOpts flag since it is unused. Also may be IncrementalInlineOneByOne and AlwaysIncrementalInline flags because it looks like they were used just for experiment.
>
> AlwaysIncrementalInline is useful for stress testing so I'd like to keep it.

OK.

>
>> But I don't see the flag which control new code usage. We should have one to be able switch new code totally OFF. MaxNodeLimit value should depend on that flag.
>
> -XX:LiveNodeCountInliningCutoff=0 turns the new code off but it doesn't adjust MaxNodeLimit. Do you think another flag is needed or checking for LiveNodeCountInliningCutoff=0 at startup and setting MaxNodeLimit to the former value is sufficient?

It is not obvious way. I would prefer separate product flag 
-XX:+IncrementalInline. Also verify that incremental inlining is off if 
we switch of all inlining -XX:-Inline.

Thanks,
Vladimir

>
>> Move whole later inlining loop into Incremental_Inline(igvn) to simplify code in Optimize(). Leave original igvn.optimize() call where it was before. In Incremental_Inline(igvn) do sequence:
>>
>> while(..) {
>> if (needed) PhaseIdealLoop
>> late inlining
>> igvn
>> }
>
> Ok.
>
>> Add comment, explaining why you need low_live_nodes.
>
> Ok.
>
>> bytecodeInfo.cpp:
>>
>> 213   if ( callee_method->should_inline()) {
>>           ^ remove space
>
> Ok.
>
>> Move inlining_progress() up after clear_inlining_progress():
>>
>> +  void        clear_inlining_progress()         { _inlining_progress = false; }
>> +  int               inlining_incrementally() const { return _inlining_incrementally; }
>> +  void          set_inlining_incrementally()       { _inlining_incrementally = true; }
>> +  int               inlining_progress() const   { return _inlining_progress; }
>
> Ok.
>
>> I still don't like new dead code elimination code but with time constrain I may gave in. We should not crush without that code - and it should be fixed and not covered by this new code.
>
> Ok. I welcome suggestions and I'll think about it more.
>
> Roland.
>