Warum hat die JVM eine maximale Inline-Tiefe?

Question

java hat ein Argument -XX:MaxInlineLevel (mit einem Standardwert von 9), die die maximale Anzahl der geschachtelten Aufrufe von Inline steuert. Warum gibt es eine solche Grenze? Warum reichen die üblichen Heuristiken auf Basis von Häufigkeit und Code-Größe nicht aus, damit die JVM selbst entscheiden kann, wie tief sie inline ist?

(dies wird durch JitWatch aufgefordert wird, zeigt mir, dass ein tief verschachtelt Guava checkArgument Anruf wurde nicht aufgrund Tiefe inlined wird)

Answer 1

Einige bedeutende Suche deckt diese interessante kleine fragment (Ich habe tatsächlich so weit Seite die Google-Suche):

if (inline_depth() > MaxInlineLevel) { 
     return "inlining too deep"; 
    } 
    if (method() == callee_method 
      && inline_depth() > MaxRecursiveInlineLevel) { 
     return "recursively inlining too deep"; 
    } 

, die darauf hindeuten, dass die MaxInlineLevel wie erwartet eine harte Grenze, wie tief gehen Sie, bevor Sie inlining stoppen. Es schlägt auch vor, dass die MaxRecursiveInlineLevel bezieht sich nur auf direkte rekursive Aufrufe, nicht umgekehrt rekursive Aufrufe wie foo() Anrufe bar(), die foo() ruft.

Also ich denke, ich in meiner Vermutung Kommentar richtig war - MaxInlineLevel gegen gegenseitige Rekursion zu schützen, ist da zu erkennen, dass Sie Verweise auf die volle Tiefe des inlining Call-Stack halten müßten.

MaxInlineResursionLevel Steuerungen foo() Anrufe foo() Inlining.

Beachten Sie, dass der referenzierte Code möglicherweise keine echte JVM ist.

Kommentare von @apangin findet eine modernere Version von Hotspot von Open JDK 8 vermuten, dass es heutzutage nicht mehr ganz so einfach ist. Es sieht so aus, als ob der vollständige Stapel nach rekursiven Aufrufen durchsucht wird, so dass die gegenseitige Rekursion jetzt auch daran gehindert werden kann, über MaxRecursiveInlineLevel hinauszugehen.