On Mon, 5 Oct 2020 12:44:34 GMT, Vladimir Kempik <vkem...@openjdk.org> wrote:
>>> _Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on >>> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_ >>> Hi Vladimir, >>> >>> On 2/10/2020 5:37 pm, Vladimir Kempik wrote: >>> >>> > On Fri, 2 Oct 2020 07:27:17 GMT, David Holmes <dholmes at openjdk.org> >>> > wrote: >>> > > Okay but look at the example that documentation gives: >>> > > > For example, if the jvmtiParamInfo returned by GetExtensionEvents >>> > > > indicates that there is a jint parameter, the event >>> > > > handler should be declared: ``` >>> > > > void JNICALL myHandler(jvmtiEnv* jvmti_env, jint myInt, ...) >>> > > > ``` >>> > > >>> > > >>> > > The myInt is explicit, just as our "jboolean* enabled" is explicit. I >>> > > think they key point is that the signature must >>> > > end with "..." which it does. >>> > > I don't see anything here that needs to be fixed. >>> > >>> > >>> > Hello David. On majority of platforms this would be fine. >>> > But on some platforms, variadic arguments and non variadic arguments are >>> > passed differently ( for example on >>> > macos-aarch64, variadic args are passed always on stack, non variadic on >>> > registers (and on stack for 9th+ arg) , that >>> > causes issues. >>> >>> Okay - I see the potential for a problme here but ... >>> >>> > If you still see no issues here we can delay and make this changeset part >>> > of JEP-391. >>> > But since this changeset isn't much macos-aarch64 specific, I thought it >>> > would be good to integrate it separately from >>> > jep-391. >>> >>> ... this change actually goes against the example in the spec, so if you >>> make this change it indicates the spec needs to be updated too. >>> >>> Cheers, >>> David >>> ----- >> >> Hello David >> >> I really believe the problem is in document here ( in examples) >> first, the doc clearly specify the type >> >> typedef jvmtiError (JNICALL *jvmtiExtensionFunction) >> (jvmtiEnv* jvmti_env, >> ...); >> >> then in examples it declares the function not matching this spec. >> >> Is it a good idea to update the docs in a separate bug ? >> >> Thanks, Vladimir > > Hello David > I have created CSR draft > https://bugs.openjdk.java.net/browse/JDK-8254014 > > Regards, Vladimir Hello I have updated the PR with changes from spec of CSR Regards, Vladimir ------------- PR: https://git.openjdk.java.net/jdk/pull/466
