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

[Vladimir Kozlov]

Thank you, Roland, for checking this.


While we are waiting Christian review, could you do some clean up in 
your changes?

Remove IncrementalInlineAfterOpts flag since it is unused. Also may be 
IncrementalInlineOneByOne and AlwaysIncrementalInline flags because it 
looks like they were used just for experiment.

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.

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
}

Add comment, explaining why you need low_live_nodes.

bytecodeInfo.cpp:

213   if ( callee_method->should_inline()) {
           ^ remove space

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; }


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.

Thanks,
Vladimir

On 12/19/12 7:48 AM, Roland Westrelin wrote:
>> I don't see the big need for new "dead code cleanup" code when we have already several implementations. We may need to adjust them to work for your case (PhaseIdealLoop work without inner loops).
>
>
> I tried doing a PhaseIdealLoop for every inlining and compilation time (as reported by CITime) on nashorn benchmarks doubled for several of them. This said, it doesn't seem to affect the peak performance of the benchmarks except for one maybe. But we're also not very aggressive in the inlining we do currently.
>
> I tried a CTW run with this change (with -XX:+AlwaysIncrementalInline: every inlining is done post parsing. That's how I've been stress testing things.) and there are several failures so it looks like if we decide to go that way, more time is required to get a clean run.
>
> Roland.
>