P4
Making JVMCI changes are currently complicated by the fact that Graal follows the express model (i.e. supports more than one JDK version). This means adapting to multiple JVMCI versions. Once Graal is integrated into the JDK this is no longer required and JVMCI changes can be made more easily since both sides of the interface will be in the same code base. This issue exists as a placeholder for enhancements to be considered in the unified code base.
1. The c2 calling convention for stubs automatically adds the trailing thread argument for the calls which need it. It's some implicit magic. C1 and Graal pass the thread as the first argument and generally things in SharedRuntime follow the prepend pattern and OptoRuntime follows the c2 idiom. Function names that end with _C are also C2 idiom. The reason for this pattern is that it's slightly more efficient when passing arguments through a stub as you don't need to shuffle all the arguments over by one just to inject the thread. Graal should consider adding support for the APPEND_THREAD style.
1. The c2 calling convention for stubs automatically adds the trailing thread argument for the calls which need it. It's some implicit magic. C1 and Graal pass the thread as the first argument and generally things in SharedRuntime follow the prepend pattern and OptoRuntime follows the c2 idiom. Function names that end with _C are also C2 idiom. The reason for this pattern is that it's slightly more efficient when passing arguments through a stub as you don't need to shuffle all the arguments over by one just to inject the thread. Graal should consider adding support for the APPEND_THREAD style.