Sorry, didn't noticed the message before.
Yes, this is oversight.
Filed https://bugs.openjdk.org/browse/JDK-8344262
Thank you for the finding Julian.
--alex
On 14.11.2024 0:28, David Holmes wrote:
> That didn't work so cc'ing serviceability-dev
>
> I think it was just an oversight.
>
> David
>
>
> On 14/11/2024 6:24 pm, David Holmes wrote:
>> It was added by JDK-8339289 so cc'ing Alex.
>>
>> David
>>
>> On 14/11/2024 5:33 pm, Julian Waters wrote:
>>> Bumping, I'm still curious about this issue
>>>
>>> best regards,
>>> Julian
>>>
>>> On Tue, Nov 12, 2024 at 10:20 PM Julian Waters
>>> <tanksherma...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> Win32AttachOperationRequest is created via new, but doesn't specify
>>>> a custom new inside the class definition. The result seems to be
>>>> that we use global new on Windows:
>>>>
>>>> for (int i=0; i<max_enqueued_operations; i++) {
>>>> Win32AttachOperationRequest* op = new
>>>> Win32AttachOperationRequest();
>>>> f1: b9 28 0d 00 00 mov ecx,0xd28
>>>> f6: e8 00 00 00 00 call fb
>>>> <Win32AttachListener::init()+0x7b>
>>>> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long)
>>>>
>>>> Stepping away from gcc's objdump and using the Microsoft dumpbin
>>>> alongside cl.exe instead, the result is this:
>>>>
>>>> 0000000000000264: B9 28 0D 00 00 mov ecx,0D28h
>>>> 0000000000000269: E8 00 00 00 00 call ??2@YAPEAX_K@Z
>>>> 000000000000026E: 48 89 44 24 28 mov qword ptr
>>>> [rsp+28h],rax
>>>> 0000000000000273: 48 83 7C 24 28 00 cmp qword ptr
>>>> [rsp+28h],0
>>>> 0000000000000279: 74 11 je 000000000000028C
>>>> 000000000000027B: 48 8B 4C 24 28 mov rcx,qword ptr
>>>> [rsp+28h]
>>>> 0000000000000280: E8 00 00 00 00 call ??
>>>> 0Win32AttachOperationRequest@@QEAA@XZ
>>>>
>>>> undname "??2@YAPEAX_K@Z"
>>>> Microsoft (R) C++ Name Undecorator
>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>
>>>> Undecoration of :- "??2@YAPEAX_K@Z"
>>>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)"
>>>>
>>>> undname "??0Win32AttachOperationRequest@@QEAA@XZ"
>>>> Microsoft (R) C++ Name Undecorator
>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>
>>>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA@XZ"
>>>> is :- "public: __cdecl
>>>> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64"
>>>>
>>>> Visual Studio, lacking the nm utility, obviously doesn't catch this.
>>>> What was more surprising is that the gcc Link Time check also fails
>>>> to catch it as well. I had to manually check the output of nm after
>>>> an unrelated failure and happened to stumble across the symbols
>>>> _Znwy and _ZdlPvy which both correspond to
>>>>
>>>> operator new(unsigned long long)
>>>> operator delete(void*, unsigned long long)
>>>>
>>>> The delete can be ignored, it's the result of a bug on my
>>>> experimental branch (It was first discovered there, then I tested it
>>>> on master). I'm more interested about the new, since it seems to be
>>>> violating a HotSpot rule. Is this an intentional exception to the
>>>> rule, or an oversight?
>>>>
>>>> best regards,
>>>> Julian
>
