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
