Tom Rodriguez wrote (see JDK-8173699):
"I'm actually unclear why we need return_oop at all. The deopt code knows whether it's returning somewhere in the interpreter where there is a value on the top of stack. Why can't it figure out that it's returning to a location that expects atos and only preserve the value in that case? I guess currently that logic lives way at the end of the deopt in vframeArrayElement::unpack_on_stack in vframeArray.cpp. If you look at the end of that method you can see that for that for all the exec_modes except Unpack_deopt we reset the deopt entry for the top frame to expect vtos so preserving the value based on return_oop is clearly either useless or wrong in those cases. I think a refactoring of that logic so it could be used earlier could completely replace the return_oop flag."