[aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__

[Monica Beckwith]

Hi David - 

I do understand your point. And in the long run, discussions will happen either way. I appreciated getting these smaller shared code changes discussed here esp. where Kim provided feedback to separate the os+cpu specific changes to their folder. It's all a learning opportunity for us. 

Thanks,
-Monica

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Wednesday, July 15, 2020 8:33 PM
To: Monica Beckwith <Monica.Beckwith at microsoft.com>; Kim Barrett <kim.barrett at oracle.com>; Andrew Haley <aph at redhat.com>
Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>; openjdk-aarch64 <openjdk-aarch64 at microsoft.com>
Subject: Re: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__

Hi Monica,

On 16/07/2020 1:47 am, Monica Beckwith wrote:
> Hello everyone -
> 
> Here's some background on this and similar RFRs that we are sending out ahead of the `repo-aarch64-port` tagged RFRs:
> 
> - we are sending these right now to encourage discussions around the changes that we had initially guarded by appropriate ifdefs since we were modifying shared code for the default use-case (such as having GCC specific macros for aarch64).

Pushing general cleanups is fine. But no change that adds an ifdef for
WIN64 or the VS toolchain to the existing Aarch64 code, can be considered a general cleanup as it obviously exists purely to support the Windows-aarch64 port. All such issues should be marked for repo-aarch64-port and pushed to the staging repo. Once the port JEP has been targeted they will then become part of the single changeset that implements the JEP.

Thanks,
David
-----

> - for this particular one, I too thought that dropping 
> __PRETTY_FUNCTION__ was a better option. (So, thank you both for 
> suggesting that)
> - there are just 2 more cleanups to `cpu/aarch64/*` where MSVC keywords or macro names are employed, and I was hoping to send those out shortly.
> 
> So, @Andrew Haley, let us know if we should stop and wait for all 
> existing cleanups to get pushed to tip. Or if we should send out the 
> last 2 (as mentioned above) and then sync and start pushing our 
> Windows + AArch64 specific changes to `repo-aarch64-port.`
> 
> -Monica
> 
> 
> 
> -----Original Message-----
> From: Kim Barrett <kim.barrett at oracle.com>
> Sent: Wednesday, July 15, 2020 5:48 AM
> To: Andrew Haley <aph at redhat.com>
> Cc: Monica Beckwith <Monica.Beckwith at microsoft.com>; 
> aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers 
> <hotspot-dev at openjdk.java.net>; openjdk-aarch64 
> <openjdk-aarch64 at microsoft.com>
> Subject: Re: [aarch64-port-dev ] RFR(XS) 8248681: AArch64: MSVC 
> doesn't support __PRETTY_FUNCTION__
> 
>> On Jul 15, 2020, at 4:24 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 15/07/2020 00:18, Kim Barrett wrote:
>>> Of course, this is currently the only use of __PRETTY_FUNCTION__ in 
>>> all of HotSpot, so that might be considered excessive overhead.  But 
>>> if we had such a macro it would simplify (and so perhaps encourage) 
>>> the use of this feature.
>>
>> I don't think we need __PRETTY_FUNCTION__ here. Anyway, I'm leaning 
>> towards David Holmes' position that this is AArch64/Windows specific,
> 
> Eliminating the only use of __PRETTY_FUNCTION__ also seems like a good solution, and doesn’t seem aarch64/windows-specific to me.
> 
>