Win32AttachOperationRequest seems to be using global new?

[Julian Waters]

Hi Alex,

Thanks for creating the bug, I can take it on, but I'm not sure how
this should be fixed. Should it be a subclass of any of the
allocation.hpp classes or be allocated with CHeapObj, or should it
just have operator new defined in it directly as some classes do?
(UnstableIfTrap from C2 is one such example)

best regards,
Julian

On Fri, Nov 15, 2024 at 10:11 AM Alexey Menkov <alexey.menkov at oracle.com> wrote:
>
> 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
> >>> <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
> >
>