RFR(L): 8161259: Simplify including platform files.
David Holmes
david.holmes at oracle.com
Mon Jul 25 05:01:07 UTC 2016
This all looks good. Approval is now in place. Just waiting for final
conformation this builds okay for Aarch64 folk.
Thanks,
David
On 21/07/2016 8:59 PM, Lindenmaier, Goetz wrote:
> Hi,
>
>
>> I see the typo was actually much bigger than I thought :) Presumably the
> Well, I edited it some more ... this time I replaced the webrev in-place,
> webrev.05 is fixed now.
>
> I really should have an aarch64 machine :)
>
> Best regards,
> Goetz.
>
>> -----Original Message-----
>> From: David Holmes [mailto:david.holmes at oracle.com]
>> Sent: Donnerstag, 21. Juli 2016 12:00
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim Barrett
>> <kim.barrett at oracle.com>
>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>
>> On 21/07/2016 7:27 PM, Lindenmaier, Goetz wrote:
>>> Hi David,
>>>
>>> Copyright of register_definitions_x86.cpp is already fixed in hs-comp,
>>> I'll skip it to avoid merges.
>>
>> This isn't going into hs-comp so I don't know when the two will collide.
>> I would deal with it anyway - I can just apply the patch without
>> committing, deal with any merges, and then commit as you.
>>
>>> I fixed the others. New webrevs, also with Coleens fixes:
>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-newPfmIncl/webrev.05/
>>
>> I see the typo was actually much bigger than I thought :) Presumably the
>> INLCUDE typo caused it to be missed by a global search replace.
>>
>>> I also did another zero build configured as follows:
>>> --disable-hotspot-gtest --with-debug-level=fastdebug --with-jvm-
>> variants=zero
>>> on linuxx86_64.
>>
>> Thanks.
>>
>> David
>>
>>> Best regards,
>>> Goetz.
>>>
>>>> -----Original Message-----
>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>> Sent: Donnerstag, 21. Juli 2016 05:26
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim Barrett
>>>> <kim.barrett at oracle.com>
>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>>>
>>>> On 20/07/2016 8:32 PM, Lindenmaier, Goetz wrote:
>>>>> Hi
>>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~goetz/wr16/8161259-
>>>> newPfmIncl/webrev.04/
>>>>>
>>>>> It re-adds -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) in
>>>> CompileJvm.gmk
>>>>> and reverts the change to the aarch define in vmStructs_jvmci.cpp. I
>>>> documented
>>>>> what I learned about the platform defines in macros.hpp.
>>>>
>>>> Thanks - much appreciated. Other than Coleen's typo (well spotted!) and
>>>> the lingering _32 the only nit I have left is a handful of copyright
>>>> updates:
>>>>
>>>> src/cpu/x86/vm/register_definitions_x86.cpp:
>>>> src/share/vm/gc/shared/memset_with_concurrent_readers.hpp:
>>>> src/share/vm/runtime/semaphore.hpp:
>>>> src/cpu/ppc/vm/stubRoutines_ppc.hpp:
>>>> src/cpu/ppc/vm/templateTable_ppc.hpp
>>>>
>>>> Then all we need is confirmation that all the open platforms that Oracle
>>>> doesn't also build (aarch64 and Zero) build and run successfully after
>>>> this change.
>>>>
>>>> I will sponsor this (in case that wasn't clear) but may have to delay it
>>>> until after we sync up the hs forest with the CPU changes now in
>>>> jdk9/dev. I will rebase and handle any merging if needed.
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>> Best regards,
>>>>> Goetz.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>> Sent: Mittwoch, 20. Juli 2016 12:05
>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim Barrett
>>>>>> <kim.barrett at oracle.com>
>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>>>>>
>>>>>> On 20/07/2016 7:21 PM, Lindenmaier, Goetz wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> OK, to get this through I will add
>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH)
>>>>>>> and revert this one and only place it needs to be used in the
>>>>>> vmStructs_jvmci.cpp.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>> For the records, openJdk aarch64 has a C1 port. And yes, such
>> cleanups
>>>>>> should
>>>>>>> not be in this change.
>>>>>>
>>>>>> I did not know they had a 64-bit C1 - interesting.
>>>>>>
>>>>>>>
>>>>>>> Thanks for doing the closed changes!
>>>>>>
>>>>>> You're welcome.
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz.
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>> Sent: Mittwoch, 20. Juli 2016 11:13
>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim Barrett
>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-
>>>>>>>> dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>>>>>>>
>>>>>>>> Hi Goetz,
>>>>>>>>
>>>>>>>> On 20/07/2016 6:47 PM, Lindenmaier, Goetz wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> that's great what you are saying and just the design I would expect!
>>>>>>>>>> We did not want to have to
>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit
>> ARM"
>>>> so
>>>>>>>>>> we worked with the Open port to ensure that shared code
>> guarded
>>>> by
>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to
>>>>>> identify
>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of
>>>>>> places
>>>>>>>>>> that needed it. And sometimes we have to be careful and ensure
>>>> that
>>>>>>>>>> ifdef chains check AARCH64 before they check ARM.
>>>>>>>>>
>>>>>>>>> I think as a consequence the open AARCH port should define ARM,
>>>> too.
>>>>>>>>
>>>>>>>> I would not want to do this and certainly not as part of this change.
>>>>>>>> If/when the Aarch32 port arrives we may have to revisit this, but not
>>>>>>>> right now, please.
>>>>>>>>
>>>>>>>>> I checked the occurrences and only see three places where this
>> would
>>>>>> have
>>>>>>>>> an effect and would have to be fixed somehow:
>>>>>>>>>
>>>>>>>>> *** share/vm/jvmci/vmStructs_jvmci.cpp:
>>>>>>>>> <global>[610] #if defined(AARCH64) && !defined(ARM)
>>>>>>>>> ==> Would this break the closed port if defined?
>>>>>>>>
>>>>>>>> Yes - it refers to specific piece of code in the open aarch64 sources.
>>>>>>>>
>>>>>>>>> (This is the only place where TARGET_ARCH_aarch64 was
>> used)
>>>>>>>>>
>>>>>>>>> *** share/vm/c1/c1_LIRGenerator.cpp:
>>>>>>>>> load_item_force[253] #if !defined(ARM) && !defined(E500V2)
>>>>>>>>> ==> Would this break the open port if defined?
>>>>>>>>>
>>>>>>>>> *** share/vm/c1/c1_Runtime1.cpp:
>>>>>>>>> <global>[1154] #ifdef ARM
>>>>>>>>> ==> Would this break the open port if defined?
>>>>>>>>
>>>>>>>> I don't think the open port has C1 so it would ignore the above files
>>>>>>>> anyway.
>>>>>>>>
>>>>>>>>> All the cases below are pointless.
>>>>>>>>>
>>>>>>>>>> So what I'm suggesting is just not getting rid of those defines, but
>>>>>>>>>> keeping them so they can be used as include guards (or other
>>>>>> conditional
>>>>>>>>>> code) when needed, and where the macros are not suitable.
>>>>>>>>> I think it's quite misleading to have two defines that are 99%
>>>> equivalent.
>>>>>>>>> If we really need a special case here, you should define -
>>>> DARM_CLOSED
>>>>>>>>> or the like in your closed port. Such a name would make clear
>> what's
>>>> the
>>>>>>>>> issue. At least, only your closed port has this problem.
>>>>>>>>
>>>>>>>> I really do not want to make any changes to this - ignoring the
>> include
>>>>>>>> macro changes everything we have is working perfectly fine just the
>>>> way
>>>>>>>> the defines are. So I don't want to see this change potentially break
>>>>>>>> that through incidental changes.
>>>>>>>>
>>>>>>>> I do not see having the following is a big issue:
>>>>>>>>
>>>>>>>> -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH)
>>>>>>>> -DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH)
>>>>>>>>
>>>>>>>> It allows TARGET_ARCH_aarch64 to mean the open ARMv8 port, and
>>>>>>>> TARGET_ARCH_arm to mean whatever the owners of that define
>>>> intend
>>>>>> it to
>>>>>>>> mean. It certainly is a lot better than interpreting what the
>>>>>>>> combinations of AARCH64 and ARM mean. Keeping this removes the
>>>>>> need to
>>>>>>>> perform some of the changes as noted above.
>>>>>>>>
>>>>>>>> I'm preparing the review of the internal changes we need to
>>>> accompany
>>>>>> this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> -----
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These should not break the open port if ARM gets defined, or can
>> be
>>>>>> fixed
>>>>>>>> easily.
>>>>>>>>> ---------------------------------------------------------
>>>>>>>>>
>>>>>>>>> *** share/vm/c1/c1_LIR.cpp:
>>>>>>>>> print[1519] #elif defined(ARM)
>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade.
>>>>>>>>>
>>>>>>>>> *** os/linux/vm/os_linux.cpp:
>>>>>>>>> dll_load[1796] #elif (defined ARM)
>>>>>>>>> get_summary_cpu_info[2273] #elif defined(ARM)
>>>>>>>>> ==> Use ARM32 as after AARCH64 in if-cascade.
>>>>>>>>>
>>>>>>>>> *** share/vm/opto/matcher.cpp:
>>>>>>>>> init_first_stack_mask[558] #ifdef ARM
>>>>>>>>> ==> Should be ARM32 (Is under !LP64).
>>>>>>>>>
>>>>>>>>> *** share/vm/c1/c1_LIR.cpp:
>>>>>>>>> validate_type[212] ARM_ONLY(|| kindfield == cpu_register)
>>>>>>>>> validate_type[219] ARM_ONLY(|| kindfield == cpu_register)
>>>>>>>>> ==> Just an assertion. Will just relax the check if defined in open
>>>>>> AARCH64.
>>>>>>>>> But maybe should be guarded by __SOFTFP__.
>>>>>>>>> <global>[70] #if defined(ARM) || defined(AARCH64) ||
>>>>>>>> defined(PPC64)
>>>>>>>>> ==> Fine: ||
>>>>>>>>>
>>>>>>>>> *** share/vm/c1/c1_LIR.hpp:
>>>>>>>>> <global>[447] #if defined(SPARC) || defined(ARM) ||
>>>>>>>> defined(PPC) || defined(AARCH64)
>>>>>>>>> <global>[537] #if defined(X86) || defined(ARM) ||
>>>>>>>> defined(AARCH64)
>>>>>>>>> ==> Fine: ||
>>>>>>>>>
>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.hpp:
>>>>>>>>> defined[162] #if defined(IA32) || defined(AMD64) ||
>>>>>>>> defined(ARM)
>>>>>>>>> *** share/vm/interpreter/interpreterRuntime.cpp:
>>>>>>>>> <global>[1358] #if defined(IA32) || defined(AMD64) ||
>>>>>>>> defined(ARM)
>>>>>>>>> ==> Just defines a method which would be unused, should be fine.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These are in code not used in the open AARCH64 port:
>>>>>>>>> --------------------------------------------------
>>>>>>>>>
>>>>>>>>> *** os/bsd/vm/os_bsd.cpp:
>>>>>>>>> <global>[215] #elif defined(ARM)
>>>>>>>>>
>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp:
>>>>>>>>> <global>[102] #ifdef ARM
>>>>>>>>>
>>>>>>>>> *** os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp:
>>>>>>>>> <global>[31] #ifdef ARM
>>>>>>>>>
>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp:
>>>>>>>>> <global>[102] #ifdef ARM
>>>>>>>>>
>>>>>>>>> *** os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp:
>>>>>>>>> <global>[31] #ifdef ARM
>>>>>>>>>
>>>>>>>>> *** share/vm/utilities/macros.hpp:
>>>>>>>>> <global>[434] #ifdef ARM
>>>>>>>>>
>>>>>>>>> *** os/bsd/vm/os_bsd.cpp:
>>>>>>>>> dll_load[1508] #elif (defined ARM)
>>>>>>>>> dll_load[1524] IA32, AMD64, IA64, __sparc, __powerpc__,
>>>> ARM,
>>>>>>>> S390, ALPHA, MIPS, MIPSEL, PARISC, M68K
>>>>>>>>>
>>>>>>>>> *** os/solaris/vm/os_solaris.cpp:
>>>>>>>>> dll_load[1725] #elif (defined ARM)
>>>>>>>>> dll_load[1729] IA32, AMD64, IA64, __sparc, __powerpc__,
>>>> ARM,
>>>>>>>> ARM
>>>>>>>>>
>>>>>>>>> *** os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp:
>>>>>>>>> store[164] #if !defined(ARM) && !defined(M68K)
>>>>>>>>> store_ptr[171] #if !defined(ARM) && !defined(M68K)
>>>>>>>>> add[178] #ifdef ARM
>>>>>>>>> add_ptr[190] #ifdef ARM
>>>>>>>>> xchg[230] #ifdef ARM
>>>>>>>>> xchg_ptr[253] #ifdef ARM
>>>>>>>>> cmpxchg[275] #ifdef ARM
>>>>>>>>> cmpxchg_ptr[298] #ifdef ARM
>>>>>>>>>
>>>>>>>>> *** os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp:
>>>>>>>>> add[172] #ifdef ARM
>>>>>>>>> add_ptr[184] #ifdef ARM
>>>>>>>>> xchg[224] #ifdef ARM
>>>>>>>>> xchg_ptr[247] #ifdef ARM
>>>>>>>>> cmpxchg[269] #ifdef ARM
>>>>>>>>> cmpxchg_ptr[292] #ifdef ARM
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>> Sent: Dienstag, 19. Juli 2016 23:59
>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim
>> Barrett
>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-
>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>>>>>>>>>
>>>>>>>>>> Hi Goetz,
>>>>>>>>>>
>>>>>>>>>> On 19/07/2016 10:12 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> we also have "closed ports", currently HPUX, ia64 and s390.
>>>>>>>>>>> (Parisc is gone, puh!).
>>>>>>>>>>> We basically patch all the shared changes onto the sources after
>>>>>>>>>>> getting them via our licensee channel.
>>>>>>>>>>> I think you should fix your closed port not to re-use the names of
>>>> the
>>>>>>>>>>> main openJdk platforms!
>>>>>>>>>>
>>>>>>>>>> Nobody "owns" a define of AARCH64 or ARM. We did not want to
>>>> have
>>>>>> to
>>>>>>>>>> pollute the shared sources with two sets of ifdefs for "64-bit
>> ARM"
>>>> so
>>>>>>>>>> we worked with the Open port to ensure that shared code
>> guarded
>>>> by
>>>>>>>>>> AARCH64 is suitable for both. We also ensured ARM was used to
>>>>>> identify
>>>>>>>>>> word-size agnostic code and we introduced ARM32 in a handful of
>>>>>> places
>>>>>>>>>> that needed it. And sometimes we have to be careful and ensure
>>>> that
>>>>>>>>>> ifdef chains check AARCH64 before they check ARM.
>>>>>>>>>>
>>>>>>>>>> This has all been working quite nicely, as the include guards used,
>> for
>>>>>>>>>> example, TARGET_ARCH_AARCH64 and TARGET_ARCH_ARM -
>> which
>>>>>> are
>>>>>>>>>> never
>>>>>>>>>> defined at the same time (derived from
>>>>>> HOTSPOT_TARGET_CPU_ARCH).
>>>>>>>> But
>>>>>>>>>> the
>>>>>>>>>> current changes remove those unique defines and, before the
>>>>>> HEADER_H
>>>>>>>>>> forms were introduced, tried to use simple AARCH64 and ARM as
>>>>>> include
>>>>>>>>>> guards, and that doesn't work as they are not mutually exclusive.
>>>>>>>>>>
>>>>>>>>>> So what I'm suggesting is just not getting rid of those defines, but
>>>>>>>>>> keeping them so they can be used as include guards (or other
>>>>>> conditional
>>>>>>>>>> code) when needed, and where the macros are not suitable.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> David
>>>>>>>>>> -----
>>>>>>>>>>
>>>>>>>>>>> I have no idea what hardware is addressed by your closed ports,
>>>>>>>>>>> nor how you merge sources.
>>>>>>>>>>> Is there also a port that sets
>>>>>>>>>>> -DTARGET_ARCH_arm
>>>>>>>>>>> -DARM
>>>>>>>>>>> -DARM32
>>>>>>>>>>> ?
>>>>>>>>>>>
>>>>>>>>>>> To fix this either you define
>>>>>>>>>>> #if defined(ARM) && defined(_LP64)
>>>>>>>>>>> #define ARM64
>>>>>>>>>>> #endif
>>>>>>>>>>> in macros.hpp or you set -DARM64 on the command line.
>>>>>>>>>>> Then you replace all
>>>>>>>>>>> #ifdef AARCH64
>>>>>>>>>>> by
>>>>>>>>>>> #if defined(AARCH64) || defined(ARM64)
>>>>>>>>>>> or maybe it suffices altogether f you replace
>>>>>>>>>>> #ifdef AARCH64
>>>>>>>>>>> by
>>>>>>>>>>> #if defined(AARCH64) || defined(ARM)
>>>>>>>>>>>
>>>>>>>>>>> For ppc, when we did the port we knew (and that's all we knew)
>>>>>>>>>>> that you have a 32-bit port. Therefore we set up these macros
>>>>>>>>>>> as on x86, where there is one for the arch (X86) and two for
>>>>>> LP64/!LP64
>>>>>>>>>>> (IA32, AMD64). This allowed to separate code for the closed port
>>>>>>>>>>> (guarded by PPC32), the open port (PPC64) and shared for both
>>>>>> (PPC).
>>>>>>>>>>>
>>>>>>>>>>> But I don't think it is necessary to do any further changes now,
>>>>>> assuming
>>>>>>>>>>> my change works for you as I adapted it. So we're all set I guess!
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Goetz.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 1:23 PM
>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim
>>>> Barrett
>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-
>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>>>>>>>>>>>
>>>>>>>>>>>> On 19/07/2016 7:08 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This
>>>> kind
>>>>>> of
>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open
>>>> Aarch64
>>>>>>>> port
>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the
>> Open
>>>>>> port
>>>>>>>>>> use
>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just
>>>>>>>> something
>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, I think TARGET_ARCH_xxx always was xxx.
>>>>>>>>>>>>> And I'm uneasy that it is no more. How do you handle that?
>> You
>>>>>> have
>>>>>>>> to
>>>>>>>>>>>>> check every AARCH change by RedHat against your closed
>> port?
>>>>>>>>>>>>
>>>>>>>>>>>> The sources for the two ports are distinct so the only place we
>>>> have
>>>>>> to
>>>>>>>>>>>> have a convention is in shared code that has CPU specific stuff
>> and
>>>> in
>>>>>>>>>>>> the build files.
>>>>>>>>>>>>
>>>>>>>>>>>> The open Aarch64 port sets (among others):
>>>>>>>>>>>> -DTARGET_ARCH_aarch64
>>>>>>>>>>>> -DAARCH64
>>>>>>>>>>>>
>>>>>>>>>>>> the closed port sets
>>>>>>>>>>>>
>>>>>>>>>>>> -DTARGET_ARCH_arm
>>>>>>>>>>>> -DARM
>>>>>>>>>>>> -DAARCH64
>>>>>>>>>>>>
>>>>>>>>>>>> so it is the value of TARGET_ARCH_xxx that distinguishes them.
>>>>>>>>>> Whenever
>>>>>>>>>>>> you saw TARGET_ARCH_arm in open shared code it is/was
>>>> referring
>>>>>> to
>>>>>>>>>> our
>>>>>>>>>>>> closed port; and TARGET_ARCH_aarch64 refers to the open
>>>> Aarch64
>>>>>>>> port.
>>>>>>>>>>>>
>>>>>>>>>>>> Of course TARGET_OS_ARCH_linux_xxx is in the same position.
>>>>>>>>>>>>
>>>>>>>>>>>> We need to keep a clear distinction. Using the combination of
>>>>>> AARCH64
>>>>>>>>>>>> and ARM is not so clear.
>>>>>>>>>>>>
>>>>>>>>>>>> You could easily have similar issues with other port groups - eg
>>>> ppc64
>>>>>>>>>>>> vs ppc32 vs ppcle.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>> I don't know about the closed stuff, but aarch came up
>> recently,
>>>>>> and
>>>>>>>>>>>>> before that it sure was equivalent. And it still is the case for
>>>>>> openJDK.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Below output is grepped out of the
>> make/<os>/platform_<cpu>
>>>>>> files
>>>>>>>> in
>>>>>>>>>>>>> jdk8/hotspot, and none of the cpu/arch names are defined
>>>> twice.
>>>>>>>>>>>>> Zero is an exception I guess, as it's no real cpu/arch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>
>>>>>>>>>>>>> sysdefs = -DAIX -DPPC64
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -
>>>> D_GNU_SOURCE
>>>>>> -
>>>>>>>>>>>> DAMD64
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -DSPARC_WORKS -
>>>> D_GNU_SOURCE
>>>>>> -
>>>>>>>>>> DIA32
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA64 -
>>>>>> DCC_INTERP
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -DSPARC
>>>>>>>>>>>>> sysdefs = -D_ALLBSD_SOURCE -D_GNU_SOURCE -
>> DCC_INTERP -
>>>>>>>> DZERO -
>>>>>>>>>>>> D at ZERO_ARCHDEF@ -
>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\"
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DAMD64
>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -
>>>> DAMD64
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA32
>>>>>>>>>>>>> sysdefs = -DLINUX -DSPARC_WORKS -D_GNU_SOURCE -
>> DIA32
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DIA64 -DCC_INTERP
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DPPC64
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DSPARC
>>>>>>>>>>>>> sysdefs = -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -
>>>>>>>>>>>> D at ZERO_ARCHDEF@ -
>> DZERO_LIBARCH=\"@ZERO_LIBARCH@\"
>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DAMD64
>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DAMD64
>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DIA32
>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DIA32
>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC
>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC
>>>>>>>>>>>>> sysdefs = -DSOLARIS -DSPARC_WORKS -DSPARC
>>>>>>>>>>>>> sysdefs = -DSOLARIS -D_GNU_SOURCE -DSPARC
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 10:47 AM
>>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Kim
>>>>>> Barrett
>>>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-
>> runtime-
>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform files.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks Goetz. Will get back to you asap if there are any
>> further
>>>>>>>> issues,
>>>>>>>>>>>>>> but the incremental changes look okay.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19/07/2016 5:47 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I added macros for C headers:
>>>>>>>>>>>>>>> CPU_HEADER_H() etc.
>>>>>>>>>>>>>>> and fixed the other issues mentioned by David and Coleen
>> in
>>>> this
>>>>>>>> new
>>>>>>>>>>>>>> webrev:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-
>>>>>>>>>>>> newPfmIncl/webrev.03/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I also added comments that AARCH64 and ARM are defined
>>>>>>>>>>>>>>> at the same time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Further I edited vmStructs_jvmci.cpp to
>>>>>>>>>>>>>>> #if defined(AARCH64) && !defined(ARM)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm still uneasy that TARGET_ARCH_xxx is now just xxx. This
>>>> kind
>>>>>> of
>>>>>>>>>>>>>> workaround is obscure - you have to know that the Open
>>>> Aarch64
>>>>>>>> port
>>>>>>>>>>>>>> defines AARCH64 but not ARM and so that code is for the
>> Open
>>>>>> port
>>>>>>>>>> use
>>>>>>>>>>>>>> only. There's no issue for the OS defines, but I wonder - just
>>>>>>>> something
>>>>>>>>>>>>>> to thing about - if TARGET_ARCH_xxx should be restored?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> My incremental changes are in this patch:
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8161259-
>>>>>>>>>>>>>> newPfmIncl/webrev.03/incremental_changes.patch
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>> Sent: Tuesday, July 19, 2016 3:37 AM
>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
>> Kim
>>>>>>>> Barrett
>>>>>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-
>>>> runtime-
>>>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including platform
>> files.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 18/07/2016 10:23 PM, David Holmes wrote:
>>>>>>>>>>>>>>>>> On 18/07/2016 10:18 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'll introduce CPU_HEADER_H, but actually this should
>> be
>>>>>> fixed
>>>>>>>>>>>>>>>>>> in the closed code.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Bear with me, I'm trying to figure out how to do just that.
>> :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The use of HOTSPOT_TARGET_CPU_DEFINE as the value
>>>> for
>>>>>> the
>>>>>>>>>> ifdef
>>>>>>>>>>>> is
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> going to work for our closed ports, unless I change that
>>>> value
>>>>>> to
>>>>>>>>>>>> match
>>>>>>>>>>>>>>>>> the open naming scheme. But that in turn will lead to
>> other
>>>>>>>>>> problems
>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>> we also need that value the way it is currently defined.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll tackle this again in the morning when I'm fresher.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sorry but this really does need the CPU_HEADER_H
>> macro.
>>>> In
>>>>>>>>>> general
>>>>>>>>>>>> you
>>>>>>>>>>>>>>>> can't just replace:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #ifdef TARGET_ARCH_abc
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #ifdef abc
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> because the "abc"'s may not be mutually exclusive. In our
>>>> case
>>>>>>>> ARM
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> AARCH64 are both defined and are both needed. In
>> contrast
>>>>>>>>>>>>>>>> TARGET_ARCH_abc is uniquely defined as "abc" is chosen
>> to
>>>>>>>>>> represent
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> architecture in this context.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>> From: David Holmes
>> [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 14:13
>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>;
>>>>>> Kim
>>>>>>>>>> Barrett
>>>>>>>>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net;
>> hotspot-
>>>>>>>> runtime-
>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including
>> platform
>>>>>> files.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18/07/2016 8:21 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it
>> appends
>>>>>> .hpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg
>>>> CPU_HEADER_H,
>>>>>>>> that
>>>>>>>>>>>>>>>> appends.h
>>>>>>>>>>>>>>>>>>>>>>> instead?
>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be
>>>> used
>>>>>>>> only
>>>>>>>>>>>> once.
>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do
>> it
>>>> to
>>>>>> get
>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> similar everywhere.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names
>> need
>>>> not
>>>>>>>> be
>>>>>>>>>>>>>> mutually
>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this
>> needs
>>>> to
>>>>>> be
>>>>>>>> an
>>>>>>>>>> if-
>>>>>>>>>>>>>> else
>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-)
>>>>>>>>>>>>>>>>>>>> They should be mutually exclusive, as they are set in
>>>>>>>>>>>>>> CompileJvm.gmk
>>>>>>>>>>>>>>>>>>>> in the same statement as the
>> INCLUDE_SUFFIX_CPU:
>>>>>>>>>>>>>>>>>>>> -D$(HOTSPOT_TARGET_CPU_DEFINE)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Unfortunately we also have -DARM coming in from
>> the
>>>>>> closed
>>>>>>>>>> part
>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> spec.gmk as we don't use AARCH64 for our port. So
>> we
>>>> get
>>>>>>>> both
>>>>>>>>>>>>>> defined
>>>>>>>>>>>>>>>>>>> and try to include two platform files.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Not sure how to try and resolve this yet. Trying to
>>>>>> understand
>>>>>>>>>> what
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> role of HOTSPOT_TARGET_CPU_DEFINE is intended to
>>>> be,
>>>>>> as
>>>>>>>> we
>>>>>>>>>>>> are
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> overriding it for our port - which I think is the current
>>>>>> problem,
>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>> changing it may break something else.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>> Goetz
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>> From: David Holmes
>>>> [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 11:06
>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>> <goetz.lindenmaier at sap.com>;
>>>>>>>> Kim
>>>>>>>>>>>> Barrett
>>>>>>>>>>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net;
>>>> hotspot-
>>>>>>>>>> runtime-
>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including
>>>> platform
>>>>>>>> files.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 18/07/2016 5:15 PM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>>>>>> Hi David,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> thanks for looking at all these files in more detail!
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes
>>>>>> [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>>>>>>>>> Sent: Montag, 18. Juli 2016 08:03
>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>> <goetz.lindenmaier at sap.com>;
>>>>>>>>>> Kim
>>>>>>>>>>>>>> Barrett
>>>>>>>>>>>>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net;
>>>>>> hotspot-
>>>>>>>>>> runtime-
>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including
>>>>>> platform
>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Goetz,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Again thanks for tackling this!
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 10:17 PM, Lindenmaier, Goetz
>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I made a new webrev:
>>>>>>>>>>>>>>>>>>>>>>>> - '_' is added in makefile
>>>>>>>>>>>>>>>>>>>>>>>> - uses Kim's macros
>>>>>>>>>>>>>>>>>>>>>>>> - macros are capitalized
>>>>>>>>>>>>>>>>>>>>>>>> - more comments in macros.hpp
>>>>>>>>>>>>>>>>>>>>>>>>
>> http://cr.openjdk.java.net/~goetz/wr16/8161259-
>>>>>>>>>>>>>>>>>>>>> newPfmIncl/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Generally looks okay, a couple of clarifications
>> and
>>>>>>>>>> comments
>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> make/gensrc/GensrcAdlc.gmk
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> So the change from HOTSPOT_TARGET_CPU to
>>>>>>>>>>>>>>>>>>>>>>> HOTSPOT_TARGET_CPU_ARCH only
>>>>>>>>>>>>>>>>>>>>>>> affects the generated files right?
>>>>>>>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>>>>>>>> For our closed ports we still have
>>>>>>>>>>>>>>>>>>>>>>> the _32/_64 source files in a common arch
>>>> directory,
>>>>>> but
>>>>>>>> I
>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>>>>>>> that needs to be reflected in the generated files.
>>>>>> (Sorry I
>>>>>>>>>>>>>>>>>>>>>>> haven't had
>>>>>>>>>>>>>>>>>>>>>>> the time yet to apply this patch and see what
>> needs
>>>> to
>>>>>>>> be
>>>>>>>>>>>>>> changed
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> closed side - but will start that once I send this
>> :).)
>>>>>>>>>>>>>>>>>>>>>> If I run plain configure, it generates a directory
>> that
>>>> has
>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> word size
>>>>>>>>>>>>>>>>>>>>>> in it's name:
>>>>>>>>>>>>>>>>>>>>>> linux-x86_64-normal-server-release
>>>>>>>>>>>>>>>>>>>>>> If I configure --with-target-bits=32, it builds to
>>>>>>>>>>>>>>>>>>>>>> linux-x86-normal-server-release,
>>>>>>>>>>>>>>>>>>>>>> so I figured this should be fine.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yes generated files are fine.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hmm but this change assumes no more _32/_64
>>>>>> header
>>>>>>>>>> files if
>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>> read it
>>>>>>>>>>>>>>>>>>>>>>> right ?? So I'll need a common file that dispatches
>>>>>>>> internally
>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>> 32-bit and 64-bit.
>>>>>>>>>>>>>>>>>>>>>> Yes.
>>>>>>>>>>>>>>>>>>>>>> There is a single file in cpu/x86 where this did not
>>>> hold:
>>>>>>>>>>>>>>>>>>>>>> stubRoutines
>>>>>>>>>>>>>>>>>>>>>> But this was rather small. And there anyways was
>> a
>>>>>>>> common
>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>> that was included in both.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> src/os/posix/vm/os_posix.cpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I'm wondering if we can use a similar trick to
>> avoid
>>>> this
>>>>>>>> kind
>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>> switch(OS) statement:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> #ifdef TARGET_OS_FAMILY_linux
>>>>>>>>>>>>>>>>>>>>>>> Linux::ucontext_set_pc(ctx, pc);
>>>>>>>>>>>>>>>>>>>>>>> #elif defined(TARGET_OS_FAMILY_solaris)
>>>>>>>>>>>>>>>>>>>>>>> Solaris::ucontext_set_pc(ctx, pc);
>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ie something like:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> SUB(TARGET_OS)::ucontext_set_pc(ctx, pc);
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ? :)
>>>>>>>>>>>>>>>>>>>>>> Hmm, I had to add the '_' to the string in
>>>> TARGET_SO...
>>>>>>>>>>>>>>>>>>>>>> Actually I think the implementation should be
>> moved
>>>> to
>>>>>>>>>>>>>>>>>>>>>> os_linux.cpp/os_bsd.cpp etc.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/code/nmethod.cpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Not clear why the platform include can simply be
>>>>>> elided
>>>>>>>>>> here ??
>>>>>>>>>>>>>>>>>>>>>> It already includes code/nativeInst.hpp, which is
>> the
>>>>>>>>>> umbrella
>>>>>>>>>>>>>> header
>>>>>>>>>>>>>>>>>>>>>> for all the platform files.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/jvmci/jvmciRuntime.cpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Shouldn't:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ! #endif // !LP64
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> be:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ! #endif // LP64
>>>>>>>>>>>>>>>>>>>>>> Well, it ends the #else part ... but fixed anyways.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jni_md.h
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/prims/jvm.h
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> // Can not use CPU_HEADER() macro, as it
>> appends
>>>>>> .hpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> can we not define a second form, eg
>>>> CPU_HEADER_H,
>>>>>>>> that
>>>>>>>>>>>>>>>> appends.h
>>>>>>>>>>>>>>>>>>>>>>> instead?
>>>>>>>>>>>>>>>>>>>>>> I'll need one for OS, one for CPU, and each will be
>>>> used
>>>>>>>> only
>>>>>>>>>>>> once.
>>>>>>>>>>>>>>>>>>>>>> So I figured not to do it. But probably I should do
>> it
>>>> to
>>>>>> get
>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>> similar everywhere.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We actually need this as the simple arch names
>> need
>>>> not
>>>>>>>> be
>>>>>>>>>>>>>> mutually
>>>>>>>>>>>>>>>>>>>>> exclusive - eg arm and aarch64. Otherwise this
>> needs
>>>> to
>>>>>> be
>>>>>>>> an
>>>>>>>>>> if-
>>>>>>>>>>>>>> else
>>>>>>>>>>>>>>>>>>>>> construct in the correct order. ;-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/os.hpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Should we convert setjmp.h include to:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> #ifndef _WINDOWS
>>>>>>>>>>>>>>>>>>>>>>> #include <setjmp.h>
>>>>>>>>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>>>>>>>> #ifdef __APPLE__
>>>>>>>>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>>>>>>>> #endif
>>>>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>>>> Fixed.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> BTW: why is it _WINDOWS instead of
>> WINDOWS? Is
>>>>>> that
>>>>>>>>>>>> coming
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> compiler itself?
>>>>>>>>>>>>>>>>>>>>>> I wondered about that, too. Therefore I defined
>>>>>>>> WINDOWS
>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> prototype webrev. Then I saw that our build is
>>>> defining
>>>>>> -
>>>>>>>>>>>>>>>> D_WINDOWS
>>>>>>>>>>>>>>>>>>>>> *and* -DWIN32,
>>>>>>>>>>>>>>>>>>>>>> and removed it again using _WINDOWS instead.
>>>>>>>>>>>>>>>>>>>>>> Eventually both should be replaced by WINDOWS,
>>>> but
>>>>>> not
>>>>>>>> in
>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>> change.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>> src/os_cpu/aix_ppc/vm/bytes_aix_ppc.inline.hpp
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Don't understand the point of this:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 28 #if defined(VM_LITTLE_ENDIAN)
>>>>>>>>>>>>>>>>>>>>>>> 29 // Aix is not littel endian.
>>>>>>>>>>>>>>>>>>>>>>> 30 #endif // VM_LITTLE_ENDIAN
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> also typo: littel
>>>>>>>>>>>>>>>>>>>>>> I just copied the linux_ppc code and removed the
>>>>>> unused
>>>>>>>>>>>>>>>>>>> implementation.
>>>>>>>>>>>>>>>>>>>>>> I wanted to document why there is this empty
>> file.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>>> From: David Holmes
>>>>>>>> [mailto:david.holmes at oracle.com]
>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Freitag, 15. Juli 2016 11:11
>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>> <goetz.lindenmaier at sap.com>;
>>>>>>>>>> Kim
>>>>>>>>>>>>>>>> Barrett
>>>>>>>>>>>>>>>>>>>>>>>>> <kim.barrett at oracle.com>
>>>>>>>>>>>>>>>>>>>>>>>>> Cc: hotspot-compiler-dev at openjdk.java.net;
>>>>>>>> hotspot-
>>>>>>>>>>>> runtime-
>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify including
>>>>>>>> platform
>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 15/07/2016 5:30 PM, Lindenmaier, Goetz
>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> HI Kim,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> thanks for this version of the macros, it's
>>>> working
>>>>>> on
>>>>>>>> all
>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> platforms
>>>>>>>>>>>>>>>>>>>>>>>>>> I can build.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, I would prefer having the '_' in the
>>>>>> macros
>>>>>>>> and
>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>>>>>>>>>>> command line. This way, parts of the name
>>>>>>>>>> construction
>>>>>>>>>>>> are
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>> CompileJvm.gmk, other parts are in
>>>> macros.hpp.
>>>>>> But
>>>>>>>>>>>>>>>> constructing
>>>>>>>>>>>>>>>>>>>>>>>>>> the search path is also in the makefile, and
>> uses
>>>>>> the
>>>>>>>>>> very
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>> string
>>>>>>>>>>>>>>>>>>>>>>>>>> as the file suffixes. (Without '_', one could
>>>> include
>>>>>>>> that
>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> macro,
>>>>>>>>>>>>>>>>>>>>>>> too.)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But overall, I consider this a detail and am as
>>>> fine
>>>>>>>> with
>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>>>>>>>> solution
>>>>>>>>>>>>>>>>>>>>>>>>>> as with the SUB() macros. What is better is
>> that
>>>>>> the
>>>>>>>>>> linux=1
>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>>>>>>>>>>>>>> problems are avoided.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Any more opinions whether the macros
>> should
>>>> be
>>>>>>>>>> upper
>>>>>>>>>>>> case?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yeah they probably should be.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>>>>>>>> Goetz.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Kim Barrett
>>>>>> [mailto:kim.barrett at oracle.com]
>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Donnerstag, 14. Juli 2016 23:20
>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
>>>>>>>>>> <goetz.lindenmaier at sap.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Haley <aph at redhat.com>;
>>>> hotspot-
>>>>>>>>>> compiler-
>>>>>>>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net; hotspot-runtime-
>>>>>>>>>>>>>>>> dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(L): 8161259: Simplify
>> including
>>>>>>>>>> platform
>>>>>>>>>>>>>> files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 14, 2016, at 3:18 PM, Lindenmaier,
>>>> Goetz
>>>>>>>>>>>>>>>>>>>>>>>>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi everybody,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> please take into account that these
>> macros
>>>> are
>>>>>>>> only
>>>>>>>>>>>> used
>>>>>>>>>>>>>>>> within
>>>>>>>>>>>>>>>>>>> 20
>>>>>>>>>>>>>>>>>>>>>>> lines
>>>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the file macro.hpp. The code everybody
>>>> needs
>>>>>> to
>>>>>>>>>>>>>> understand
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> #include cpu_header(bytes)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> which, in this example, is in file bytes.hpp
>>>> and
>>>>>>>>>> expands to
>>>>>>>>>>>>>>>>>>>>>>>>>>> bytes_<cpu>.hpp.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are six of these, for cpu/os/os_cpu
>>>>>>>>>>>>>> and .hpp/.inline.hpp.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I really would appreciate if I don't have to
>>>>>> spend
>>>>>>>> days
>>>>>>>>>>>>>>>>>>>>>>>>>>>> editing the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 12 lines that use SUB().
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> @Kim
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm working on the s390 port, and posted
>> my
>>>>>>>> current
>>>>>>>>>>>>>> progress
>>>>>>>>>>>>>>>>>>>>> claiming
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the biggest shared change I need to
>> do
>>>> is
>>>>>>>> adding
>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> #includes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-
>>>>>>>>>>>> dev/2016-
>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023782.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This arose the discussion about the
>> includes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Later I posted a prototype of what Volker
>>>>>>>> proposed
>>>>>>>>>> in
>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>> discussion
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to that thread:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-
>>>>>>>>>>>> dev/2016-
>>>>>>>>>>>>>>>>>>>>>>>>>>> July/023934.html
>>>>>>>>>>>>>>>>>>>>>>>>>>>> which I now turned into a RFR.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I think I see what happened to the email
>>>> thread
>>>>>> for
>>>>>>>>>> me; it
>>>>>>>>>>>>>> looks
>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>> Andrew’s replies went to hotspot-
>> compiler-
>>>> dev
>>>>>> but
>>>>>>>>>> not
>>>>>>>>>>>>>>>> hotspot-
>>>>>>>>>>>>>>>>>>>>>>> runtime-
>>>>>>>>>>>>>>>>>>>>>>>>>>> dev,
>>>>>>>>>>>>>>>>>>>>>>>>>>> and I was not subscribed to the compiler list
>>>> this
>>>>>>>>>> morning.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I like the idea, just quibbling over details.
>> I've
>>>>>> only
>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed
>>>>>>>>>>>>>>>>>>>>>>>>>>> macros.hpp so far; the rest looks like it can
>>>> wait
>>>>>>>> until
>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> details
>>>>>>>>>>>>>>>>>>>>>>>>>>> are settled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> -----------------------------------------------------
>> ---
>>>> ---
>>>>>> ----
>>>>>>>> ---
>>>>>>>>>> ----
>>>>>>>>>>>> ---
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/utilities/macros.hpp
>>>>>>>>>>>>>>>>>>>>>>>>>>> 470 // Helper macros to workaround
>> existing
>>>>>>>> #defines
>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> spoil
>>>>>>>>>>>>>>>>>>>>>>>>>>> 471 // the macro expansion. Detected so
>> far:
>>>>>>>> linux=1,
>>>>>>>>>>>>>> sparc=1.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> This issue can be dodged by making the
>>>> leading
>>>>>>>>>>>> underscore
>>>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> expansion for INCLUDE_SUFFIX_*, e.g. in
>>>>>>>>>>>>>>>>>>>>> make/lib/CompileJvm.gmk,
>>>>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>>>> instead
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 66 JVM_CFLAGS_TARGET_DEFINES += \
>>>>>>>>>>>>>>>>>>>>>>>>>>> 67 -
>>>>>>>>>> DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS)
>>>>>>>>>>>> \
>>>>>>>>>>>>>>>>>>>>>>>>>>> 68 -
>>>>>>>>>>>>>>>>>>>
>>>>>> DINCLUDE_SUFFIX_CPU=_$(HOTSPOT_TARGET_CPU_ARCH)
>>>>>>>>>>>>>>>>>>>>> \
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Note the insertion of leading "_" for the
>>>> values.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Then the whole macro block can be written
>> as
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_stem(basename)
>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename,
>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_stem(basename)
>>>>>>>>>>>>>>>> PASTE_TOKENS(basename,
>>>>>>>>>>>>>>>>>>>>>>>>>>> INCLUDE_SUFFIX_OS)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_stem(basename)
>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(basename,
>>>>>>>>>>>>>>>>>>>>>>>>>>> PASTE_TOKENS(INCLUDE_SUFFIX_OS,
>>>>>>>>>>>>>> INCLUDE_SUFFIX_CPU))
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header(basename)
>>>>>>>>>>>>>>>>>>>>>>>>> XSTR(cpu_header_stem(basename).hpp)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define cpu_header_inline(basename)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> XSTR(cpu_header_stem(basename).inline.hpp)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header(basename)
>>>>>>>>>>>>>>>>>>>>>>> XSTR(os_header_stem(basename).hpp)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_header_inline(basename)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> XSTR(os_header_stem(basename).inline.hpp)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header(basename)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XSTR(os_cpu_header_stem(basename).hpp)
>>>>>>>>>>>>>>>>>>>>>>>>>>> #define os_cpu_header_inline(basename)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> XSTR(os_cpu_header_stem(basename).inline.hpp)
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> And SUB is no longer used...
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If some future build system wants brackets
>>>>>> instead
>>>>>>>> of
>>>>>>>>>>>>>>>>>>>>>>>>>>> strings, just
>>>>>>>>>>>>>>>>>>>>>>>>>>> replace XSTR(...) with <...>.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> We lose if _linux or _sparc (for example)
>> are
>>>>>>>> defined,
>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>>>>>>>>> that's
>>>>>>>>>>>>>>>>>>> true
>>>>>>>>>>>>>>>>>>>>>>>>>>> for the webrev.01 code too. But note that
>>>>>>>> underscore
>>>>>>>>>>>>>>>> followed
>>>>>>>>>>>>>>>>>>> by a
>>>>>>>>>>>>>>>>>>>>>>>>>>> lowercase letter is not in the reserved word
>>>>>> pattern
>>>>>>>>>> for
>>>>>>>>>>>>>> C/C++.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> BTW, my preference would be to use
>>>> uppercase
>>>>>> for
>>>>>>>>>> the
>>>>>>>>>>>>>> macro
>>>>>>>>>>>>>>>>>>>>> names.
>>>>>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>>>>>>>>> don't know what others think about that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> -----------------------------------------------------
>> ---
>>>> ---
>>>>>> ----
>>>>>>>> ---
>>>>>>>>>> ----
>>>>>>>>>>>> ---
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
More information about the hotspot-runtime-dev
mailing list