RFR(L): 8161259: Simplify including platform files.
David Holmes
david.holmes at oracle.com
Wed Jul 27 01:46:11 UTC 2016
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