Hi,<br><br>I've been doing some reading about how TCO is intended to be implemented. <br><br>As I understand it, the bytecode for a optimised tail call would look something like this:<br><br>0xc4 wide <br>0xb6 invokevirtual <br>
0x00 // high byte of index of method to call<br>0x03 // low byte of index of method to call<br>
0xb0 areturn<br><br>The idea being that the wide opcode indicates that this call should be optimised as a tail call, and that the interpreter part of HotSpot will then (if allowed by protection restrictions) rewrite the current native stack frame rather than create a new one.<br>
<br>My question is, what about non-HotSpot implementations?<br><br>Is the intention that the definition of the wide bytecode (as per <a href="http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc15.html">http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc15.html</a>) will change, so that we additionally have a "Form 3", which looks a bit like the above, and that any JVM which is fully compatible with version 7 bytecode is required to implement TCO (or at the very least, tolerate Form 3, and just execute the embedded invoke* instruction as normal, growing the stack)?<br>
<br>Or is the intent that the new form of wide will never appear in .class files, but only in code which has been generate dynamically, ie so that this is a private implementation detail to HotSpot and can't cause problems to other JVMs?<br>
<br>Or something else entirely?<br><br>Thanks,<br><br>Ben<br>