On Thu, 22 Oct 2020 08:42:40 GMT, Richard Reingruber <rr...@openjdk.org> wrote:
>> Stack frames are counted beginning at 0. The top frame has depth 0. So >> object deoptimization happens in the top frame. >> >> Still the used method is not optimal because it assumes that objects of >> frames within the given depth are accessed and their escape state is >> changed. But potentially caller methods optimized on the escape state >> therefore it searches for caller frames passing ArgEscape objects and >> deoptimizes these too. With ForceEarlyReturn no objects are accessed but it >> is so uncommon that I did not bother optimizing this. Should I? > > @robehn you haven't messed up. Hope I havn't either. I've tested > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > > jtreg:test/hotspot/jtreg:hotspot_serviceability 197 197 0 0 > > jtreg:test/jdk:jdk_svc 1176 1176 0 0 > > jtreg:test/jdk:jdk_jdi 174 174 0 0 > > jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdi 1141 1141 0 0 > > jtreg:test/hotspot/jtreg:vmTestbase_nsk_jvmti 648 648 0 0 > > jtreg:test/hotspot/jtreg:vmTestbase_nsk_jdwp 113 113 0 0 > > ============================== > TEST SUCCESS > jdk_jdi now includes jdk/com/sun/jdi/EATests.java which tests > PopFrame/ForceEarlyReturn with object reallocation with and without > reallocation failures. Ah. I see now the loop uses <= instead of <. So my reasoning was right but off by 1. Passing in 0 really means deopt 1 frame. Which means everything is fine and working the way I expect it to. ------------- PR: https://git.openjdk.java.net/jdk/pull/729
