RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

[Vladimir Kempik]

On Fri, 2 Oct 2020 15:26:30 GMT, Vladimir Kempik <vkempik 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.  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.
>> Regards, Vladimir
>
>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on
>> [hotspot-dev](mailto:hotspot-dev at 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

-------------

PR: https://git.openjdk.java.net/jdk/pull/466