Win32AttachOperationRequest seems to be using global new?

[David Holmes]

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 
>> <tanksherman27 at 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 at 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 at XZ
>>>
>>> undname "??2 at YAPEAX_K@Z"
>>> Microsoft (R) C++ Name Undecorator
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> Undecoration of :- "??2 at YAPEAX_K@Z"
>>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)"
>>>
>>> undname "??0Win32AttachOperationRequest@@QEAA at XZ"
>>> Microsoft (R) C++ Name Undecorator
>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>
>>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at 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