RFR: 8253899: Make IsClassUnloadingEnabled signature match specification

David Holmes david.holmes at oracle.com
Tue Oct 6 01:28:02 UTC 2020


On 5/10/2020 10:47 pm, Vladimir Kempik wrote:
> 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

Thanks. I have updated and reviewed the CSR request.

David

> Regards, Vladimir
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/466
> 


More information about the serviceability-dev mailing list