RFR(L): 8161259: Simplify including platform files.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Jul 27 12:25:03 UTC 2016
Hi David,
I understand it can not check whether the bug is open or closed
already. But it could compare the synopsis.
Once again, thanks for fixing this ...
Goetz.
> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Mittwoch, 27. Juli 2016 14:11
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> daniel.daugherty 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 27/07/2016 7:40 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I'm sorry, I messed this up. Thanks for looking after this.
> > In my first webrev, the bugID was correct, after that it's one off.
> > I don't know what happened.
>
> These things happen from time to time.
>
> > Should "8161258: [Win] Timer functionality is broken after JDK-8089563"
> > be reopened so that it gets a new bugID?
>
> No it was already closed.
>
> > Btw, why isn't jcheck catching this?
>
> jcheck only comes into play when the same bug ID is used with different
> changesets in a given repo. In this case the other bug is a FX bug and
> not in this repo. But the same could have happened if the bug had been
> fixed in jdk9/dev but not yet pulled down to jdk9/hs.
>
> Cheers,
> David
>
> > Best regards and sorry again,
> > Goetz.
> >
> >> -----Original Message-----
> >> From: David Holmes [mailto:david.holmes at oracle.com]
> >> Sent: Mittwoch, 27. Juli 2016 03:46
> >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.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 27/07/2016 7:38 AM, Daniel D. Daugherty wrote:
> >>> I've made some manual updates to both bugs and will keep an eye
> >>> on JDK-8161258. As it goes through it's phases I'll try to make
> >>> the same updates to JDK-8161259.
> >>
> >> Thanks Dan - much appreciated.
> >>
> >> David
> >>
> >>> Dan
> >>>
> >>>
> >>> On 7/26/16 2:21 PM, David Holmes wrote:
> >>>> The patch for this used the wrong bug ID - 8161258 instead of 8161259.
> >>>>
> >>>> Not sure what I'm going to be able to do about that :(
> >>>>
> >>>> David
> >>>> -----
> >>>>
> >>>> On 26/07/2016 11:12 AM, David Holmes wrote:
> >>>>> On 25/07/2016 3:01 PM, David Holmes wrote:
> >>>>>> This all looks good. Approval is now in place. Just waiting for final
> >>>>>> conformation this builds okay for Aarch64 folk.
> >>>>>
> >>>>> That confirmation was sent to compiler-dev so the changes have been
> >>>>> pushed.
> >>>>>
> >>>>> David
> >>>>>
> >>>>>> 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