RFR(M): 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH

David Holmes david.holmes at oracle.com
Wed Jun 11 02:45:58 UTC 2014

Hi Mikael,

This seems a reasonable proposal to me. We have an over-abundance of 
"arch" variables and values, so reducing that is a good aim.

As you note the main flow-on effect here is that the hotspot makefiles 
have to be updated for the cases where OPENJDK_TARGET_CPU_ARCH and 
OPENJDK_TARGET_CPU_LEGACY differ so that it still sets LIBARCH, 
BUILDARCH, SRCARCH correctly. I think only x86 has that issue.

Wouldn't it be nice if we could get rid of i386, i586, i686 etc both 
internally and in the build artifacts and bundles!


On 11/06/2014 10:11 AM, Mikael Vidstedt wrote:
> All,
> I need some feedback and comments on the below fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8046471
> Webrev:
> http://cr.openjdk.java.net/~mikael/webrevs/8046471/webrev.00/webrev/
> Background:
> When configuring the hotspot build the build system sets up the ARCH
> variable to reflect the target cpu. Currently the value is initialized
> to OPENJDK_TARGET_CPU_LEGACY, which is the internal legacy cpu name. For
> example, on x86 64-bit this is amd64 on linux (but x86_64 on mac). The
> goal in the new (JDK) build system is to have the "legacy" value
> gradually removed in favor of the other variables.
> Discussion:
> The two candidate variables to base ARCH on are as far as I can tell
> OPENJDK_TARGET_CPU_ARCH is the more "stable" one, with a single, well
> defined value per cpu family { arm, ppc, s390, sparc, x86 }. Together
> with ARCH_DATA_MODEL/LP64 that information should be enough for the
> Hotspot build system to do its thing. Note: ARCH is currently ignored on
> solaris and bsd - it's overridden at the top of the respective
> make/<os>/makefiles/defs.make files.
> Before I go too far with this though I'd like to get some feedback on
> whether or not this is the right approach and what the exact value
> should be. Depending on the outcome of that the Hotspot build system may
> have to be updated for some platforms to support the new value(s).
> Thanks,
> Mikael

More information about the build-dev mailing list