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

[Roland Westrelin]

> 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.

> 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?

> 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.