From magnus.ihse.bursie at oracle.com  Sat Jul  1 15:20:52 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sat, 1 Jul 2017 17:20:52 +0200
Subject: Result: Dissolving the build-infra project
Message-ID: <22e7630a-4270-90f5-bbd9-53b66407f2d8@oracle.com>

I proposed that the build-infra project should be dissolved. It has 
outlived it's usefulness, and it only causes confusion since people are 
unaware of the project and incorrectly send build-dev questions to this 
list. [1]

The vote for this proposal is now closed.

Yes: 4
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient 
to approve the proposal.

With this mail, I'm asking the maintainers of the OpenJDK infrastructure 
to make the build-infra repositories read-only, and to archive the 
mailing list, so that no new mails can be sent to the list.

/Magnus

[1] 
http://mail.openjdk.java.net/pipermail/build-infra-dev/2017-May/004572.html




From mark.reinhold at oracle.com  Mon Jul  3 17:52:31 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon, 03 Jul 2017 10:52:31 -0700
Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes
In-Reply-To: <5956D9D9.1010104@oracle.com>
References: <20170630213608.0A5718091A@eggemoggin.niobe.net>
 <5956D9D9.1010104@oracle.com>
Message-ID: <20170703105231.826067087@eggemoggin.niobe.net>

2017/6/30 16:08:09 -0700, jonathan.gibbons at oracle.com:
> Mark,
> 
> The font-family settings in the <dl> nodes were deliberate, and a 
> workaround for not having time to create a proper taglet for tool guides.
> 
> If you remove the style attribute, you'll see in your sample output that 
> the "Tool Guides" header is in Serif font, but the immediately following 
> "Since: "  header is in the standard Sans Serif font.
> 
> See, for example, this page:
> http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html

You're right, but the problem with placing the style attribute on the
`<dl>` elements is that it forces the `<dd>` text into the sans-serif
font.  That's fine for the tool-guide links, since they're tool names,
but it's wrong for provider descriptions, which are free text (see the
attached image).

The right fix is to repair the Javadoc stylesheet, but the expedient fix
is to tweak the style attributes just where needed, so I've updated the
patch to do the latter:

  http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
  http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)

- Mark


From jonathan.gibbons at oracle.com  Mon Jul  3 18:02:19 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 03 Jul 2017 11:02:19 -0700
Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes
In-Reply-To: <20170703105231.826067087@eggemoggin.niobe.net>
References: <20170630213608.0A5718091A@eggemoggin.niobe.net>
 <5956D9D9.1010104@oracle.com> <20170703105231.826067087@eggemoggin.niobe.net>
Message-ID: <595A86AB.4050302@oracle.com>



On 07/03/2017 10:52 AM, mark.reinhold at oracle.com wrote:
> 2017/6/30 16:08:09 -0700, jonathan.gibbons at oracle.com:
>> Mark,
>>
>> The font-family settings in the <dl> nodes were deliberate, and a
>> workaround for not having time to create a proper taglet for tool guides.
>>
>> If you remove the style attribute, you'll see in your sample output that
>> the "Tool Guides" header is in Serif font, but the immediately following
>> "Since: "  header is in the standard Sans Serif font.
>>
>> See, for example, this page:
>> http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html
> You're right, but the problem with placing the style attribute on the
> `<dl>` elements is that it forces the `<dd>` text into the sans-serif
> font.  That's fine for the tool-guide links, since they're tool names,
> but it's wrong for provider descriptions, which are free text (see the
> attached image).
>
> The right fix is to repair the Javadoc stylesheet, but the expedient fix
> is to tweak the style attributes just where needed, so I've updated the
> patch to do the latter:
>
>    http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
>    http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)
>
> - Mark

Yes, understood. I hadn't realized that "Tool Guides" had been extended 
to "Providers".

-- Jon


From jonathan.gibbons at oracle.com  Mon Jul  3 18:27:45 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 3 Jul 2017 11:27:45 -0700
Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes
In-Reply-To: <20170703105231.826067087@eggemoggin.niobe.net>
References: <20170630213608.0A5718091A@eggemoggin.niobe.net>
 <5956D9D9.1010104@oracle.com> <20170703105231.826067087@eggemoggin.niobe.net>
Message-ID: <05d43a1f-23f8-a727-4c03-3bced7097375@oracle.com>

Looks good to me.

-- Jon


On 7/3/17 10:52 AM, mark.reinhold at oracle.com wrote:
> 2017/6/30 16:08:09 -0700, jonathan.gibbons at oracle.com:
>> Mark,
>>
>> The font-family settings in the <dl> nodes were deliberate, and a
>> workaround for not having time to create a proper taglet for tool guides.
>>
>> If you remove the style attribute, you'll see in your sample output that
>> the "Tool Guides" header is in Serif font, but the immediately following
>> "Since: "  header is in the standard Sans Serif font.
>>
>> See, for example, this page:
>> http://cr.openjdk.java.net/~mr/rev/8182776/api/jdk.compiler-summary.html
> You're right, but the problem with placing the style attribute on the
> `<dl>` elements is that it forces the `<dd>` text into the sans-serif
> font.  That's fine for the tool-guide links, since they're tool names,
> but it's wrong for provider descriptions, which are free text (see the
> attached image).
>
> The right fix is to repair the Javadoc stylesheet, but the expedient fix
> is to tweak the style attributes just where needed, so I've updated the
> patch to do the latter:
>
>    http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
>    http://cr.openjdk.java.net/~mr/rev/8182776/api/ (sample output)
>
> - Mark



From Alan.Bateman at oracle.com  Mon Jul  3 19:53:59 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 3 Jul 2017 20:53:59 +0100
Subject: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes
In-Reply-To: <05d43a1f-23f8-a727-4c03-3bced7097375@oracle.com>
References: <20170630213608.0A5718091A@eggemoggin.niobe.net>
 <5956D9D9.1010104@oracle.com> <20170703105231.826067087@eggemoggin.niobe.net>
 <05d43a1f-23f8-a727-4c03-3bced7097375@oracle.com>
Message-ID: <88e099f4-5b86-c302-36d2-b716a91946bf@oracle.com>



On 03/07/2017 19:27, Jonathan Gibbons wrote:
> Looks good to me.
>
> -- Jon
Thumbs up from me too.

-Alan


From glaubitz at physik.fu-berlin.de  Tue Jul  4 09:33:04 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 4 Jul 2017 11:33:04 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
Message-ID: <20170704093304.GD28259@physik.fu-berlin.de>

On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
> I think the first three patches (hotspot-add-missing-log-header.diff,
> hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) all
> look good, thanks for fixing broken code. Consider them Reviewed by me.
> Every patch needs a corresponding issue in the bug tracker, so I went ahead
> and created:
> - https://bugs.openjdk.java.net/browse/JDK-8182163
> - https://bugs.openjdk.java.net/browse/JDK-8182164
> - https://bugs.openjdk.java.net/browse/JDK-8182165

Any chance a second maintainer can review those?

I have run the test suite as mentioned before:

> https://people.debian.org/~glaubitz/openjdk-9_9~b170-2_sparc64.new.build.gz

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From matthias.baesken at sap.com  Wed Jul  5 13:36:21 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 5 Jul 2017 13:36:21 +0000
Subject: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
Message-ID: <64495e2dba5d4d1788d101eaa6f89a3e@sap.com>

Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
  are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
  when  CDS is disabled at compile time  :


See  hotspot/make/lib/JvmFeatures.gmk  :

ifneq ($(call check-jvm-feature, cds), true)
  JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0



However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in


share/vm/prims/jvmtiRedefineClasses.cpp
share/vm/memory/universe.cpp

(also some other places)


Should I prepare a change and add the compile-time guard at the places where missing as well ?

Best regards, Matthias


From thomas.stuefe at gmail.com  Wed Jul  5 17:26:07 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 5 Jul 2017 19:26:07 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170704093304.GD28259@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
Message-ID: <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>

Hi Adrian,

Changes look fine to me. I cannot build and test though, do not have a
sparc linux machine.

Kind Regards, Thomas

On Tue, Jul 4, 2017 at 11:33 AM, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:

> On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
> > I think the first three patches (hotspot-add-missing-log-header.diff,
> > hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff)
> all
> > look good, thanks for fixing broken code. Consider them Reviewed by me.
> > Every patch needs a corresponding issue in the bug tracker, so I went
> ahead
> > and created:
> > - https://bugs.openjdk.java.net/browse/JDK-8182163
> > - https://bugs.openjdk.java.net/browse/JDK-8182164
> > - https://bugs.openjdk.java.net/browse/JDK-8182165
>
> Any chance a second maintainer can review those?
>
> I have run the test suite as mentioned before:
>
> > https://people.debian.org/~glaubitz/openjdk-9_9~b170-2_
> sparc64.new.build.gz
>
> Thanks,
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


From glaubitz at physik.fu-berlin.de  Wed Jul  5 17:27:12 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 5 Jul 2017 19:27:12 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
Message-ID: <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>

On 07/05/2017 07:26 PM, Thomas St?fe wrote:
> Changes look fine to me. I cannot build and test though, do not have a sparc linux machine.

We have a fast SPARC T5 running Debian unstable available and I could
create an account for you if you're interested.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From thomas.stuefe at gmail.com  Wed Jul  5 17:37:42 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 5 Jul 2017 19:37:42 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
 <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
Message-ID: <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>

On Wed, Jul 5, 2017 at 7:27 PM, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:

> On 07/05/2017 07:26 PM, Thomas St?fe wrote:
> > Changes look fine to me. I cannot build and test though, do not have a
> sparc linux machine.
>
> We have a fast SPARC T5 running Debian unstable available and I could
> create an account for you if you're interested.
>
> Adrian
>
>
Nah, I believe you :) Changes are trivial enough.

..Thomas


> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


From glaubitz at physik.fu-berlin.de  Wed Jul  5 17:39:10 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Wed, 5 Jul 2017 19:39:10 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
 <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
 <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>
Message-ID: <78dbbda5-f3ea-009e-3989-95a2292a0a46@physik.fu-berlin.de>

On 07/05/2017 07:37 PM, Thomas St?fe wrote:
> Nah, I believe you :) Changes are trivial enough.

OK. So we're good to merge then?

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From thomas.stuefe at gmail.com  Wed Jul  5 19:23:12 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 05 Jul 2017 19:23:12 +0000
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <78dbbda5-f3ea-009e-3989-95a2292a0a46@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
 <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
 <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>
 <78dbbda5-f3ea-009e-3989-95a2292a0a46@physik.fu-berlin.de>
Message-ID: <CAA-vtUzd-H7fM6JfDAL7fT6q9gL4d7DVy_zE-6gEmUbGsVupHA@mail.gmail.com>

On Wed 5. Jul 2017 at 19:39, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:

> On 07/05/2017 07:37 PM, Thomas St?fe wrote:
> > Nah, I believe you :) Changes are trivial enough.
>
> OK. So we're good to merge then?
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaubitz at debian.org
> `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
Yes, you now have two reviewers. But for these changes (hotspot) you need a
sponsor, which needs to be an Oracle employee, which I am not.

Maybe Eric could sponsor the change?

Best regards, Thomas


From ioi.lam at oracle.com  Wed Jul  5 20:45:57 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 5 Jul 2017 13:45:57 -0700
Subject: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
In-Reply-To: <64495e2dba5d4d1788d101eaa6f89a3e@sap.com>
References: <64495e2dba5d4d1788d101eaa6f89a3e@sap.com>
Message-ID: <a6a93746-8b96-de44-82df-48ec5d48e0ef@oracle.com>

Hi Matthias,

We don't use INCLUDE_CDS everywhere so we can avoid cluttering the code. 
In many cases, functions called inside if (UseSharedSpaces) are declared 
to have empty bodies. E.g.,

void VM_RedefineClasses::doit() {
   Thread *thread = Thread::current();

   if (UseSharedSpaces) {
     // Sharing is enabled so we remap the shared readonly space to
     // shared readwrite, private just in case we need to redefine
     // a shared class. We do the remap during the doit() phase of
     // the safepoint to be safer.
     if (!MetaspaceShared::remap_shared_readonly_as_readwrite()) {
       log_info(redefine, class, load)("failed to remap shared readonly 
space to readwrite, private");
       _res = JVMTI_ERROR_INTERNAL;
       return;
     }
   }

class MetaspaceShared {
   static bool remap_shared_readonly_as_readwrite() NOT_CDS_RETURN_(true);


So hopefully the C++ compile will just elide all the code inside the if 
(!...) branch (also also the check for UseSharedSpaces). There may be a 
few places where we should have added #if INCLUDE_CDS. For example, 
InstanceKlass::restore_unshareable_info.

We are regularly building the minimal VM which doesn't have INCLUDE_CDS. 
So it looks like the VM will be built correctly when INCLUDE_CDS is not 
specified, but it probably has a bit of dead code.

Are you mainly trying to reduce the size of libjvm when CDS is not enabled?

Thanks
- Ioi


On 7/5/17 6:36 AM, Baesken, Matthias wrote:
> Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
>    are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
>    when  CDS is disabled at compile time  :
>
>
> See  hotspot/make/lib/JvmFeatures.gmk  :
>
> ifneq ($(call check-jvm-feature, cds), true)
>    JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0
>
>
>
> However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in
>
>
> share/vm/prims/jvmtiRedefineClasses.cpp
> share/vm/memory/universe.cpp
>
> (also some other places)
>
>
> Should I prepare a change and add the compile-time guard at the places where missing as well ?
>
> Best regards, Matthias



From erik.helin at oracle.com  Thu Jul  6 12:55:53 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 6 Jul 2017 14:55:53 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <CAA-vtUzd-H7fM6JfDAL7fT6q9gL4d7DVy_zE-6gEmUbGsVupHA@mail.gmail.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
 <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
 <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>
 <78dbbda5-f3ea-009e-3989-95a2292a0a46@physik.fu-berlin.de>
 <CAA-vtUzd-H7fM6JfDAL7fT6q9gL4d7DVy_zE-6gEmUbGsVupHA@mail.gmail.com>
Message-ID: <bdfd9a55-fa97-dca3-5063-cf3abc2d7b93@oracle.com>

On 07/05/2017 09:23 PM, Thomas St?fe wrote:
>
> On Wed 5. Jul 2017 at 19:39, John Paul Adrian Glaubitz
> <glaubitz at physik.fu-berlin.de <mailto:glaubitz at physik.fu-berlin.de>> wrote:
>
>     On 07/05/2017 07:37 PM, Thomas St?fe wrote:
>     > Nah, I believe you :) Changes are trivial enough.
>
>     OK. So we're good to merge then?
>
>     --
>      .''`.  John Paul Adrian Glaubitz
>     : :' :  Debian Developer - glaubitz at debian.org
>     <mailto:glaubitz at debian.org>
>     `. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
>     <mailto:glaubitz at physik.fu-berlin.de>
>       `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>
> Yes, you now have two reviewers. But for these changes (hotspot) you
> need a sponsor, which needs to be an Oracle employee, which I am not.
>
> Maybe Eric could sponsor the change?

Yep, I can shepherd the patches in (aka getting them through the build 
and test system we all know as JPRT). Thanks Thomas for reviewing!
Erik

> Best regards, Thomas
>
>


From erik.helin at oracle.com  Thu Jul  6 13:00:09 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Thu, 6 Jul 2017 15:00:09 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170704093304.GD28259@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
Message-ID: <2d442ae6-50bf-6354-08e2-6874118ccfd8@oracle.com>

On 07/04/2017 11:33 AM, John Paul Adrian Glaubitz wrote:
> On Wed, Jun 14, 2017 at 01:50:06PM +0200, Erik Helin wrote:
>> I think the first three patches (hotspot-add-missing-log-header.diff,
>> hotspot-fix-checkbytebuffer.diff, rename-sparc-linux-atomic-header.diff) all
>> look good, thanks for fixing broken code. Consider them Reviewed by me.
>> Every patch needs a corresponding issue in the bug tracker, so I went ahead
>> and created:
>> - https://bugs.openjdk.java.net/browse/JDK-8182163
>> - https://bugs.openjdk.java.net/browse/JDK-8182164
>> - https://bugs.openjdk.java.net/browse/JDK-8182165
>
> Any chance a second maintainer can review those?
>
> I have run the test suite as mentioned before:
>
>> https://people.debian.org/~glaubitz/openjdk-9_9~b170-2_sparc64.new.build.gz

Although these three patches are correct, it seems like you have some 
way to go still to make this port solid :) All tests (that are 
applicable) in hotspot_tier1 should pass (besides the ones in 
ProblemList.txt). If you run the test via the top-level Makefiles, as in:

$ make test TEST=hotspot_tier1

then all tests should pass (because the Makefiles will pass 
ProblemList.txt to jtreg). After you get the code to compile, this 
should be your next goal :)

Thanks,
Erik

> Thanks,
> Adrian
>


From glaubitz at physik.fu-berlin.de  Thu Jul  6 13:09:19 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Thu, 6 Jul 2017 15:09:19 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <2d442ae6-50bf-6354-08e2-6874118ccfd8@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <2d442ae6-50bf-6354-08e2-6874118ccfd8@oracle.com>
Message-ID: <20170706130918.GJ23904@physik.fu-berlin.de>

On Thu, Jul 06, 2017 at 03:00:09PM +0200, Erik Helin wrote:
> Although these three patches are correct, it seems like you have some way to
> go still to make this port solid :) All tests (that are applicable) in
> hotspot_tier1 should pass (besides the ones in ProblemList.txt). If you run
> the test via the top-level Makefiles, as in:

Oh, I agree. But one has to start somewhere, no? ;)

> $ make test TEST=hotspot_tier1
> 
> then all tests should pass (because the Makefiles will pass ProblemList.txt
> to jtreg). After you get the code to compile, this should be your next goal
> :)

Thanks, I will look into this.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From matthias.baesken at sap.com  Thu Jul  6 14:18:14 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 6 Jul 2017 14:18:14 +0000
Subject: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
Message-ID: <c699972b6c24461b8333a4c1a9fd78a7@sap.com>

Hi Ioi ,
Yes I looked a bit at space reduction  but the effect is very small .

I was noticing the "mixture"  of   UseSharedSpaces code parts guarded (and not guarded) with  INCLUDE_CDS
When looking at a build configuration with cds disabled at build time.

But I'm totally fine with your  answer about not using INCLUDE_CDS everywhere.

Thanks, Matthias



>Hi Matthias,

>

>We don't use INCLUDE_CDS everywhere so we can avoid cluttering the code.

>In many cases, functions called inside if (UseSharedSpaces) are declared

>to have empty bodies. E.g.,

>

>void VM_RedefineClasses::doit() {

>   Thread *thread = Thread::current();

>

>   if (UseSharedSpaces) {

>     // Sharing is enabled so we remap the shared readonly space to

>     // shared readwrite, private just in case we need to redefine

>     // a shared class. We do the remap during the doit() phase of

>     // the safepoint to be safer.

>     if (!MetaspaceShared::remap_shared_readonly_as_readwrite()) {

>       log_info(redefine, class, load)("failed to remap shared readonly

>space to readwrite, private");

>       _res = JVMTI_ERROR_INTERNAL;

>       return;

>     }

>   }

>

>class MetaspaceShared {

>   static bool remap_shared_readonly_as_readwrite() NOT_CDS_RETURN_(true);

>

>

>So hopefully the C++ compile will just elide all the code inside the if

>(!...) branch (also also the check for UseSharedSpaces). There may be a

>few places where we should have added #if INCLUDE_CDS. For example,

>InstanceKlass::restore_unshareable_info.

>

>We are regularly building the minimal VM which doesn't have INCLUDE_CDS.

>So it looks like the VM will be built correctly when INCLUDE_CDS is not

>specified, but it probably has a bit of dead code.

>

>Are you mainly trying to reduce the size of libjvm when CDS is not enabled?

>

>Thanks

>- Ioi

>

>

>On 7/5/17 6:36 AM, Baesken, Matthias wrote:

>> Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,

>>    are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding

>>    when  CDS is disabled at compile time  :

>>

>>

>> See  hotspot/make/lib/JvmFeatures.gmk  :

>>

>> ifneq ($(call check-jvm-feature, cds), true)

>>    JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0

>>

>>

>>

>> However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in

>>

>>

>> share/vm/prims/jvmtiRedefineClasses.cpp

>> share/vm/memory/universe.cpp

>>

>> (also some other places)

>>

>>

>> Should I prepare a change and add the compile-time guard at the places where missing as well ?

>>

>> Best regards, Matthias



From hohensee at amazon.com  Sun Jul  9 13:26:56 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Sun, 9 Jul 2017 13:26:56 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
Message-ID: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>

Please review the following change to get JDK10 to build on OSX 10.12 and above.

https://bugs.openjdk.java.net/browse/JDK-8184022
http://cr.openjdk.java.net/~phh/8184022/webrev.00/

I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.

Slightly revised from the RFE:

JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m

  #if defined(MAC_OS_X_VERSION_10_12) && \
     MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
     __LP64__
     / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
  - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
  #else
  - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
  #endif
  untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {

works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.

The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.

Thanks,

Paul


From erik.joelsson at oracle.com  Mon Jul 10 08:10:21 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jul 2017 10:10:21 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
Message-ID: <13b66715-b546-d31b-5556-43f71a934249@oracle.com>

Hello,

I do not agree to removing that macro. I added those options to help 
guarantee that a build made on a newer version of macosx would still run 
on the oldest version currently supported. The macro is not mainly meant 
to be used in our code, but is picked up by system headers to cause an 
error if any features newer than 10.7 are used. It may be that we should 
bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.

It seems to me that we instead need to ignore the particular warning for 
this case.

/Erik


On 2017-07-09 15:26, Hohensee, Paul wrote:
> Please review the following change to get JDK10 to build on OSX 10.12 and above.
>
> https://bugs.openjdk.java.net/browse/JDK-8184022
> http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>
> I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
>
> Slightly revised from the RFE:
>
> JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>
>    #if defined(MAC_OS_X_VERSION_10_12) && \
>       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
>       __LP64__
>       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
>    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
>    #else
>    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
>    #endif
>    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>
> works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
>
> The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
>
> Thanks,
>
> Paul
>



From erik.joelsson at oracle.com  Mon Jul 10 15:47:54 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jul 2017 17:47:54 +0200
Subject: RFR: JDK-8184075: Make run-test-prebuilt profile more robust
Message-ID: <3e76f518-8f27-20c1-533f-99168ef687c3@oracle.com>

Hello,

The special Jib profile run-test-prebuilt is used when running tests 
through Mach 5. This profile is now used as the base for other profiles 
which requires that the profile always has a target platform configured. 
It should be the build platform by default, but if they testedProfile 
input variable is set, it should be the target platform of that profile.

Bug: https://bugs.openjdk.java.net/browse/JDK-8184075

Webrev: http://cr.openjdk.java.net/~erikj/8184075

/Erik



From tim.bell at oracle.com  Mon Jul 10 16:08:20 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 10 Jul 2017 09:08:20 -0700
Subject: RFR: JDK-8184075: Make run-test-prebuilt profile more robust
In-Reply-To: <3e76f518-8f27-20c1-533f-99168ef687c3@oracle.com>
References: <3e76f518-8f27-20c1-533f-99168ef687c3@oracle.com>
Message-ID: <5963A674.6010304@oracle.com>

Erik:
> The special Jib profile run-test-prebuilt is used when running tests
> through Mach 5. This profile is now used as the base for other profiles
> which requires that the profile always has a target platform configured.
> It should be the build platform by default, but if they testedProfile
> input variable is set, it should be the target platform of that profile.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184075
>
> Webrev: http://cr.openjdk.java.net/~erikj/8184075

Looks good to me.

Tim



From hohensee at amazon.com  Mon Jul 10 16:09:23 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 10 Jul 2017 16:09:23 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
Message-ID: <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>

Hi Erik,

The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.

What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.

Thanks,

Paul

On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    Hello,
    
    I do not agree to removing that macro. I added those options to help 
    guarantee that a build made on a newer version of macosx would still run 
    on the oldest version currently supported. The macro is not mainly meant 
    to be used in our code, but is picked up by system headers to cause an 
    error if any features newer than 10.7 are used. It may be that we should 
    bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
    
    It seems to me that we instead need to ignore the particular warning for 
    this case.
    
    /Erik
    
    
    On 2017-07-09 15:26, Hohensee, Paul wrote:
    > Please review the following change to get JDK10 to build on OSX 10.12 and above.
    >
    > https://bugs.openjdk.java.net/browse/JDK-8184022
    > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
    >
    > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
    >
    > Slightly revised from the RFE:
    >
    > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
    >
    >    #if defined(MAC_OS_X_VERSION_10_12) && \
    >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
    >       __LP64__
    >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
    >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
    >    #else
    >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
    >    #endif
    >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
    >
    > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
    >
    > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
    >
    > Thanks,
    >
    > Paul
    >
    
    


From at.manuel at gmail.com  Mon Jul 10 10:25:00 2017
From: at.manuel at gmail.com (Manuel Alonso Tajuelo)
Date: Mon, 10 Jul 2017 12:25:00 +0200
Subject: Cross compilation
Message-ID: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>

Hi,
cannot find any doc explaining how to cross compile openjdk. Is out there
any guidelines on how to perform that? I'm trying to cross compile from
x86_64 to an Arm7le.

Thanks in advance,


Manuel Alonso


From Anton.Bikineev at kaspersky.com  Mon Jul 10 15:23:50 2017
From: Anton.Bikineev at kaspersky.com (Anton Bikineev)
Date: Mon, 10 Jul 2017 15:23:50 +0000
Subject: Building and installing *only* java.base
Message-ID: <eee903777c6945e0955f0098e4175d37@kaspersky.com>

Hi,


Java 9 has done a good job of modularizing the codebase. This is great! And I need to port OpenJDK to a specific environment and want to do this incrementally. So far I've been able to build java.base successfully and now wondering, is there a way to install what has been built? I would assume the following commands would work:

make java.base

make install

but the last line goes and compiles all the rest that I don't need. Does anybody how to compile and install only specific modules?


Thanks!


From jiangli.zhou at oracle.com  Mon Jul 10 15:53:58 2017
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Mon, 10 Jul 2017 08:53:58 -0700
Subject: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
In-Reply-To: <64495e2dba5d4d1788d101eaa6f89a3e@sap.com>
References: <64495e2dba5d4d1788d101eaa6f89a3e@sap.com>
Message-ID: <36267ACB-03A1-4C37-AA4E-269F244B78D8@oracle.com>

Hi Matthias,

Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. I can help you integrate the changes after they are reviewed.

Thanks!
Jiangli

> On Jul 5, 2017, at 6:36 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
>  are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
>  when  CDS is disabled at compile time  :
> 
> 
> See  hotspot/make/lib/JvmFeatures.gmk  :
> 
> ifneq ($(call check-jvm-feature, cds), true)
>  JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0
> 
> 
> 
> However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in
> 
> 
> share/vm/prims/jvmtiRedefineClasses.cpp
> share/vm/memory/universe.cpp
> 
> (also some other places)
> 
> 
> Should I prepare a change and add the compile-time guard at the places where missing as well ?
> 
> Best regards, Matthias



From erik.joelsson at oracle.com  Mon Jul 10 16:46:53 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jul 2017 18:46:53 +0200
Subject: Building and installing *only* java.base
In-Reply-To: <eee903777c6945e0955f0098e4175d37@kaspersky.com>
References: <eee903777c6945e0955f0098e4175d37@kaspersky.com>
Message-ID: <da92f83a-0eed-f693-740e-b257f6509380@oracle.com>

Hello Anton,

We currently don't have a shortcut like that in the build system, you 
basically have to build everything. Once everything is built you can use 
jlink to create your own custom image with just the modules you like.

If you run "make java.base", you will get a runnable "exploded" image in 
build/<foobar>/jdk that contains what you just built and nothing more. 
Perhaps that's enough for what you need?

/Erik


On 2017-07-10 17:23, Anton Bikineev wrote:
> Hi,
>
>
> Java 9 has done a good job of modularizing the codebase. This is great! And I need to port OpenJDK to a specific environment and want to do this incrementally. So far I've been able to build java.base successfully and now wondering, is there a way to install what has been built? I would assume the following commands would work:
>
> make java.base
>
> make install
>
> but the last line goes and compiles all the rest that I don't need. Does anybody how to compile and install only specific modules?
>
>
> Thanks!



From erik.joelsson at oracle.com  Mon Jul 10 17:01:38 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jul 2017 19:01:38 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
Message-ID: <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>



On 2017-07-10 18:09, Hohensee, Paul wrote:
> Hi Erik,
>
> The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>
> What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
That's not exactly true. Apple is making it very hard to stay on older 
versions of the OS compared to other OS vendors. For this reason we are 
not always able to stay on a particular version for Macosx in 
particular. We also in general try to avoid having to fill our build 
servers/environments with just the oldest OSes, because older OSes are 
harder to maintain and less convenient to work with. So instead, we try 
to maintain working build environments on newer OSes that produce 
binaries that are compatible with the oldest we support. So, at least 
from Oracle's perspective, we prefer if builds on different OS versions 
produce equivalent binaries when possible. We certainly don't want to 
prevent building on newer OS/compilers.

If this can't be worked around at the source level, then perhaps we need 
to consider hiding this macro definition behind a configure option that 
we can use internally. I would be open to that. Something like 
--with-macosx-version-min=10.7 which configure could then translate to 
the combination of options currently used. That way, most openjdk 
developers/builders would not need to suffer this Oracle requirement.

/Erik
> Thanks,
>
> Paul
>
> On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>
>      Hello,
>      
>      I do not agree to removing that macro. I added those options to help
>      guarantee that a build made on a newer version of macosx would still run
>      on the oldest version currently supported. The macro is not mainly meant
>      to be used in our code, but is picked up by system headers to cause an
>      error if any features newer than 10.7 are used. It may be that we should
>      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
>      
>      It seems to me that we instead need to ignore the particular warning for
>      this case.
>      
>      /Erik
>      
>      
>      On 2017-07-09 15:26, Hohensee, Paul wrote:
>      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
>      >
>      > https://bugs.openjdk.java.net/browse/JDK-8184022
>      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>      >
>      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
>      >
>      > Slightly revised from the RFE:
>      >
>      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>      >
>      >    #if defined(MAC_OS_X_VERSION_10_12) && \
>      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
>      >       __LP64__
>      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
>      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
>      >    #else
>      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
>      >    #endif
>      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>      >
>      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
>      >
>      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
>      >
>      > Thanks,
>      >
>      > Paul
>      >
>      
>      
>



From hohensee at amazon.com  Mon Jul 10 17:48:21 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 10 Jul 2017 17:48:21 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
Message-ID: <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>

That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.

Thanks,

Paul

On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    
    
    On 2017-07-10 18:09, Hohensee, Paul wrote:
    > Hi Erik,
    >
    > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
    >
    > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
    That's not exactly true. Apple is making it very hard to stay on older 
    versions of the OS compared to other OS vendors. For this reason we are 
    not always able to stay on a particular version for Macosx in 
    particular. We also in general try to avoid having to fill our build 
    servers/environments with just the oldest OSes, because older OSes are 
    harder to maintain and less convenient to work with. So instead, we try 
    to maintain working build environments on newer OSes that produce 
    binaries that are compatible with the oldest we support. So, at least 
    from Oracle's perspective, we prefer if builds on different OS versions 
    produce equivalent binaries when possible. We certainly don't want to 
    prevent building on newer OS/compilers.
    
    If this can't be worked around at the source level, then perhaps we need 
    to consider hiding this macro definition behind a configure option that 
    we can use internally. I would be open to that. Something like 
    --with-macosx-version-min=10.7 which configure could then translate to 
    the combination of options currently used. That way, most openjdk 
    developers/builders would not need to suffer this Oracle requirement.
    
    /Erik
    > Thanks,
    >
    > Paul
    >
    > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >
    >      Hello,
    >      
    >      I do not agree to removing that macro. I added those options to help
    >      guarantee that a build made on a newer version of macosx would still run
    >      on the oldest version currently supported. The macro is not mainly meant
    >      to be used in our code, but is picked up by system headers to cause an
    >      error if any features newer than 10.7 are used. It may be that we should
    >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
    >      
    >      It seems to me that we instead need to ignore the particular warning for
    >      this case.
    >      
    >      /Erik
    >      
    >      
    >      On 2017-07-09 15:26, Hohensee, Paul wrote:
    >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
    >      >
    >      > https://bugs.openjdk.java.net/browse/JDK-8184022
    >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
    >      >
    >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
    >      >
    >      > Slightly revised from the RFE:
    >      >
    >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
    >      >
    >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
    >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
    >      >       __LP64__
    >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
    >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
    >      >    #else
    >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
    >      >    #endif
    >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
    >      >
    >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
    >      >
    >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
    >      >
    >      > Thanks,
    >      >
    >      > Paul
    >      >
    >      
    >      
    >
    
    


From aph at redhat.com  Tue Jul 11 09:16:35 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 11 Jul 2017 10:16:35 +0100
Subject: Cross compilation
In-Reply-To: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
Message-ID: <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>

On 10/07/17 11:25, Manuel Alonso Tajuelo wrote:
> cannot find any doc explaining how to cross compile openjdk. Is out there
> any guidelines on how to perform that? I'm trying to cross compile from
> x86_64 to an Arm7le.

It's usually pretty easy.  You'll need a toolchain for your target in
your path, a complete image of your target system (i.e. the libraries,
header files, and so on) which you use as the sysroot when
configuring, and then you just run make as usual.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From list at xenhideout.nl  Tue Jul 11 09:32:20 2017
From: list at xenhideout.nl (Xen)
Date: Tue, 11 Jul 2017 11:32:20 +0200
Subject: Cross compilation
In-Reply-To: <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
Message-ID: <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>

Andrew Haley schreef op 11-07-2017 11:16:
> On 10/07/17 11:25, Manuel Alonso Tajuelo wrote:
>> cannot find any doc explaining how to cross compile openjdk. Is out 
>> there
>> any guidelines on how to perform that? I'm trying to cross compile 
>> from
>> x86_64 to an Arm7le.
> 
> It's usually pretty easy.  You'll need a toolchain for your target in
> your path, a complete image of your target system (i.e. the libraries,
> header files, and so on) which you use as the sysroot when
> configuring, and then you just run make as usual.

You will need all X libraries as well though. I personally couldn't 
manage without using OpenEmbedded.


From aph at redhat.com  Tue Jul 11 09:34:39 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 11 Jul 2017 10:34:39 +0100
Subject: Cross compilation
In-Reply-To: <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
 <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
Message-ID: <6a130e7d-7179-f94a-e97e-e6b5edc87eef@redhat.com>

On 11/07/17 10:32, Xen wrote:
> Andrew Haley schreef op 11-07-2017 11:16:
>> On 10/07/17 11:25, Manuel Alonso Tajuelo wrote:
>>> cannot find any doc explaining how to cross compile openjdk. Is out 
>>> there
>>> any guidelines on how to perform that? I'm trying to cross compile 
>>> from
>>> x86_64 to an Arm7le.
>>
>> It's usually pretty easy.  You'll need a toolchain for your target in
>> your path, a complete image of your target system (i.e. the libraries,
>> header files, and so on) which you use as the sysroot when
>> configuring, and then you just run make as usual.
> 
> You will need all X libraries as well though.

Well, yes: they are in the complete image of your target system.

> I personally couldn't manage without using OpenEmbedded.

I found it a complete pain.  Each to their own, I guess.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From glaubitz at physik.fu-berlin.de  Tue Jul 11 09:37:48 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 11 Jul 2017 11:37:48 +0200
Subject: Cross compilation
In-Reply-To: <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
 <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
Message-ID: <20170711093748.GE30495@physik.fu-berlin.de>

On Tue, Jul 11, 2017 at 11:32:20AM +0200, Xen wrote:
> You will need all X libraries as well though. I personally couldn't manage
> without using OpenEmbedded.

It's fairly easy to do that on Debian thanks to Multi-Arch. You can
install all build dependencies for the target architecture simply from
the corresponding repository.

You basically just need to:

# dpkg --add-architecture armhf
# apt update
# apt build-dep openjdk-8:armhf

Just make sure you have at least Debian Jessie for openjdk-8.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From erik.joelsson at oracle.com  Tue Jul 11 09:45:40 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 11 Jul 2017 11:45:40 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
Message-ID: <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>

The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are 
used in combination to achieve the same thing. I chose to use both to 
really enforce full compatibility with the specified version. The 
"official" way of targeting earlier versions of the OS is just using 
-mmacosx-version-min. This will however still accept uses of newer APIs, 
but at link time, those will be linked with weak_import. Essentially 
it's expected that your application should be able to do without these 
calls if necessary, at the application level. While better than not 
being able to launch at all on the older OS, by adding 
-DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any 
code tries to use a newer API.

As I see it, either we fully enforce this at build time, or we don't at 
all. The natural default is to build for the current host platform. The 
configure parameter would make it possible to enforce a minimal 
compatible OS version that the binaries must be usable on.

(Note that if you propose such a change, I will need to add the Oracle 
bit as well, where we use the parameter, which would need to go in at 
the same time in common/conf/jib-profiles.js. Also note that I will be 
on vacation for 5 weeks starting this weekend so won't be around to 
review for most of that time.)

/Erik


On 2017-07-10 19:48, Hohensee, Paul wrote:
> That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
>
> Thanks,
>
> Paul
>
> On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>
>      
>      
>      On 2017-07-10 18:09, Hohensee, Paul wrote:
>      > Hi Erik,
>      >
>      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>      >
>      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
>      That's not exactly true. Apple is making it very hard to stay on older
>      versions of the OS compared to other OS vendors. For this reason we are
>      not always able to stay on a particular version for Macosx in
>      particular. We also in general try to avoid having to fill our build
>      servers/environments with just the oldest OSes, because older OSes are
>      harder to maintain and less convenient to work with. So instead, we try
>      to maintain working build environments on newer OSes that produce
>      binaries that are compatible with the oldest we support. So, at least
>      from Oracle's perspective, we prefer if builds on different OS versions
>      produce equivalent binaries when possible. We certainly don't want to
>      prevent building on newer OS/compilers.
>      
>      If this can't be worked around at the source level, then perhaps we need
>      to consider hiding this macro definition behind a configure option that
>      we can use internally. I would be open to that. Something like
>      --with-macosx-version-min=10.7 which configure could then translate to
>      the combination of options currently used. That way, most openjdk
>      developers/builders would not need to suffer this Oracle requirement.
>      
>      /Erik
>      > Thanks,
>      >
>      > Paul
>      >
>      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >
>      >      Hello,
>      >
>      >      I do not agree to removing that macro. I added those options to help
>      >      guarantee that a build made on a newer version of macosx would still run
>      >      on the oldest version currently supported. The macro is not mainly meant
>      >      to be used in our code, but is picked up by system headers to cause an
>      >      error if any features newer than 10.7 are used. It may be that we should
>      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
>      >
>      >      It seems to me that we instead need to ignore the particular warning for
>      >      this case.
>      >
>      >      /Erik
>      >
>      >
>      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
>      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
>      >      >
>      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
>      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>      >      >
>      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
>      >      >
>      >      > Slightly revised from the RFE:
>      >      >
>      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>      >      >
>      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
>      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
>      >      >       __LP64__
>      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
>      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
>      >      >    #else
>      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
>      >      >    #endif
>      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>      >      >
>      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
>      >      >
>      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
>      >      >
>      >      > Thanks,
>      >      >
>      >      > Paul
>      >      >
>      >
>      >
>      >
>      
>      
>



From aph at redhat.com  Tue Jul 11 09:53:53 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 11 Jul 2017 10:53:53 +0100
Subject: Cross compilation
In-Reply-To: <20170711093748.GE30495@physik.fu-berlin.de>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
 <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
 <20170711093748.GE30495@physik.fu-berlin.de>
Message-ID: <f5ce8324-d8d2-da7c-8efd-f05b0fecf53b@redhat.com>

On 11/07/17 10:37, John Paul Adrian Glaubitz wrote:
> On Tue, Jul 11, 2017 at 11:32:20AM +0200, Xen wrote:
>> You will need all X libraries as well though. I personally couldn't manage
>> without using OpenEmbedded.
> 
> It's fairly easy to do that on Debian thanks to Multi-Arch. You can
> install all build dependencies for the target architecture simply from
> the corresponding repository.
> 
> You basically just need to:
> 
> # dpkg --add-architecture armhf
> # apt update
> # apt build-dep openjdk-8:armhf
> 
> Just make sure you have at least Debian Jessie for openjdk-8.

I've always assumed that you must have a target system to test on,
so all you have to do is install everything on the target and then
copy an image of its root filesystem.  I've even taken a drive
out of a target system and plugged it into my host.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From glaubitz at physik.fu-berlin.de  Tue Jul 11 10:02:58 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Tue, 11 Jul 2017 12:02:58 +0200
Subject: Cross compilation
In-Reply-To: <f5ce8324-d8d2-da7c-8efd-f05b0fecf53b@redhat.com>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
 <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
 <20170711093748.GE30495@physik.fu-berlin.de>
 <f5ce8324-d8d2-da7c-8efd-f05b0fecf53b@redhat.com>
Message-ID: <d1ad4d7a-d91d-66e6-2686-a1fa89f527ae@physik.fu-berlin.de>

On 07/11/2017 11:53 AM, Andrew Haley wrote:
>> Just make sure you have at least Debian Jessie for openjdk-8.
> 
> I've always assumed that you must have a target system to test on,
> so all you have to do is install everything on the target and then
> copy an image of its root filesystem.  I've even taken a drive
> out of a target system and plugged it into my host.

You can use QEMU for that. I use qemu-user in Debian to create a
complete build environment for emulator-based cross-building [1].

You basically create a chroot for the target, copy the qemu-user
binary for the target architecture into it and then just configure
sbuild to use it.

Note: If you create the chroot for armhf, you must not use the
      debian-ports mirror but the regular mirror:

> debootstrap --variant=buildd --foreign --arch=armhf unstable sid-armhf-sbuild http://ftp.debian.org/debian/

And you don't need to overwrite the etc/apt/sources.list in the
case of armhf.

Let me know if you need anymore help.

Adrian

> [1] https://wiki.debian.org/SH4/sbuildQEMU

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From list at xenhideout.nl  Tue Jul 11 10:04:18 2017
From: list at xenhideout.nl (Xen)
Date: Tue, 11 Jul 2017 12:04:18 +0200
Subject: Cross compilation
In-Reply-To: <20170711093748.GE30495@physik.fu-berlin.de>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
 <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
 <20170711093748.GE30495@physik.fu-berlin.de>
Message-ID: <921cd25c61bab15b86dcdda11f595a0f@xenhideout.nl>

John Paul Adrian Glaubitz schreef op 11-07-2017 11:37:
> On Tue, Jul 11, 2017 at 11:32:20AM +0200, Xen wrote:
>> You will need all X libraries as well though. I personally couldn't 
>> manage
>> without using OpenEmbedded.
> 
> It's fairly easy to do that on Debian thanks to Multi-Arch. You can
> install all build dependencies for the target architecture simply from
> the corresponding repository.
> 
> You basically just need to:
> 
> # dpkg --add-architecture armhf
> # apt update
> # apt build-dep openjdk-8:armhf
> 
> Just make sure you have at least Debian Jessie for openjdk-8.

Aye, but it just seems that when you have such a full-fledged system 
available already, the need for cross-compilation also grows much less, 
since it has already been done, unless you are developing I guess. I 
mean if you have not changed the JDK there is usually not much reason to 
cross-compile to a system that already has it ;-).

Anyway, to each their own indeed. The biggest pain for OpenEmbedded was 
that you cannot really select your target compiler and target glibc very 
well, I am sure you can, but I couldn't. Also, the ipkgs it created were 
not actually usable by my target system, but anyway.

It's a sort of out-of-the-box system that will compile EVERYTHING the 
JDK might need first, which takes a long time, and then finally it will 
build the JDK. If you have a target system available with all the 
required libraries, there is probably indeed not much use in using 
OpenEmbedded.

Regards.

(Also I was trying JDK 7, version 8 may have a much better build 
system).


From aph at redhat.com  Tue Jul 11 10:08:38 2017
From: aph at redhat.com (Andrew Haley)
Date: Tue, 11 Jul 2017 11:08:38 +0100
Subject: Cross compilation
In-Reply-To: <921cd25c61bab15b86dcdda11f595a0f@xenhideout.nl>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <ca91cf8b-2265-1223-35a6-19fa4e2d4491@redhat.com>
 <3768ac8e178736f0bb81cbce42779bd1@xenhideout.nl>
 <20170711093748.GE30495@physik.fu-berlin.de>
 <921cd25c61bab15b86dcdda11f595a0f@xenhideout.nl>
Message-ID: <31fb0700-6181-c32b-59ef-78f54e5aa111@redhat.com>

On 11/07/17 11:04, Xen wrote:
> (Also I was trying JDK 7, version 8 may have a much better build 
> system).

It has.  Much.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From magnus.ihse.bursie at oracle.com  Tue Jul 11 14:27:20 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 11 Jul 2017 16:27:20 +0200
Subject: Cross compilation
In-Reply-To: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
Message-ID: <77F79480-8786-40FB-9233-510E227392CA@oracle.com>


> 10 juli 2017 kl. 12:25 skrev Manuel Alonso Tajuelo <at.manuel at gmail.com>:
> 
> Hi,
> cannot find any doc explaining how to cross compile openjdk.

http://hg.openjdk.java.net/jdk9/jdk9/raw-file/tip/common/doc/building.html

See the section "Cross-compiling". 

/Magnus

> Is out there
> any guidelines on how to perform that? I'm trying to cross compile from
> x86_64 to an Arm7le.
> 
> Thanks in advance,
> 
> 
> Manuel Alonso


From hohensee at amazon.com  Wed Jul 12 01:19:38 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 12 Jul 2017 01:19:38 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
Message-ID: <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>

New webrev at

http://cr.openjdk.java.net/~phh/8184022/webrev.01/

I defined a new shell variable MACOSX_VERSION_MAX which is settable via a new configure switch ?with-macosx-version-max=<version>. Example use: --with-macosx-version-max=10.12.00. The specified version is passed via a compiler command line switch, vis ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).

MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.

Tested by attempting builds on OSX 10.12.04.

(1) no ?with-macosx-version-max: succeeds as expected because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so defaults to 10.12.04.
(2) ?with-macosx-version-max=10.11.00: fails as expected due to formal parameter type mismatch.
(3) ?with-macosx-version-max=10.12.00: succeeds as expected because formal parameter types are the same for all 10.12.xx.

It?d be great if you could try it out.

Note that successful cases (1) and (3) above provoke three warnings which I haven?t investigated. Imo, I/we can figure out how to get rid of these next/later.

ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) was built for newer OSX version (10.12) than being linked (10.7)
ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) was built for newer OSX version (10.12) than being linked (10.7)
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]

Paul

On 7/11/17, 2:45 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are 
    used in combination to achieve the same thing. I chose to use both to 
    really enforce full compatibility with the specified version. The 
    "official" way of targeting earlier versions of the OS is just using 
    -mmacosx-version-min. This will however still accept uses of newer APIs, 
    but at link time, those will be linked with weak_import. Essentially 
    it's expected that your application should be able to do without these 
    calls if necessary, at the application level. While better than not 
    being able to launch at all on the older OS, by adding 
    -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any 
    code tries to use a newer API.
    
    As I see it, either we fully enforce this at build time, or we don't at 
    all. The natural default is to build for the current host platform. The 
    configure parameter would make it possible to enforce a minimal 
    compatible OS version that the binaries must be usable on.
    
    (Note that if you propose such a change, I will need to add the Oracle 
    bit as well, where we use the parameter, which would need to go in at 
    the same time in common/conf/jib-profiles.js. Also note that I will be 
    on vacation for 5 weeks starting this weekend so won't be around to 
    review for most of that time.)
    
    /Erik
    
    
    On 2017-07-10 19:48, Hohensee, Paul wrote:
    > That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
    >
    > Thanks,
    >
    > Paul
    >
    > On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >
    >      
    >      
    >      On 2017-07-10 18:09, Hohensee, Paul wrote:
    >      > Hi Erik,
    >      >
    >      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
    >      >
    >      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
    >      That's not exactly true. Apple is making it very hard to stay on older
    >      versions of the OS compared to other OS vendors. For this reason we are
    >      not always able to stay on a particular version for Macosx in
    >      particular. We also in general try to avoid having to fill our build
    >      servers/environments with just the oldest OSes, because older OSes are
    >      harder to maintain and less convenient to work with. So instead, we try
    >      to maintain working build environments on newer OSes that produce
    >      binaries that are compatible with the oldest we support. So, at least
    >      from Oracle's perspective, we prefer if builds on different OS versions
    >      produce equivalent binaries when possible. We certainly don't want to
    >      prevent building on newer OS/compilers.
    >      
    >      If this can't be worked around at the source level, then perhaps we need
    >      to consider hiding this macro definition behind a configure option that
    >      we can use internally. I would be open to that. Something like
    >      --with-macosx-version-min=10.7 which configure could then translate to
    >      the combination of options currently used. That way, most openjdk
    >      developers/builders would not need to suffer this Oracle requirement.
    >      
    >      /Erik
    >      > Thanks,
    >      >
    >      > Paul
    >      >
    >      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >      >
    >      >      Hello,
    >      >
    >      >      I do not agree to removing that macro. I added those options to help
    >      >      guarantee that a build made on a newer version of macosx would still run
    >      >      on the oldest version currently supported. The macro is not mainly meant
    >      >      to be used in our code, but is picked up by system headers to cause an
    >      >      error if any features newer than 10.7 are used. It may be that we should
    >      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
    >      >
    >      >      It seems to me that we instead need to ignore the particular warning for
    >      >      this case.
    >      >
    >      >      /Erik
    >      >
    >      >
    >      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
    >      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
    >      >      >
    >      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
    >      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
    >      >      >
    >      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
    >      >      >
    >      >      > Slightly revised from the RFE:
    >      >      >
    >      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
    >      >      >
    >      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
    >      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
    >      >      >       __LP64__
    >      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
    >      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
    >      >      >    #else
    >      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
    >      >      >    #endif
    >      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
    >      >      >
    >      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
    >      >      >
    >      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
    >      >      >
    >      >      > Thanks,
    >      >      >
    >      >      > Paul
    >      >      >
    >      >
    >      >
    >      >
    >      
    >      
    >
    
    


From erik.joelsson at oracle.com  Wed Jul 12 08:15:56 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Jul 2017 10:15:56 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
Message-ID: <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>

Hello,


On 2017-07-12 03:19, Hohensee, Paul wrote:
> New webrev at
>
> http://cr.openjdk.java.net/~phh/8184022/webrev.01/
For the AC_ARG_WITH, we usually refrain from using the builtin "if-set, 
if-not-set" parameters and define our own logic to handle all 4 
possibilities: not set, --with-foobar=value, --with-foobar and 
--without-foobar. The latter two results in the values "yes" and "no" 
respectively and in this case those two are invalid and needs to result 
in errors. Also since we are expecting a very specific format on the 
input, we need to validate this format so we fail fast instead of 
getting weird compile errors much later.

My understanding of -mmacosx-version-min is that it sets 
MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add that. OTOH, it 
makes it more obvious where this comes from if anyone stumbles on it in 
the source.
> I defined a new shell variable MACOSX_VERSION_MAX which is settable via a new configure switch ?with-macosx-version-max=<version>. Example use: --with-macosx-version-max=10.12.00. The specified version is passed via a compiler command line switch, vis ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
At what point did they introduce the double zeros at the end? Seems like 
we will need guard the values quite carefully and make sure we zero pad 
if needed.
> MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
>
> Tested by attempting builds on OSX 10.12.04.
>
> (1) no ?with-macosx-version-max: succeeds as expected because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so defaults to 10.12.04.
> (2) ?with-macosx-version-max=10.11.00: fails as expected due to formal parameter type mismatch.
> (3) ?with-macosx-version-max=10.12.00: succeeds as expected because formal parameter types are the same for all 10.12.xx.
>
> It?d be great if you could try it out.
>
> Note that successful cases (1) and (3) above provoke three warnings which I haven?t investigated. Imo, I/we can figure out how to get rid of these next/later.
>
> ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) was built for newer OSX version (10.12) than being linked (10.7)
> ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) was built for newer OSX version (10.12) than being linked (10.7)
> clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
I believe the warnings for static libs is simply caused by not adding 
-mmacosx-version-min to the ARFLAGS. Not sure if ar on mac takes that 
flag though.

The libstdc++ warning seems harder to work around until we change the 
minimum to 10.9 instead of 10.7.

I would appreciate if you could also include this patch as part of this 
change to make Oracle builds still behave as before:

diff -r a6c830ee8a67 common/conf/jib-profiles.js
--- a/common/conf/jib-profiles.js
+++ b/common/conf/jib-profiles.js
@@ -436,7 +436,8 @@
              target_os: "macosx",
              target_cpu: "x64",
              dependencies: ["devkit"],
-            configure_args: concat(common.configure_args_64bit, 
"--with-zlib=system"),
+            configure_args: concat(common.configure_args_64bit, 
"--with-zlib=system",
+                "--with-macosx-version-max=10.7.0"),
          },

          "solaris-x64": {


Thanks!
/Erik
> Paul
>
> On 7/11/17, 2:45 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>
>      The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are
>      used in combination to achieve the same thing. I chose to use both to
>      really enforce full compatibility with the specified version. The
>      "official" way of targeting earlier versions of the OS is just using
>      -mmacosx-version-min. This will however still accept uses of newer APIs,
>      but at link time, those will be linked with weak_import. Essentially
>      it's expected that your application should be able to do without these
>      calls if necessary, at the application level. While better than not
>      being able to launch at all on the older OS, by adding
>      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any
>      code tries to use a newer API.
>      
>      As I see it, either we fully enforce this at build time, or we don't at
>      all. The natural default is to build for the current host platform. The
>      configure parameter would make it possible to enforce a minimal
>      compatible OS version that the binaries must be usable on.
>      
>      (Note that if you propose such a change, I will need to add the Oracle
>      bit as well, where we use the parameter, which would need to go in at
>      the same time in common/conf/jib-profiles.js. Also note that I will be
>      on vacation for 5 weeks starting this weekend so won't be around to
>      review for most of that time.)
>      
>      /Erik
>      
>      
>      On 2017-07-10 19:48, Hohensee, Paul wrote:
>      > That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
>      >
>      > Thanks,
>      >
>      > Paul
>      >
>      > On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >
>      >
>      >
>      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
>      >      > Hi Erik,
>      >      >
>      >      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>      >      >
>      >      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
>      >      That's not exactly true. Apple is making it very hard to stay on older
>      >      versions of the OS compared to other OS vendors. For this reason we are
>      >      not always able to stay on a particular version for Macosx in
>      >      particular. We also in general try to avoid having to fill our build
>      >      servers/environments with just the oldest OSes, because older OSes are
>      >      harder to maintain and less convenient to work with. So instead, we try
>      >      to maintain working build environments on newer OSes that produce
>      >      binaries that are compatible with the oldest we support. So, at least
>      >      from Oracle's perspective, we prefer if builds on different OS versions
>      >      produce equivalent binaries when possible. We certainly don't want to
>      >      prevent building on newer OS/compilers.
>      >
>      >      If this can't be worked around at the source level, then perhaps we need
>      >      to consider hiding this macro definition behind a configure option that
>      >      we can use internally. I would be open to that. Something like
>      >      --with-macosx-version-min=10.7 which configure could then translate to
>      >      the combination of options currently used. That way, most openjdk
>      >      developers/builders would not need to suffer this Oracle requirement.
>      >
>      >      /Erik
>      >      > Thanks,
>      >      >
>      >      > Paul
>      >      >
>      >      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >      >
>      >      >      Hello,
>      >      >
>      >      >      I do not agree to removing that macro. I added those options to help
>      >      >      guarantee that a build made on a newer version of macosx would still run
>      >      >      on the oldest version currently supported. The macro is not mainly meant
>      >      >      to be used in our code, but is picked up by system headers to cause an
>      >      >      error if any features newer than 10.7 are used. It may be that we should
>      >      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
>      >      >
>      >      >      It seems to me that we instead need to ignore the particular warning for
>      >      >      this case.
>      >      >
>      >      >      /Erik
>      >      >
>      >      >
>      >      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
>      >      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
>      >      >      >
>      >      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
>      >      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>      >      >      >
>      >      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
>      >      >      >
>      >      >      > Slightly revised from the RFE:
>      >      >      >
>      >      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>      >      >      >
>      >      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
>      >      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
>      >      >      >       __LP64__
>      >      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
>      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
>      >      >      >    #else
>      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
>      >      >      >    #endif
>      >      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>      >      >      >
>      >      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
>      >      >      >
>      >      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
>      >      >      >
>      >      >      > Thanks,
>      >      >      >
>      >      >      > Paul
>      >      >      >
>      >      >
>      >      >
>      >      >
>      >
>      >
>      >
>      
>      
>



From jan.lahoda at oracle.com  Wed Jul 12 14:58:14 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 12 Jul 2017 16:58:14 +0200
Subject: RFR: JDK-8181298: Assertion failure in
 com.sun.tools.javac.comp.Modules
Message-ID: <59663906.7050109@oracle.com>

Hi,

The ct.sym building needs to read existing module-infos, to properly 
detect transitive dependencies. But the target does not depend on all 
module-infos being generated, which may in turn lead to problems with 
incomplete module graph.

So, the proposed patch is to add the dependency on all generated 
module-infos. javac should crash this way even in a presence of 
incomplete module graph, this will be fixed under a separate ticket.

The cause was found and patch is by Erik.

Bug: https://bugs.openjdk.java.net/browse/JDK-8181298
Webrev: http://cr.openjdk.java.net/~jlahoda/8181298/webrev.00/

Comments are welcome.

Thanks,
     Jan


From tim.bell at oracle.com  Wed Jul 12 15:25:16 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 12 Jul 2017 08:25:16 -0700
Subject: RFR: JDK-8181298: Assertion failure in
 com.sun.tools.javac.comp.Modules
In-Reply-To: <59663906.7050109@oracle.com>
References: <59663906.7050109@oracle.com>
Message-ID: <59663F5C.9090309@oracle.com>

Jan:

> The ct.sym building needs to read existing module-infos, to properly
> detect transitive dependencies. But the target does not depend on all
> module-infos being generated, which may in turn lead to problems with
> incomplete module graph.
>
> So, the proposed patch is to add the dependency on all generated
> module-infos. javac should crash this way even in a presence of
> incomplete module graph, this will be fixed under a separate ticket.
>
> The cause was found and patch is by Erik.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181298
> Webrev: http://cr.openjdk.java.net/~jlahoda/8181298/webrev.00/
>
> Comments are welcome.

Looks good to me.

Tim




From erik.joelsson at oracle.com  Wed Jul 12 15:35:44 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Jul 2017 17:35:44 +0200
Subject: RFR: JDK-8181298: Assertion failure in
 com.sun.tools.javac.comp.Modules
In-Reply-To: <59663906.7050109@oracle.com>
References: <59663906.7050109@oracle.com>
Message-ID: <76e5277d-9273-dc13-9a94-6ad29353acc1@oracle.com>

Looks good to me as well.

/Erik


On 2017-07-12 16:58, Jan Lahoda wrote:
> Hi,
>
> The ct.sym building needs to read existing module-infos, to properly 
> detect transitive dependencies. But the target does not depend on all 
> module-infos being generated, which may in turn lead to problems with 
> incomplete module graph.
>
> So, the proposed patch is to add the dependency on all generated 
> module-infos. javac should crash this way even in a presence of 
> incomplete module graph, this will be fixed under a separate ticket.
>
> The cause was found and patch is by Erik.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181298
> Webrev: http://cr.openjdk.java.net/~jlahoda/8181298/webrev.00/
>
> Comments are welcome.
>
> Thanks,
>     Jan



From at.manuel at gmail.com  Wed Jul 12 16:01:14 2017
From: at.manuel at gmail.com (Manuel Alonso Tajuelo)
Date: Wed, 12 Jul 2017 18:01:14 +0200
Subject: Cross compilation
In-Reply-To: <77F79480-8786-40FB-9233-510E227392CA@oracle.com>
References: <CAFPo=rUbzF6MCezHrwSe_sGpfUCRmjdS5my3jTxpoNmFGDVOtw@mail.gmail.com>
 <77F79480-8786-40FB-9233-510E227392CA@oracle.com>
Message-ID: <CAFPo=rUhnn6sUW0bq5UFrNKEz8=Gut8DkSh_v4Hvp55k-QaNOQ@mail.gmail.com>

Hi,
Thank you for pointing me out to the documentation (btw quite good
document), I was able to cross compile openjdk-9 from sources but (I forgot
to mention...my apologies...) I was looking for information to
cross-compile openjdk-8. After some reading of the makefiles and build
scripts, I have decided to postpone(or cancel)  for the time being (unless
I find the proper recipe)

Best Regards,

Manuel

2017-07-11 16:27 GMT+02:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
>:

>
> 10 juli 2017 kl. 12:25 skrev Manuel Alonso Tajuelo <at.manuel at gmail.com>:
>
> Hi,
> cannot find any doc explaining how to cross compile openjdk.
>
>
> http://hg.openjdk.java.net/jdk9/jdk9/raw-file/tip/common/doc/building.html
>
> See the section "Cross-compiling".
>
> /Magnus
>
> Is out there
> any guidelines on how to perform that? I'm trying to cross compile from
> x86_64 to an Arm7le.
>
> Thanks in advance,
>
>
> Manuel Alonso
>
>


From matthias.baesken at sap.com  Thu Jul 13 09:21:12 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 13 Jul 2017 09:21:12 +0000
Subject: jdk10 build : usage of -fno-var-tracking-assignments  g++ flag in
 hotspot build
Message-ID: <a55bac4b639a4f13b7d6faa9e3084306@sap.com>

Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .

It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see

https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary

I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
There are various solutions one could do  to avoid  the  compilation error .


1) disallow usage of old gcc versions here :

autoconf/toolchain.m4

TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"

( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )


2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
(in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )

hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
hotspot/make/lib/JvmOverrideFiles.gmk-35-endif

What is your preferred solution ?


Thanks, Matthias




From erik.joelsson at oracle.com  Thu Jul 13 09:59:12 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Jul 2017 11:59:12 +0200
Subject: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in
 hotspot build
In-Reply-To: <a55bac4b639a4f13b7d6faa9e3084306@sap.com>
References: <a55bac4b639a4f13b7d6faa9e3084306@sap.com>
Message-ID: <a2c22c0e-b91a-7100-5cd8-c1c42fff8e33@oracle.com>

Hello Matthias,

AFAIK, the only reason we support GCC versions older than 4.9 is for you 
guys at SAP, so if you would suggest dropping support, that would of 
course be the simplest solution.

If you want to keep support but make the use of this flag optional, the 
preferred method is to add a test in flags.m4. We have macros defined 
for this. FLAGS_COMPILER_CHECK_ARGUMENTS or 
FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use 
it to check if the flag is valid for the current compiler. If so, you 
can define a variable 
"CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment" 
and empty otherwise, and in the makefile use this variable in the 
assignement.

We want to avoid static shell expressions in the makefiles if possible 
and keep that kind of logic in configure. It's also better to explicitly 
check for features rather than versions.

/Erik


On 2017-07-13 11:21, Baesken, Matthias wrote:
> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>
> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>
> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>
> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
> There are various solutions one could do  to avoid  the  compilation error .
>
>
> 1) disallow usage of old gcc versions here :
>
> autoconf/toolchain.m4
>
> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>
> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>
>
> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>
> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>
> What is your preferred solution ?
>
>
> Thanks, Matthias
>
>



From matthias.baesken at sap.com  Thu Jul 13 11:16:43 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 13 Jul 2017 11:16:43 +0000
Subject: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in
 hotspot build
In-Reply-To: <a2c22c0e-b91a-7100-5cd8-c1c42fff8e33@oracle.com>
References: <a55bac4b639a4f13b7d6faa9e3084306@sap.com>
 <a2c22c0e-b91a-7100-5cd8-c1c42fff8e33@oracle.com>
Message-ID: <5b01357c0a84470c94d7ebd21d974816@sap.com>

Hi Erik,

> AFAIK, the only reason we support GCC versions older than 4.9 is for you 
> guys at SAP, so if you would suggest dropping support, that would of 
> course be the simplest solution.

  for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
 ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  , 
configure works nicely and then the build fails in the middle of the HS make )

autoconf/toolchain.m4

TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"

Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?

Best regards, Matthias




-----Original Message-----
From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
Sent: Donnerstag, 13. Juli 2017 11:59
To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

Hello Matthias,

AFAIK, the only reason we support GCC versions older than 4.9 is for you 
guys at SAP, so if you would suggest dropping support, that would of 
course be the simplest solution.

If you want to keep support but make the use of this flag optional, the 
preferred method is to add a test in flags.m4. We have macros defined 
for this. FLAGS_COMPILER_CHECK_ARGUMENTS or 
FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use 
it to check if the flag is valid for the current compiler. If so, you 
can define a variable 
"CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment" 
and empty otherwise, and in the makefile use this variable in the 
assignement.

We want to avoid static shell expressions in the makefiles if possible 
and keep that kind of logic in configure. It's also better to explicitly 
check for features rather than versions.

/Erik


On 2017-07-13 11:21, Baesken, Matthias wrote:
> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>
> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>
> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>
> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
> There are various solutions one could do  to avoid  the  compilation error .
>
>
> 1) disallow usage of old gcc versions here :
>
> autoconf/toolchain.m4
>
> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>
> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>
>
> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>
> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>
> What is your preferred solution ?
>
>
> Thanks, Matthias
>
>


From erik.joelsson at oracle.com  Thu Jul 13 11:33:38 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Jul 2017 13:33:38 +0200
Subject: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in
 hotspot build
In-Reply-To: <5b01357c0a84470c94d7ebd21d974816@sap.com>
References: <a55bac4b639a4f13b7d6faa9e3084306@sap.com>
 <a2c22c0e-b91a-7100-5cd8-c1c42fff8e33@oracle.com>
 <5b01357c0a84470c94d7ebd21d974816@sap.com>
Message-ID: <62771b89-5d6a-0bc4-2b38-35278bb7950c@oracle.com>

Hello,

That would be the correct place. If you prepare the change and send the 
review I can sponsor the push.

/Erik

On 2017-07-13 13:16, Baesken, Matthias wrote:
> Hi Erik,
>
>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>> guys at SAP, so if you would suggest dropping support, that would of
>> course be the simplest solution.
>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>   ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
> configure works nicely and then the build fails in the middle of the HS make )
>
> autoconf/toolchain.m4
>
> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>
> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>
> Best regards, Matthias
>
>
>
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Donnerstag, 13. Juli 2017 11:59
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> Hello Matthias,
>
> AFAIK, the only reason we support GCC versions older than 4.9 is for you
> guys at SAP, so if you would suggest dropping support, that would of
> course be the simplest solution.
>
> If you want to keep support but make the use of this flag optional, the
> preferred method is to add a test in flags.m4. We have macros defined
> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
> it to check if the flag is valid for the current compiler. If so, you
> can define a variable
> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
> and empty otherwise, and in the makefile use this variable in the
> assignement.
>
> We want to avoid static shell expressions in the makefiles if possible
> and keep that kind of logic in configure. It's also better to explicitly
> check for features rather than versions.
>
> /Erik
>
>
> On 2017-07-13 11:21, Baesken, Matthias wrote:
>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>
>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>
>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>
>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>> There are various solutions one could do  to avoid  the  compilation error .
>>
>>
>> 1) disallow usage of old gcc versions here :
>>
>> autoconf/toolchain.m4
>>
>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>
>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>
>>
>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>
>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>
>> What is your preferred solution ?
>>
>>
>> Thanks, Matthias
>>
>>



From matthias.baesken at sap.com  Thu Jul 13 12:18:56 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 13 Jul 2017 12:18:56 +0000
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS
 macro
Message-ID: <4d2f3964b0924ffa897074759e508653@sap.com>

> Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. 
> I can help you integrate the changes after they are reviewed.

Thanks for your feedback !

I created a bug :

https://bugs.openjdk.java.net/browse/JDK-8184323


and a webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/


Best regards, Matthias


-----Original Message-----
From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com] 
Sent: Montag, 10. Juli 2017 17:54
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net
Subject: Re: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro

Hi Matthias,

Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. I can help you integrate the changes after they are reviewed.

Thanks!
Jiangli

> On Jul 5, 2017, at 6:36 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
>  are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
>  when  CDS is disabled at compile time  :
> 
> 
> See  hotspot/make/lib/JvmFeatures.gmk  :
> 
> ifneq ($(call check-jvm-feature, cds), true)
>  JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0
> 
> 
> 
> However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in
> 
> 
> share/vm/prims/jvmtiRedefineClasses.cpp
> share/vm/memory/universe.cpp
> 
> (also some other places)
> 
> 
> Should I prepare a change and add the compile-time guard at the places where missing as well ?
> 
> Best regards, Matthias



From matthias.baesken at sap.com  Thu Jul 13 13:40:52 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 13 Jul 2017 13:40:52 +0000
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was
 : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in
 hotspot build
Message-ID: <6c85b34b225e417788f794a99269e9fb@sap.com>

Hi Erik, I prepared the change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/

bug :

https://bugs.openjdk.java.net/browse/JDK-8184338

Asking for review(s) ...


Best regards, Matthias




-----Original Message-----
From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
Sent: Donnerstag, 13. Juli 2017 13:34
To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

Hello,

That would be the correct place. If you prepare the change and send the 
review I can sponsor the push.

/Erik

On 2017-07-13 13:16, Baesken, Matthias wrote:
> Hi Erik,
>
>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>> guys at SAP, so if you would suggest dropping support, that would of
>> course be the simplest solution.
>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>   ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
> configure works nicely and then the build fails in the middle of the HS make )
>
> autoconf/toolchain.m4
>
> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>
> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>
> Best regards, Matthias
>
>
>
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Donnerstag, 13. Juli 2017 11:59
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> Hello Matthias,
>
> AFAIK, the only reason we support GCC versions older than 4.9 is for you
> guys at SAP, so if you would suggest dropping support, that would of
> course be the simplest solution.
>
> If you want to keep support but make the use of this flag optional, the
> preferred method is to add a test in flags.m4. We have macros defined
> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
> it to check if the flag is valid for the current compiler. If so, you
> can define a variable
> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
> and empty otherwise, and in the makefile use this variable in the
> assignement.
>
> We want to avoid static shell expressions in the makefiles if possible
> and keep that kind of logic in configure. It's also better to explicitly
> check for features rather than versions.
>
> /Erik
>
>
> On 2017-07-13 11:21, Baesken, Matthias wrote:
>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>
>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>
>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>
>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>> There are various solutions one could do  to avoid  the  compilation error .
>>
>>
>> 1) disallow usage of old gcc versions here :
>>
>> autoconf/toolchain.m4
>>
>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>
>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>
>>
>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>
>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>
>> What is your preferred solution ?
>>
>>
>> Thanks, Matthias
>>
>>


From erik.joelsson at oracle.com  Thu Jul 13 14:44:19 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Jul 2017 16:44:19 +0200
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <6c85b34b225e417788f794a99269e9fb@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
Message-ID: <4c644405-a75f-1ad0-db7d-be66a6a477a9@oracle.com>

Looks good to me.

/Erik


On 2017-07-13 15:40, Baesken, Matthias wrote:
> Hi Erik, I prepared the change :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>
> bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8184338
>
> Asking for review(s) ...
>
>
> Best regards, Matthias
>
>
>
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Donnerstag, 13. Juli 2017 13:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> Hello,
>
> That would be the correct place. If you prepare the change and send the
> review I can sponsor the push.
>
> /Erik
>
> On 2017-07-13 13:16, Baesken, Matthias wrote:
>> Hi Erik,
>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>     for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>    ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>> configure works nicely and then the build fails in the middle of the HS make )
>>
>> autoconf/toolchain.m4
>>
>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>
>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 11:59
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello Matthias,
>>
>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>> guys at SAP, so if you would suggest dropping support, that would of
>> course be the simplest solution.
>>
>> If you want to keep support but make the use of this flag optional, the
>> preferred method is to add a test in flags.m4. We have macros defined
>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>> it to check if the flag is valid for the current compiler. If so, you
>> can define a variable
>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>> and empty otherwise, and in the makefile use this variable in the
>> assignement.
>>
>> We want to avoid static shell expressions in the makefiles if possible
>> and keep that kind of logic in configure. It's also better to explicitly
>> check for features rather than versions.
>>
>> /Erik
>>
>>
>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>
>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>
>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>> There are various solutions one could do  to avoid  the  compilation error .
>>>
>>>
>>> 1) disallow usage of old gcc versions here :
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>
>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>
>>>
>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>
>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>
>>> What is your preferred solution ?
>>>
>>>
>>> Thanks, Matthias
>>>
>>>



From erik.joelsson at oracle.com  Thu Jul 13 14:46:07 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Jul 2017 16:46:07 +0200
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <4c644405-a75f-1ad0-db7d-be66a6a477a9@oracle.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <4c644405-a75f-1ad0-db7d-be66a6a477a9@oracle.com>
Message-ID: <9145f8aa-fb2c-00eb-3f52-a03d1d860b2c@oracle.com>

Just remembered, please also update the building documentation 
referencing 4.3 in common/docs/building.md.

/Erik


On 2017-07-13 16:44, Erik Joelsson wrote:
> Looks good to me.
>
> /Erik
>
>
> On 2017-07-13 15:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 
>> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 
>> 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ 
>> flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send the
>> review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is 
>>>> for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>     for jdk10  it is fine for us to  use  minimum gcc 4.8  . That 
>>> would be probably the most simple solution to avoid running into 
>>> the  "-fno-var-tracking-assignments"  issue
>>>    ( I now and then run into it when I forget to set the PATH to 
>>> gcc-4.8 one should use for compiling on the SLES11 machine, so I 
>>> pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the 
>>> HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for 
>>> Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 
>>> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 
>>> 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments 
>>> g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for 
>>> you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to 
>>> explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  
>>>> 4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag 
>>>> -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / 
>>>> -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary 
>>>>
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 
>>>> "know" the flag.
>>>> There are various solutions one could do  to avoid  the compilation 
>>>> error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the 
>>>> flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc 
>>>> versions here :
>>>> (in a similar way it was done : 
>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33: 
>>>> BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := 
>>>> -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34: 
>>>> BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := 
>>>> -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>
>



From hohensee at amazon.com  Thu Jul 13 15:46:00 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 13 Jul 2017 15:46:00 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
Message-ID: <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>

New webrev

http://cr.openjdk.java.net/~phh/8184022/webrev.02/

It includes ?with-macosx-version-max format checks (disallows ?without-macosx-version-max) and your jib-profiles.js patch. I put the checking logic in AC_ARG_WITH based on the code in basics.m4 line 597 that defines BASIC_SETUP_DEVKIT.

--with-macosx-version-max will fail the format checks and ?without-macosx-version-max will fail the check against ?xno?.

Paul

On 7/12/17, 1:15 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    Hello,
    
    
    On 2017-07-12 03:19, Hohensee, Paul wrote:
    > New webrev at
    >
    > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
    For the AC_ARG_WITH, we usually refrain from using the builtin "if-set, 
    if-not-set" parameters and define our own logic to handle all 4 
    possibilities: not set, --with-foobar=value, --with-foobar and 
    --without-foobar. The latter two results in the values "yes" and "no" 
    respectively and in this case those two are invalid and needs to result 
    in errors. Also since we are expecting a very specific format on the 
    input, we need to validate this format so we fail fast instead of 
    getting weird compile errors much later.
    
    My understanding of -mmacosx-version-min is that it sets 
    MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add that. OTOH, it 
    makes it more obvious where this comes from if anyone stumbles on it in 
    the source.
    > I defined a new shell variable MACOSX_VERSION_MAX which is settable via a new configure switch ?with-macosx-version-max=<version>. Example use: --with-macosx-version-max=10.12.00. The specified version is passed via a compiler command line switch, vis ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
    At what point did they introduce the double zeros at the end? Seems like 
    we will need guard the values quite carefully and make sure we zero pad 
    if needed.
    > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
    >
    > Tested by attempting builds on OSX 10.12.04.
    >
    > (1) no ?with-macosx-version-max: succeeds as expected because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so defaults to 10.12.04.
    > (2) ?with-macosx-version-max=10.11.00: fails as expected due to formal parameter type mismatch.
    > (3) ?with-macosx-version-max=10.12.00: succeeds as expected because formal parameter types are the same for all 10.12.xx.
    >
    > It?d be great if you could try it out.
    >
    > Note that successful cases (1) and (3) above provoke three warnings which I haven?t investigated. Imo, I/we can figure out how to get rid of these next/later.
    >
    > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) was built for newer OSX version (10.12) than being linked (10.7)
    > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) was built for newer OSX version (10.12) than being linked (10.7)
    > clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
    I believe the warnings for static libs is simply caused by not adding 
    -mmacosx-version-min to the ARFLAGS. Not sure if ar on mac takes that 
    flag though.
    
    The libstdc++ warning seems harder to work around until we change the 
    minimum to 10.9 instead of 10.7.
    
    I would appreciate if you could also include this patch as part of this 
    change to make Oracle builds still behave as before:
    
    diff -r a6c830ee8a67 common/conf/jib-profiles.js
    --- a/common/conf/jib-profiles.js
    +++ b/common/conf/jib-profiles.js
    @@ -436,7 +436,8 @@
                  target_os: "macosx",
                  target_cpu: "x64",
                  dependencies: ["devkit"],
    -            configure_args: concat(common.configure_args_64bit, 
    "--with-zlib=system"),
    +            configure_args: concat(common.configure_args_64bit, 
    "--with-zlib=system",
    +                "--with-macosx-version-max=10.7.0"),
              },
    
              "solaris-x64": {
    
    
    Thanks!
    /Erik
    > Paul
    >
    > On 7/11/17, 2:45 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >
    >      The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are
    >      used in combination to achieve the same thing. I chose to use both to
    >      really enforce full compatibility with the specified version. The
    >      "official" way of targeting earlier versions of the OS is just using
    >      -mmacosx-version-min. This will however still accept uses of newer APIs,
    >      but at link time, those will be linked with weak_import. Essentially
    >      it's expected that your application should be able to do without these
    >      calls if necessary, at the application level. While better than not
    >      being able to launch at all on the older OS, by adding
    >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any
    >      code tries to use a newer API.
    >      
    >      As I see it, either we fully enforce this at build time, or we don't at
    >      all. The natural default is to build for the current host platform. The
    >      configure parameter would make it possible to enforce a minimal
    >      compatible OS version that the binaries must be usable on.
    >      
    >      (Note that if you propose such a change, I will need to add the Oracle
    >      bit as well, where we use the parameter, which would need to go in at
    >      the same time in common/conf/jib-profiles.js. Also note that I will be
    >      on vacation for 5 weeks starting this weekend so won't be around to
    >      review for most of that time.)
    >      
    >      /Erik
    >      
    >      
    >      On 2017-07-10 19:48, Hohensee, Paul wrote:
    >      > That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
    >      >
    >      > Thanks,
    >      >
    >      > Paul
    >      >
    >      > On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >      >
    >      >
    >      >
    >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
    >      >      > Hi Erik,
    >      >      >
    >      >      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
    >      >      >
    >      >      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
    >      >      That's not exactly true. Apple is making it very hard to stay on older
    >      >      versions of the OS compared to other OS vendors. For this reason we are
    >      >      not always able to stay on a particular version for Macosx in
    >      >      particular. We also in general try to avoid having to fill our build
    >      >      servers/environments with just the oldest OSes, because older OSes are
    >      >      harder to maintain and less convenient to work with. So instead, we try
    >      >      to maintain working build environments on newer OSes that produce
    >      >      binaries that are compatible with the oldest we support. So, at least
    >      >      from Oracle's perspective, we prefer if builds on different OS versions
    >      >      produce equivalent binaries when possible. We certainly don't want to
    >      >      prevent building on newer OS/compilers.
    >      >
    >      >      If this can't be worked around at the source level, then perhaps we need
    >      >      to consider hiding this macro definition behind a configure option that
    >      >      we can use internally. I would be open to that. Something like
    >      >      --with-macosx-version-min=10.7 which configure could then translate to
    >      >      the combination of options currently used. That way, most openjdk
    >      >      developers/builders would not need to suffer this Oracle requirement.
    >      >
    >      >      /Erik
    >      >      > Thanks,
    >      >      >
    >      >      > Paul
    >      >      >
    >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >      >      >
    >      >      >      Hello,
    >      >      >
    >      >      >      I do not agree to removing that macro. I added those options to help
    >      >      >      guarantee that a build made on a newer version of macosx would still run
    >      >      >      on the oldest version currently supported. The macro is not mainly meant
    >      >      >      to be used in our code, but is picked up by system headers to cause an
    >      >      >      error if any features newer than 10.7 are used. It may be that we should
    >      >      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
    >      >      >
    >      >      >      It seems to me that we instead need to ignore the particular warning for
    >      >      >      this case.
    >      >      >
    >      >      >      /Erik
    >      >      >
    >      >      >
    >      >      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
    >      >      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
    >      >      >      >
    >      >      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
    >      >      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
    >      >      >      >
    >      >      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
    >      >      >      >
    >      >      >      > Slightly revised from the RFE:
    >      >      >      >
    >      >      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
    >      >      >      >
    >      >      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
    >      >      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
    >      >      >      >       __LP64__
    >      >      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
    >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
    >      >      >      >    #else
    >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
    >      >      >      >    #endif
    >      >      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
    >      >      >      >
    >      >      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
    >      >      >      >
    >      >      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
    >      >      >      >
    >      >      >      > Thanks,
    >      >      >      >
    >      >      >      > Paul
    >      >      >      >
    >      >      >
    >      >      >
    >      >      >
    >      >
    >      >
    >      >
    >      
    >      
    >
    
    


From erik.joelsson at oracle.com  Thu Jul 13 17:04:01 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 13 Jul 2017 19:04:01 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
 <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
Message-ID: <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>

This looks pretty good. A few points:

* Please use $GREP since configure is doing some work on finding a good 
grep for us. If you want to make the grep patterns more readable, it's 
possible to put the [] escapes around the whole expression, or at any 
level you wish. That way you don't need to repeat them for each [0-9]. 
Both styles are used throughout the configure script and I don't have a 
strong preference myself.

* The check for "no" got me thinking. If someone explicitly sets 
--without-macosx-version-max, that probably means they want it empty. 
The reason for doing so would be to override an earlier instance of the 
parameter on the command line (set by some script or automatic system 
that you can't directly influence). This is not a likely usecase but is 
perhaps a more correct action. Sorry for confusing this earlier. "yes" 
is definitely an error though.

I took this patch for a run here and it seems to work as it should from 
the Oracle point of view.

/Erik


On 2017-07-13 17:46, Hohensee, Paul wrote:
> New webrev
>
> http://cr.openjdk.java.net/~phh/8184022/webrev.02/
>
> It includes ?with-macosx-version-max format checks (disallows ?without-macosx-version-max) and your jib-profiles.js patch. I put the checking logic in AC_ARG_WITH based on the code in basics.m4 line 597 that defines BASIC_SETUP_DEVKIT.
>
> --with-macosx-version-max will fail the format checks and ?without-macosx-version-max will fail the check against ?xno?.
>
> Paul
>
> On 7/12/17, 1:15 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>
>      Hello,
>      
>      
>      On 2017-07-12 03:19, Hohensee, Paul wrote:
>      > New webrev at
>      >
>      > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
>      For the AC_ARG_WITH, we usually refrain from using the builtin "if-set,
>      if-not-set" parameters and define our own logic to handle all 4
>      possibilities: not set, --with-foobar=value, --with-foobar and
>      --without-foobar. The latter two results in the values "yes" and "no"
>      respectively and in this case those two are invalid and needs to result
>      in errors. Also since we are expecting a very specific format on the
>      input, we need to validate this format so we fail fast instead of
>      getting weird compile errors much later.
>      
>      My understanding of -mmacosx-version-min is that it sets
>      MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add that. OTOH, it
>      makes it more obvious where this comes from if anyone stumbles on it in
>      the source.
>      > I defined a new shell variable MACOSX_VERSION_MAX which is settable via a new configure switch ?with-macosx-version-max=<version>. Example use: --with-macosx-version-max=10.12.00. The specified version is passed via a compiler command line switch, vis ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
>      At what point did they introduce the double zeros at the end? Seems like
>      we will need guard the values quite carefully and make sure we zero pad
>      if needed.
>      > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
>      >
>      > Tested by attempting builds on OSX 10.12.04.
>      >
>      > (1) no ?with-macosx-version-max: succeeds as expected because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so defaults to 10.12.04.
>      > (2) ?with-macosx-version-max=10.11.00: fails as expected due to formal parameter type mismatch.
>      > (3) ?with-macosx-version-max=10.12.00: succeeds as expected because formal parameter types are the same for all 10.12.xx.
>      >
>      > It?d be great if you could try it out.
>      >
>      > Note that successful cases (1) and (3) above provoke three warnings which I haven?t investigated. Imo, I/we can figure out how to get rid of these next/later.
>      >
>      > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) was built for newer OSX version (10.12) than being linked (10.7)
>      > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) was built for newer OSX version (10.12) than being linked (10.7)
>      > clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
>      I believe the warnings for static libs is simply caused by not adding
>      -mmacosx-version-min to the ARFLAGS. Not sure if ar on mac takes that
>      flag though.
>      
>      The libstdc++ warning seems harder to work around until we change the
>      minimum to 10.9 instead of 10.7.
>      
>      I would appreciate if you could also include this patch as part of this
>      change to make Oracle builds still behave as before:
>      
>      diff -r a6c830ee8a67 common/conf/jib-profiles.js
>      --- a/common/conf/jib-profiles.js
>      +++ b/common/conf/jib-profiles.js
>      @@ -436,7 +436,8 @@
>                    target_os: "macosx",
>                    target_cpu: "x64",
>                    dependencies: ["devkit"],
>      -            configure_args: concat(common.configure_args_64bit,
>      "--with-zlib=system"),
>      +            configure_args: concat(common.configure_args_64bit,
>      "--with-zlib=system",
>      +                "--with-macosx-version-max=10.7.0"),
>                },
>      
>                "solaris-x64": {
>      
>      
>      Thanks!
>      /Erik
>      > Paul
>      >
>      > On 7/11/17, 2:45 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >
>      >      The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are
>      >      used in combination to achieve the same thing. I chose to use both to
>      >      really enforce full compatibility with the specified version. The
>      >      "official" way of targeting earlier versions of the OS is just using
>      >      -mmacosx-version-min. This will however still accept uses of newer APIs,
>      >      but at link time, those will be linked with weak_import. Essentially
>      >      it's expected that your application should be able to do without these
>      >      calls if necessary, at the application level. While better than not
>      >      being able to launch at all on the older OS, by adding
>      >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any
>      >      code tries to use a newer API.
>      >
>      >      As I see it, either we fully enforce this at build time, or we don't at
>      >      all. The natural default is to build for the current host platform. The
>      >      configure parameter would make it possible to enforce a minimal
>      >      compatible OS version that the binaries must be usable on.
>      >
>      >      (Note that if you propose such a change, I will need to add the Oracle
>      >      bit as well, where we use the parameter, which would need to go in at
>      >      the same time in common/conf/jib-profiles.js. Also note that I will be
>      >      on vacation for 5 weeks starting this weekend so won't be around to
>      >      review for most of that time.)
>      >
>      >      /Erik
>      >
>      >
>      >      On 2017-07-10 19:48, Hohensee, Paul wrote:
>      >      > That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
>      >      >
>      >      > Thanks,
>      >      >
>      >      > Paul
>      >      >
>      >      > On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >      >
>      >      >
>      >      >
>      >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
>      >      >      > Hi Erik,
>      >      >      >
>      >      >      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>      >      >      >
>      >      >      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
>      >      >      That's not exactly true. Apple is making it very hard to stay on older
>      >      >      versions of the OS compared to other OS vendors. For this reason we are
>      >      >      not always able to stay on a particular version for Macosx in
>      >      >      particular. We also in general try to avoid having to fill our build
>      >      >      servers/environments with just the oldest OSes, because older OSes are
>      >      >      harder to maintain and less convenient to work with. So instead, we try
>      >      >      to maintain working build environments on newer OSes that produce
>      >      >      binaries that are compatible with the oldest we support. So, at least
>      >      >      from Oracle's perspective, we prefer if builds on different OS versions
>      >      >      produce equivalent binaries when possible. We certainly don't want to
>      >      >      prevent building on newer OS/compilers.
>      >      >
>      >      >      If this can't be worked around at the source level, then perhaps we need
>      >      >      to consider hiding this macro definition behind a configure option that
>      >      >      we can use internally. I would be open to that. Something like
>      >      >      --with-macosx-version-min=10.7 which configure could then translate to
>      >      >      the combination of options currently used. That way, most openjdk
>      >      >      developers/builders would not need to suffer this Oracle requirement.
>      >      >
>      >      >      /Erik
>      >      >      > Thanks,
>      >      >      >
>      >      >      > Paul
>      >      >      >
>      >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >      >      >
>      >      >      >      Hello,
>      >      >      >
>      >      >      >      I do not agree to removing that macro. I added those options to help
>      >      >      >      guarantee that a build made on a newer version of macosx would still run
>      >      >      >      on the oldest version currently supported. The macro is not mainly meant
>      >      >      >      to be used in our code, but is picked up by system headers to cause an
>      >      >      >      error if any features newer than 10.7 are used. It may be that we should
>      >      >      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
>      >      >      >
>      >      >      >      It seems to me that we instead need to ignore the particular warning for
>      >      >      >      this case.
>      >      >      >
>      >      >      >      /Erik
>      >      >      >
>      >      >      >
>      >      >      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
>      >      >      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
>      >      >      >      >
>      >      >      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
>      >      >      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>      >      >      >      >
>      >      >      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
>      >      >      >      >
>      >      >      >      > Slightly revised from the RFE:
>      >      >      >      >
>      >      >      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>      >      >      >      >
>      >      >      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
>      >      >      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
>      >      >      >      >       __LP64__
>      >      >      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
>      >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
>      >      >      >      >    #else
>      >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
>      >      >      >      >    #endif
>      >      >      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>      >      >      >      >
>      >      >      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
>      >      >      >      >
>      >      >      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
>      >      >      >      >
>      >      >      >      > Thanks,
>      >      >      >      >
>      >      >      >      > Paul
>      >      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >
>      >      >
>      >      >
>      >
>      >
>      >
>      
>      
>



From hohensee at amazon.com  Thu Jul 13 17:24:31 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 13 Jul 2017 17:24:31 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
 <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
 <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>
Message-ID: <BDC77B0E-A828-4195-BEE3-FB81612A0DF4@amazon.com>

New webrev with two-line change to flags.m4 at line 1129.

http://cr.openjdk.java.net/~phh/8184022/webrev.03/

?xno? now means ?use build system default?, just as if the switch had not been used.

I?m a very inexperienced regex user, so I used what worked first for me. What would it look like to escape the whole expression or sub-expressions?

Paul

On 7/13/17, 10:04 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:

    This looks pretty good. A few points:
    
    * Please use $GREP since configure is doing some work on finding a good 
    grep for us. If you want to make the grep patterns more readable, it's 
    possible to put the [] escapes around the whole expression, or at any 
    level you wish. That way you don't need to repeat them for each [0-9]. 
    Both styles are used throughout the configure script and I don't have a 
    strong preference myself.
    
    * The check for "no" got me thinking. If someone explicitly sets 
    --without-macosx-version-max, that probably means they want it empty. 
    The reason for doing so would be to override an earlier instance of the 
    parameter on the command line (set by some script or automatic system 
    that you can't directly influence). This is not a likely usecase but is 
    perhaps a more correct action. Sorry for confusing this earlier. "yes" 
    is definitely an error though.
    
    I took this patch for a run here and it seems to work as it should from 
    the Oracle point of view.
    
    /Erik
    
    
    On 2017-07-13 17:46, Hohensee, Paul wrote:
    > New webrev
    >
    > http://cr.openjdk.java.net/~phh/8184022/webrev.02/
    >
    > It includes ?with-macosx-version-max format checks (disallows ?without-macosx-version-max) and your jib-profiles.js patch. I put the checking logic in AC_ARG_WITH based on the code in basics.m4 line 597 that defines BASIC_SETUP_DEVKIT.
    >
    > --with-macosx-version-max will fail the format checks and ?without-macosx-version-max will fail the check against ?xno?.
    >
    > Paul
    >
    > On 7/12/17, 1:15 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >
    >      Hello,
    >      
    >      
    >      On 2017-07-12 03:19, Hohensee, Paul wrote:
    >      > New webrev at
    >      >
    >      > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
    >      For the AC_ARG_WITH, we usually refrain from using the builtin "if-set,
    >      if-not-set" parameters and define our own logic to handle all 4
    >      possibilities: not set, --with-foobar=value, --with-foobar and
    >      --without-foobar. The latter two results in the values "yes" and "no"
    >      respectively and in this case those two are invalid and needs to result
    >      in errors. Also since we are expecting a very specific format on the
    >      input, we need to validate this format so we fail fast instead of
    >      getting weird compile errors much later.
    >      
    >      My understanding of -mmacosx-version-min is that it sets
    >      MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add that. OTOH, it
    >      makes it more obvious where this comes from if anyone stumbles on it in
    >      the source.
    >      > I defined a new shell variable MACOSX_VERSION_MAX which is settable via a new configure switch ?with-macosx-version-max=<version>. Example use: --with-macosx-version-max=10.12.00. The specified version is passed via a compiler command line switch, vis ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
    >      At what point did they introduce the double zeros at the end? Seems like
    >      we will need guard the values quite carefully and make sure we zero pad
    >      if needed.
    >      > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
    >      >
    >      > Tested by attempting builds on OSX 10.12.04.
    >      >
    >      > (1) no ?with-macosx-version-max: succeeds as expected because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so defaults to 10.12.04.
    >      > (2) ?with-macosx-version-max=10.11.00: fails as expected due to formal parameter type mismatch.
    >      > (3) ?with-macosx-version-max=10.12.00: succeeds as expected because formal parameter types are the same for all 10.12.xx.
    >      >
    >      > It?d be great if you could try it out.
    >      >
    >      > Note that successful cases (1) and (3) above provoke three warnings which I haven?t investigated. Imo, I/we can figure out how to get rid of these next/later.
    >      >
    >      > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) was built for newer OSX version (10.12) than being linked (10.7)
    >      > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) was built for newer OSX version (10.12) than being linked (10.7)
    >      > clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
    >      I believe the warnings for static libs is simply caused by not adding
    >      -mmacosx-version-min to the ARFLAGS. Not sure if ar on mac takes that
    >      flag though.
    >      
    >      The libstdc++ warning seems harder to work around until we change the
    >      minimum to 10.9 instead of 10.7.
    >      
    >      I would appreciate if you could also include this patch as part of this
    >      change to make Oracle builds still behave as before:
    >      
    >      diff -r a6c830ee8a67 common/conf/jib-profiles.js
    >      --- a/common/conf/jib-profiles.js
    >      +++ b/common/conf/jib-profiles.js
    >      @@ -436,7 +436,8 @@
    >                    target_os: "macosx",
    >                    target_cpu: "x64",
    >                    dependencies: ["devkit"],
    >      -            configure_args: concat(common.configure_args_64bit,
    >      "--with-zlib=system"),
    >      +            configure_args: concat(common.configure_args_64bit,
    >      "--with-zlib=system",
    >      +                "--with-macosx-version-max=10.7.0"),
    >                },
    >      
    >                "solaris-x64": {
    >      
    >      
    >      Thanks!
    >      /Erik
    >      > Paul
    >      >
    >      > On 7/11/17, 2:45 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >      >
    >      >      The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are
    >      >      used in combination to achieve the same thing. I chose to use both to
    >      >      really enforce full compatibility with the specified version. The
    >      >      "official" way of targeting earlier versions of the OS is just using
    >      >      -mmacosx-version-min. This will however still accept uses of newer APIs,
    >      >      but at link time, those will be linked with weak_import. Essentially
    >      >      it's expected that your application should be able to do without these
    >      >      calls if necessary, at the application level. While better than not
    >      >      being able to launch at all on the older OS, by adding
    >      >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any
    >      >      code tries to use a newer API.
    >      >
    >      >      As I see it, either we fully enforce this at build time, or we don't at
    >      >      all. The natural default is to build for the current host platform. The
    >      >      configure parameter would make it possible to enforce a minimal
    >      >      compatible OS version that the binaries must be usable on.
    >      >
    >      >      (Note that if you propose such a change, I will need to add the Oracle
    >      >      bit as well, where we use the parameter, which would need to go in at
    >      >      the same time in common/conf/jib-profiles.js. Also note that I will be
    >      >      on vacation for 5 weeks starting this weekend so won't be around to
    >      >      review for most of that time.)
    >      >
    >      >      /Erik
    >      >
    >      >
    >      >      On 2017-07-10 19:48, Hohensee, Paul wrote:
    >      >      > That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
    >      >      >
    >      >      > Thanks,
    >      >      >
    >      >      > Paul
    >      >      >
    >      >      > On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >      >      >
    >      >      >
    >      >      >
    >      >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
    >      >      >      > Hi Erik,
    >      >      >      >
    >      >      >      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
    >      >      >      >
    >      >      >      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
    >      >      >      That's not exactly true. Apple is making it very hard to stay on older
    >      >      >      versions of the OS compared to other OS vendors. For this reason we are
    >      >      >      not always able to stay on a particular version for Macosx in
    >      >      >      particular. We also in general try to avoid having to fill our build
    >      >      >      servers/environments with just the oldest OSes, because older OSes are
    >      >      >      harder to maintain and less convenient to work with. So instead, we try
    >      >      >      to maintain working build environments on newer OSes that produce
    >      >      >      binaries that are compatible with the oldest we support. So, at least
    >      >      >      from Oracle's perspective, we prefer if builds on different OS versions
    >      >      >      produce equivalent binaries when possible. We certainly don't want to
    >      >      >      prevent building on newer OS/compilers.
    >      >      >
    >      >      >      If this can't be worked around at the source level, then perhaps we need
    >      >      >      to consider hiding this macro definition behind a configure option that
    >      >      >      we can use internally. I would be open to that. Something like
    >      >      >      --with-macosx-version-min=10.7 which configure could then translate to
    >      >      >      the combination of options currently used. That way, most openjdk
    >      >      >      developers/builders would not need to suffer this Oracle requirement.
    >      >      >
    >      >      >      /Erik
    >      >      >      > Thanks,
    >      >      >      >
    >      >      >      > Paul
    >      >      >      >
    >      >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >      >      >      >
    >      >      >      >      Hello,
    >      >      >      >
    >      >      >      >      I do not agree to removing that macro. I added those options to help
    >      >      >      >      guarantee that a build made on a newer version of macosx would still run
    >      >      >      >      on the oldest version currently supported. The macro is not mainly meant
    >      >      >      >      to be used in our code, but is picked up by system headers to cause an
    >      >      >      >      error if any features newer than 10.7 are used. It may be that we should
    >      >      >      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
    >      >      >      >
    >      >      >      >      It seems to me that we instead need to ignore the particular warning for
    >      >      >      >      this case.
    >      >      >      >
    >      >      >      >      /Erik
    >      >      >      >
    >      >      >      >
    >      >      >      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
    >      >      >      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
    >      >      >      >      >
    >      >      >      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
    >      >      >      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
    >      >      >      >      >
    >      >      >      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
    >      >      >      >      >
    >      >      >      >      > Slightly revised from the RFE:
    >      >      >      >      >
    >      >      >      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
    >      >      >      >      >
    >      >      >      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
    >      >      >      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
    >      >      >      >      >       __LP64__
    >      >      >      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
    >      >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
    >      >      >      >      >    #else
    >      >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
    >      >      >      >      >    #endif
    >      >      >      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
    >      >      >      >      >
    >      >      >      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
    >      >      >      >      >
    >      >      >      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
    >      >      >      >      >
    >      >      >      >      > Thanks,
    >      >      >      >      >
    >      >      >      >      > Paul
    >      >      >      >      >
    >      >      >      >
    >      >      >      >
    >      >      >      >
    >      >      >
    >      >      >
    >      >      >
    >      >
    >      >
    >      >
    >      
    >      
    >
    
    


From simon at cjnash.com  Thu Jul 13 19:56:19 2017
From: simon at cjnash.com (Simon Nash)
Date: Thu, 13 Jul 2017 20:56:19 +0100
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8
 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag
 in hotspot build
In-Reply-To: <6c85b34b225e417788f794a99269e9fb@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
Message-ID: <5967D063.1010808@cjnash.com>

I am currently building JDK 9 for arm32 (hard float and soft float) using
a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
this cannot be supported for JDK 10?

Best regards,
Simon

On 13/07/2017 14:40, Baesken, Matthias wrote:
> Hi Erik, I prepared the change :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
> 
> bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8184338
> 
> Asking for review(s) ...
> 
> 
> Best regards, Matthias
> 
> 
> 
> 
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
> Sent: Donnerstag, 13. Juli 2017 13:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
> 
> Hello,
> 
> That would be the correct place. If you prepare the change and send the 
> review I can sponsor the push.
> 
> /Erik
> 
> On 2017-07-13 13:16, Baesken, Matthias wrote:
>> Hi Erik,
>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>   ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>> configure works nicely and then the build fails in the middle of the HS make )
>>
>> autoconf/toolchain.m4
>>
>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>
>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 11:59
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello Matthias,
>>
>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>> guys at SAP, so if you would suggest dropping support, that would of
>> course be the simplest solution.
>>
>> If you want to keep support but make the use of this flag optional, the
>> preferred method is to add a test in flags.m4. We have macros defined
>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>> it to check if the flag is valid for the current compiler. If so, you
>> can define a variable
>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>> and empty otherwise, and in the makefile use this variable in the
>> assignement.
>>
>> We want to avoid static shell expressions in the makefiles if possible
>> and keep that kind of logic in configure. It's also better to explicitly
>> check for features rather than versions.
>>
>> /Erik
>>
>>
>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>
>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>
>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>> There are various solutions one could do  to avoid  the  compilation error .
>>>
>>>
>>> 1) disallow usage of old gcc versions here :
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>
>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>
>>>
>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>
>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>
>>> What is your preferred solution ?
>>>
>>>
>>> Thanks, Matthias
>>>
>>>
> 



From matthias.baesken at sap.com  Fri Jul 14 06:35:51 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 14 Jul 2017 06:35:51 +0000
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <5967D063.1010808@cjnash.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com>
Message-ID: <424e7257bc504fe09d967ce56d64afd1@sap.com>

> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?

Hi Simon,
   reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.

My first  suggestion was  :

>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )

 So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).

Best regards, Matthias



-----Original Message-----
From: Simon Nash [mailto:simon at cjnash.com] 
Sent: Donnerstag, 13. Juli 2017 21:56
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

I am currently building JDK 9 for arm32 (hard float and soft float) using
a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
this cannot be supported for JDK 10?

Best regards,
Simon

On 13/07/2017 14:40, Baesken, Matthias wrote:
> Hi Erik, I prepared the change :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
> 
> bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8184338
> 
> Asking for review(s) ...
> 
> 
> Best regards, Matthias
> 
> 
> 
> 
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
> Sent: Donnerstag, 13. Juli 2017 13:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
> 
> Hello,
> 
> That would be the correct place. If you prepare the change and send the 
> review I can sponsor the push.
> 
> /Erik
> 
> On 2017-07-13 13:16, Baesken, Matthias wrote:
>> Hi Erik,
>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>   ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>> configure works nicely and then the build fails in the middle of the HS make )
>>
>> autoconf/toolchain.m4
>>
>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>
>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 11:59
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello Matthias,
>>
>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>> guys at SAP, so if you would suggest dropping support, that would of
>> course be the simplest solution.
>>
>> If you want to keep support but make the use of this flag optional, the
>> preferred method is to add a test in flags.m4. We have macros defined
>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>> it to check if the flag is valid for the current compiler. If so, you
>> can define a variable
>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>> and empty otherwise, and in the makefile use this variable in the
>> assignement.
>>
>> We want to avoid static shell expressions in the makefiles if possible
>> and keep that kind of logic in configure. It's also better to explicitly
>> check for features rather than versions.
>>
>> /Erik
>>
>>
>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>
>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>
>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>> There are various solutions one could do  to avoid  the  compilation error .
>>>
>>>
>>> 1) disallow usage of old gcc versions here :
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>
>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>
>>>
>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>
>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>
>>> What is your preferred solution ?
>>>
>>>
>>> Thanks, Matthias
>>>
>>>
> 


From erik.joelsson at oracle.com  Fri Jul 14 06:45:05 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jul 2017 08:45:05 +0200
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <5967D063.1010808@cjnash.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com>
Message-ID: <157cc89c-b481-6797-9dc1-b504965fdf1f@oracle.com>

 From my point of view, the minimum version is a bit arbitrary. We have 
identified that we likely need 4.6 or newer now, so we could set the 
limit to 4.6 or 4.7 if needed. Supporting very old compilers have a 
cost. The setting here will only cause a warning to be printed that 
essentially means we don't test builds with this old compiler and we 
won't make any effort in keeping it working. I would expect 4.7 to 
continue to work for a time anyway.

Eventually though, we will upgrade the recommended toolchain and we will 
start using newer compiler features that will make older compilers 
obsolete for real.

/Erik


On 2017-07-13 21:56, Simon Nash wrote:
> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason 
> that
> this cannot be supported for JDK 10?
>
> Best regards,
> Simon
>
> On 13/07/2017 14:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] Sent: 
>> Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 
>> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 
>> 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ 
>> flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send 
>> the review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is 
>>>> for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That 
>>> would be probably the most simple solution to avoid running into 
>>> the  "-fno-var-tracking-assignments"  issue
>>>   ( I now and then run into it when I forget to set the PATH to 
>>> gcc-4.8 one should use for compiling on the SLES11 machine, so I 
>>> pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the 
>>> HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for 
>>> Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 
>>> 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 
>>> 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments 
>>> g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for 
>>> you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to 
>>> explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  
>>>> 4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag 
>>>> -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / 
>>>> -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary 
>>>>
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 
>>>> "know" the flag.
>>>> There are various solutions one could do  to avoid  the compilation 
>>>> error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the 
>>>> flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc 
>>>> versions here :
>>>> (in a similar way it was done : 
>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33: 
>>>> BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := 
>>>> -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34: 
>>>> BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := 
>>>> -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>
>>
>



From erik.joelsson at oracle.com  Fri Jul 14 06:53:28 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jul 2017 08:53:28 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <BDC77B0E-A828-4195-BEE3-FB81612A0DF4@amazon.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
 <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
 <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>
 <BDC77B0E-A828-4195-BEE3-FB81612A0DF4@amazon.com>
Message-ID: <8ef320d8-63e7-b481-a450-f92999a03615@oracle.com>

This looks good to me. Never mind the regexps, they are fine.

I can sponsor the change since it touches configure and will need a 
corresponding closed change. Do you mind if I push this to jdk10/jdk10 
instead of hs? That way it will get to hs within a week, but also be in 
jdk10, while going the other way, it will take much longer before it 
hits jdk10.

/Erik

On 2017-07-13 19:24, Hohensee, Paul wrote:
> New webrev with two-line change to flags.m4 at line 1129.
>
> http://cr.openjdk.java.net/~phh/8184022/webrev.03/
>
> ?xno? now means ?use build system default?, just as if the switch had not been used.
>
> I?m a very inexperienced regex user, so I used what worked first for me. What would it look like to escape the whole expression or sub-expressions?
>
> Paul
>
> On 7/13/17, 10:04 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>
>      This looks pretty good. A few points:
>      
>      * Please use $GREP since configure is doing some work on finding a good
>      grep for us. If you want to make the grep patterns more readable, it's
>      possible to put the [] escapes around the whole expression, or at any
>      level you wish. That way you don't need to repeat them for each [0-9].
>      Both styles are used throughout the configure script and I don't have a
>      strong preference myself.
>      
>      * The check for "no" got me thinking. If someone explicitly sets
>      --without-macosx-version-max, that probably means they want it empty.
>      The reason for doing so would be to override an earlier instance of the
>      parameter on the command line (set by some script or automatic system
>      that you can't directly influence). This is not a likely usecase but is
>      perhaps a more correct action. Sorry for confusing this earlier. "yes"
>      is definitely an error though.
>      
>      I took this patch for a run here and it seems to work as it should from
>      the Oracle point of view.
>      
>      /Erik
>      
>      
>      On 2017-07-13 17:46, Hohensee, Paul wrote:
>      > New webrev
>      >
>      > http://cr.openjdk.java.net/~phh/8184022/webrev.02/
>      >
>      > It includes ?with-macosx-version-max format checks (disallows ?without-macosx-version-max) and your jib-profiles.js patch. I put the checking logic in AC_ARG_WITH based on the code in basics.m4 line 597 that defines BASIC_SETUP_DEVKIT.
>      >
>      > --with-macosx-version-max will fail the format checks and ?without-macosx-version-max will fail the check against ?xno?.
>      >
>      > Paul
>      >
>      > On 7/12/17, 1:15 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >
>      >      Hello,
>      >
>      >
>      >      On 2017-07-12 03:19, Hohensee, Paul wrote:
>      >      > New webrev at
>      >      >
>      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
>      >      For the AC_ARG_WITH, we usually refrain from using the builtin "if-set,
>      >      if-not-set" parameters and define our own logic to handle all 4
>      >      possibilities: not set, --with-foobar=value, --with-foobar and
>      >      --without-foobar. The latter two results in the values "yes" and "no"
>      >      respectively and in this case those two are invalid and needs to result
>      >      in errors. Also since we are expecting a very specific format on the
>      >      input, we need to validate this format so we fail fast instead of
>      >      getting weird compile errors much later.
>      >
>      >      My understanding of -mmacosx-version-min is that it sets
>      >      MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add that. OTOH, it
>      >      makes it more obvious where this comes from if anyone stumbles on it in
>      >      the source.
>      >      > I defined a new shell variable MACOSX_VERSION_MAX which is settable via a new configure switch ?with-macosx-version-max=<version>. Example use: --with-macosx-version-max=10.12.00. The specified version is passed via a compiler command line switch, vis ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
>      >      At what point did they introduce the double zeros at the end? Seems like
>      >      we will need guard the values quite carefully and make sure we zero pad
>      >      if needed.
>      >      > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
>      >      >
>      >      > Tested by attempting builds on OSX 10.12.04.
>      >      >
>      >      > (1) no ?with-macosx-version-max: succeeds as expected because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so defaults to 10.12.04.
>      >      > (2) ?with-macosx-version-max=10.11.00: fails as expected due to formal parameter type mismatch.
>      >      > (3) ?with-macosx-version-max=10.12.00: succeeds as expected because formal parameter types are the same for all 10.12.xx.
>      >      >
>      >      > It?d be great if you could try it out.
>      >      >
>      >      > Note that successful cases (1) and (3) above provoke three warnings which I haven?t investigated. Imo, I/we can figure out how to get rid of these next/later.
>      >      >
>      >      > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) was built for newer OSX version (10.12) than being linked (10.7)
>      >      > ld: warning: object file (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) was built for newer OSX version (10.12) than being linked (10.7)
>      >      > clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
>      >      I believe the warnings for static libs is simply caused by not adding
>      >      -mmacosx-version-min to the ARFLAGS. Not sure if ar on mac takes that
>      >      flag though.
>      >
>      >      The libstdc++ warning seems harder to work around until we change the
>      >      minimum to 10.9 instead of 10.7.
>      >
>      >      I would appreciate if you could also include this patch as part of this
>      >      change to make Oracle builds still behave as before:
>      >
>      >      diff -r a6c830ee8a67 common/conf/jib-profiles.js
>      >      --- a/common/conf/jib-profiles.js
>      >      +++ b/common/conf/jib-profiles.js
>      >      @@ -436,7 +436,8 @@
>      >                    target_os: "macosx",
>      >                    target_cpu: "x64",
>      >                    dependencies: ["devkit"],
>      >      -            configure_args: concat(common.configure_args_64bit,
>      >      "--with-zlib=system"),
>      >      +            configure_args: concat(common.configure_args_64bit,
>      >      "--with-zlib=system",
>      >      +                "--with-macosx-version-max=10.7.0"),
>      >                },
>      >
>      >                "solaris-x64": {
>      >
>      >
>      >      Thanks!
>      >      /Erik
>      >      > Paul
>      >      >
>      >      > On 7/11/17, 2:45 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >      >
>      >      >      The -DMAC_OSX_VERSION_MAX_ALLOWED and -mmacosx-version-min arguments are
>      >      >      used in combination to achieve the same thing. I chose to use both to
>      >      >      really enforce full compatibility with the specified version. The
>      >      >      "official" way of targeting earlier versions of the OS is just using
>      >      >      -mmacosx-version-min. This will however still accept uses of newer APIs,
>      >      >      but at link time, those will be linked with weak_import. Essentially
>      >      >      it's expected that your application should be able to do without these
>      >      >      calls if necessary, at the application level. While better than not
>      >      >      being able to launch at all on the older OS, by adding
>      >      >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a compile time error if any
>      >      >      code tries to use a newer API.
>      >      >
>      >      >      As I see it, either we fully enforce this at build time, or we don't at
>      >      >      all. The natural default is to build for the current host platform. The
>      >      >      configure parameter would make it possible to enforce a minimal
>      >      >      compatible OS version that the binaries must be usable on.
>      >      >
>      >      >      (Note that if you propose such a change, I will need to add the Oracle
>      >      >      bit as well, where we use the parameter, which would need to go in at
>      >      >      the same time in common/conf/jib-profiles.js. Also note that I will be
>      >      >      on vacation for 5 weeks starting this weekend so won't be around to
>      >      >      review for most of that time.)
>      >      >
>      >      >      /Erik
>      >      >
>      >      >
>      >      >      On 2017-07-10 19:48, Hohensee, Paul wrote:
>      >      >      > That?s a good idea, though the option would be --with-macosx-version-max=<n>, right? The minimum is currently hard-coded and should probably stay that way since there?s likely a lot of code that depends on it. Let me see what I can come up with.
>      >      >      >
>      >      >      > Thanks,
>      >      >      >
>      >      >      > Paul
>      >      >      >
>      >      >      > On 7/10/17, 10:01 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
>      >      >      >      > Hi Erik,
>      >      >      >      >
>      >      >      >      > The problem is that the compiler doesn?t issue a warning in this case, but rather a type-mismatch error on NSEventMask, so I can?t turn it off. NSUInteger was being used as an enum, so Apple changed to using a real enum in 10.12 as a matter of code hygiene. The new code in NSApplicationAWT.m is doing the right thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>      >      >      >      >
>      >      >      >      > What particular problem were you trying to solve? Production, QA and JPRT builds and test runs are done on the oldest supported OSX version, so any use of newer features should be detected very early in the test process. Restricting builds to old OSX versions means that engineers who keep their development boxes up to date (which they should: security, etc.) can?t use them to do JDK development.
>      >      >      >      That's not exactly true. Apple is making it very hard to stay on older
>      >      >      >      versions of the OS compared to other OS vendors. For this reason we are
>      >      >      >      not always able to stay on a particular version for Macosx in
>      >      >      >      particular. We also in general try to avoid having to fill our build
>      >      >      >      servers/environments with just the oldest OSes, because older OSes are
>      >      >      >      harder to maintain and less convenient to work with. So instead, we try
>      >      >      >      to maintain working build environments on newer OSes that produce
>      >      >      >      binaries that are compatible with the oldest we support. So, at least
>      >      >      >      from Oracle's perspective, we prefer if builds on different OS versions
>      >      >      >      produce equivalent binaries when possible. We certainly don't want to
>      >      >      >      prevent building on newer OS/compilers.
>      >      >      >
>      >      >      >      If this can't be worked around at the source level, then perhaps we need
>      >      >      >      to consider hiding this macro definition behind a configure option that
>      >      >      >      we can use internally. I would be open to that. Something like
>      >      >      >      --with-macosx-version-min=10.7 which configure could then translate to
>      >      >      >      the combination of options currently used. That way, most openjdk
>      >      >      >      developers/builders would not need to suffer this Oracle requirement.
>      >      >      >
>      >      >      >      /Erik
>      >      >      >      > Thanks,
>      >      >      >      >
>      >      >      >      > Paul
>      >      >      >      >
>      >      >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>      >      >      >      >
>      >      >      >      >      Hello,
>      >      >      >      >
>      >      >      >      >      I do not agree to removing that macro. I added those options to help
>      >      >      >      >      guarantee that a build made on a newer version of macosx would still run
>      >      >      >      >      on the oldest version currently supported. The macro is not mainly meant
>      >      >      >      >      to be used in our code, but is picked up by system headers to cause an
>      >      >      >      >      error if any features newer than 10.7 are used. It may be that we should
>      >      >      >      >      bump it to a newer version of macosx in JDK 10, but certainly not to 10.12.
>      >      >      >      >
>      >      >      >      >      It seems to me that we instead need to ignore the particular warning for
>      >      >      >      >      this case.
>      >      >      >      >
>      >      >      >      >      /Erik
>      >      >      >      >
>      >      >      >      >
>      >      >      >      >      On 2017-07-09 15:26, Hohensee, Paul wrote:
>      >      >      >      >      > Please review the following change to get JDK10 to build on OSX 10.12 and above.
>      >      >      >      >      >
>      >      >      >      >      > https://bugs.openjdk.java.net/browse/JDK-8184022
>      >      >      >      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>      >      >      >      >      >
>      >      >      >      >      > I?d very much appreciate a sponsor for this fix. Imo, successful JDK10 builds on all supported platforms would be sufficient testing, but please let me know what I can do to help.
>      >      >      >      >      >
>      >      >      >      >      > Slightly revised from the RFE:
>      >      >      >      >      >
>      >      >      >      >      > JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled previously disabled clang warnings and was intended to also enable builds on OSX 10 + Xcode 8. Due to a mixup, this code in jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>      >      >      >      >      >
>      >      >      >      >      >    #if defined(MAC_OS_X_VERSION_10_12) && \
>      >      >      >      >      >       MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_12 && \
>      >      >      >      >      >       __LP64__
>      >      >      >      >      >       / 10.12 changed `mask` to NSEventMask (unsigned long long) for x86_64 builds.
>      >      >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSEventMask)mask
>      >      >      >      >      >    #else
>      >      >      >      >      >    - (NSEvent *)nextEventMatchingMask:(NSUInteger)mask
>      >      >      >      >      >    #endif
>      >      >      >      >      >    untilDate:(NSDate *)expiration inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>      >      >      >      >      >
>      >      >      >      >      > works fine with OSX versions earlier than 10.12, but fails to compile starting with OSX 10.12 due to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command line as 10.7.
>      >      >      >      >      >
>      >      >      >      >      > The fix is to remove that definition, since it places an artificial upper bound on the OSX version under which JDK10 can be built. A source code search reveals no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. The latter won't be affected by this change, since it checks for a version > 10.5, which is always true in JDK10.
>      >      >      >      >      >
>      >      >      >      >      > Thanks,
>      >      >      >      >      >
>      >      >      >      >      > Paul
>      >      >      >      >      >
>      >      >      >      >
>      >      >      >      >
>      >      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >
>      >      >
>      >      >
>      >
>      >
>      >
>      
>      
>



From glaubitz at physik.fu-berlin.de  Fri Jul 14 09:23:11 2017
From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz)
Date: Fri, 14 Jul 2017 11:23:11 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <bdfd9a55-fa97-dca3-5063-cf3abc2d7b93@oracle.com>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
 <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
 <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>
 <78dbbda5-f3ea-009e-3989-95a2292a0a46@physik.fu-berlin.de>
 <CAA-vtUzd-H7fM6JfDAL7fT6q9gL4d7DVy_zE-6gEmUbGsVupHA@mail.gmail.com>
 <bdfd9a55-fa97-dca3-5063-cf3abc2d7b93@oracle.com>
Message-ID: <20170714092310.GB26530@physik.fu-berlin.de>

Hi Erik!

On Thu, Jul 06, 2017 at 02:55:53PM +0200, Erik Helin wrote:
> >Yes, you now have two reviewers. But for these changes (hotspot) you
> >need a sponsor, which needs to be an Oracle employee, which I am not.
> >
> >Maybe Eric could sponsor the change?
> 
> Yep, I can shepherd the patches in (aka getting them through the build and
> test system we all know as JPRT). Thanks Thomas for reviewing!
> Erik

Can you tell me what the current status of the patches are? Have they
been merged yet? Which repository are they going to get merged? I have
searched through the various JDK repositories and couldn't find it
last time I checked.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


From matthias.baesken at sap.com  Fri Jul 14 11:47:02 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 14 Jul 2017 11:47:02 +0000
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <424e7257bc504fe09d967ce56d64afd1@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
Message-ID: <2ac4b05d05434369bdeb72f7018d00f8@sap.com>

After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
And created a new webrev  :

http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/

- check adjusted to minimum gcc 4.7  
- common/doc/building.md    adjusted  (the part talking about gcc versions)


Best regards, Matthias



-----Original Message-----
From: Baesken, Matthias 
Sent: Freitag, 14. Juli 2017 08:36
To: 'Simon Nash' <simon at cjnash.com>
Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?

Hi Simon,
   reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.

My first  suggestion was  :

>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )

 So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).

Best regards, Matthias



-----Original Message-----
From: Simon Nash [mailto:simon at cjnash.com] 
Sent: Donnerstag, 13. Juli 2017 21:56
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

I am currently building JDK 9 for arm32 (hard float and soft float) using
a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
this cannot be supported for JDK 10?

Best regards,
Simon

On 13/07/2017 14:40, Baesken, Matthias wrote:
> Hi Erik, I prepared the change :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
> 
> bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8184338
> 
> Asking for review(s) ...
> 
> 
> Best regards, Matthias
> 
> 
> 
> 
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
> Sent: Donnerstag, 13. Juli 2017 13:34
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
> 
> Hello,
> 
> That would be the correct place. If you prepare the change and send the 
> review I can sponsor the push.
> 
> /Erik
> 
> On 2017-07-13 13:16, Baesken, Matthias wrote:
>> Hi Erik,
>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>   ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>> configure works nicely and then the build fails in the middle of the HS make )
>>
>> autoconf/toolchain.m4
>>
>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>
>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 11:59
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello Matthias,
>>
>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>> guys at SAP, so if you would suggest dropping support, that would of
>> course be the simplest solution.
>>
>> If you want to keep support but make the use of this flag optional, the
>> preferred method is to add a test in flags.m4. We have macros defined
>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>> it to check if the flag is valid for the current compiler. If so, you
>> can define a variable
>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>> and empty otherwise, and in the makefile use this variable in the
>> assignement.
>>
>> We want to avoid static shell expressions in the makefiles if possible
>> and keep that kind of logic in configure. It's also better to explicitly
>> check for features rather than versions.
>>
>> /Erik
>>
>>
>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>
>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>
>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>
>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>> There are various solutions one could do  to avoid  the  compilation error .
>>>
>>>
>>> 1) disallow usage of old gcc versions here :
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>
>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>
>>>
>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>
>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>
>>> What is your preferred solution ?
>>>
>>>
>>> Thanks, Matthias
>>>
>>>
> 


From erik.helin at oracle.com  Fri Jul 14 12:23:14 2017
From: erik.helin at oracle.com (Erik Helin)
Date: Fri, 14 Jul 2017 14:23:14 +0200
Subject: [PATCH] linux-sparc build fixes
In-Reply-To: <20170714092310.GB26530@physik.fu-berlin.de>
References: <20170609102041.GA2477@physik.fu-berlin.de>
 <bde3077b-73be-ecc3-975e-78cbe15acdbf@oracle.com>
 <20170704093304.GD28259@physik.fu-berlin.de>
 <CAA-vtUxnnzb9Am3-j1htLbiZXo83WyyJ2BrBRiWHuuSxHPgFng@mail.gmail.com>
 <e6637681-aa72-5d6a-5e16-ccc3fd6a6a9e@physik.fu-berlin.de>
 <CAA-vtUxuB4qFw+D2mJY2G2iTy2mBGf+fxdjNitc_MqtFRE+a=Q@mail.gmail.com>
 <78dbbda5-f3ea-009e-3989-95a2292a0a46@physik.fu-berlin.de>
 <CAA-vtUzd-H7fM6JfDAL7fT6q9gL4d7DVy_zE-6gEmUbGsVupHA@mail.gmail.com>
 <bdfd9a55-fa97-dca3-5063-cf3abc2d7b93@oracle.com>
 <20170714092310.GB26530@physik.fu-berlin.de>
Message-ID: <e0d7852c-cb3d-d7c2-c589-84a26e406960@oracle.com>

On 07/14/2017 11:23 AM, John Paul Adrian Glaubitz wrote:
> Hi Erik!
> 
> On Thu, Jul 06, 2017 at 02:55:53PM +0200, Erik Helin wrote:
>>> Yes, you now have two reviewers. But for these changes (hotspot) you
>>> need a sponsor, which needs to be an Oracle employee, which I am not.
>>>
>>> Maybe Eric could sponsor the change?
>>
>> Yep, I can shepherd the patches in (aka getting them through the build and
>> test system we all know as JPRT). Thanks Thomas for reviewing!
>> Erik
> 
> Can you tell me what the current status of the patches are? Have they
> been merged yet? Which repository are they going to get merged? I have
> searched through the various JDK repositories and couldn't find it
> last time I checked.

Sorry, I haven't gotten around to do this until now. The patches are 
currently running on the build server and assuming everything is fine, 
will end up in http://hg.openjdk.java.net/jdk10/hs/hotspot.

Thanks,
Erik

> Thanks,
> Adrian
> 


From erik.joelsson at oracle.com  Fri Jul 14 12:39:47 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jul 2017 14:39:47 +0200
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
Message-ID: <54952e80-0602-7645-6f7c-df5efadaf9bd@oracle.com>

Looks good to me.

/Erik


On 2017-07-14 13:47, Baesken, Matthias wrote:
> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
> And created a new webrev  :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
>
> - check adjusted to minimum gcc 4.7
> - common/doc/building.md    adjusted  (the part talking about gcc versions)
>
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Freitag, 14. Juli 2017 08:36
> To: 'Simon Nash' <simon at cjnash.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
> Hi Simon,
>     reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
>
> My first  suggestion was  :
>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>   So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Simon Nash [mailto:simon at cjnash.com]
> Sent: Donnerstag, 13. Juli 2017 21:56
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?
>
> Best regards,
> Simon
>
> On 13/07/2017 14:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send the
>> review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>     for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>    ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>



From erik.joelsson at oracle.com  Fri Jul 14 12:43:08 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jul 2017 14:43:08 +0200
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
Message-ID: <948004c4-63e7-b0e4-1820-bf2351fc2327@oracle.com>

This looks good to me.

/Erik


On 2017-07-14 13:47, Baesken, Matthias wrote:
> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
> And created a new webrev  :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
>
> - check adjusted to minimum gcc 4.7
> - common/doc/building.md    adjusted  (the part talking about gcc versions)
>
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Freitag, 14. Juli 2017 08:36
> To: 'Simon Nash' <simon at cjnash.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
> Hi Simon,
>     reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
>
> My first  suggestion was  :
>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>   So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Simon Nash [mailto:simon at cjnash.com]
> Sent: Donnerstag, 13. Juli 2017 21:56
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?
>
> Best regards,
> Simon
>
> On 13/07/2017 14:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send the
>> review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>     for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>    ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>



From simon at cjnash.com  Fri Jul 14 13:15:56 2017
From: simon at cjnash.com (Simon Nash)
Date: Fri, 14 Jul 2017 14:15:56 +0100
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8
 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag
 in hotspot build
In-Reply-To: <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
Message-ID: <5968C40C.3010503@cjnash.com>

Hi Matthias,
Thanks very much for making this change.

Best regards,
Simon

On 14/07/2017 12:47, Baesken, Matthias wrote:
> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
> And created a new webrev  :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
> 
> - check adjusted to minimum gcc 4.7  
> - common/doc/building.md    adjusted  (the part talking about gcc versions)
> 
> 
> Best regards, Matthias
> 
> 
> 
> -----Original Message-----
> From: Baesken, Matthias 
> Sent: Freitag, 14. Juli 2017 08:36
> To: 'Simon Nash' <simon at cjnash.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
> 
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
> 
> Hi Simon,
>    reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
> 
> My first  suggestion was  :
> 
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
> 
>  So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
> 
> Best regards, Matthias
> 
> 
> 
> -----Original Message-----
> From: Simon Nash [mailto:simon at cjnash.com] 
> Sent: Donnerstag, 13. Juli 2017 21:56
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
> 
> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?
> 
> Best regards,
> Simon
> 
> On 13/07/2017 14:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
>> Sent: Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send the 
>> review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>    for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>   ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>
> 



From erik.joelsson at oracle.com  Fri Jul 14 14:02:52 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jul 2017 16:02:52 +0200
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <8ef320d8-63e7-b481-a450-f92999a03615@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
 <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
 <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>
 <BDC77B0E-A828-4195-BEE3-FB81612A0DF4@amazon.com>
 <8ef320d8-63e7-b481-a450-f92999a03615@oracle.com>
Message-ID: <08d70b62-d8a0-e301-6fce-c65d8dbd18af@oracle.com>

I realized I spoke too soon. I won't be able to sponsor this anytime 
soon as I'm about to leave on vacation now. Hopefully someone else will 
be able to pick this up for you.

/Erik


On 2017-07-14 08:53, Erik Joelsson wrote:
> This looks good to me. Never mind the regexps, they are fine.
>
> I can sponsor the change since it touches configure and will need a 
> corresponding closed change. Do you mind if I push this to jdk10/jdk10 
> instead of hs? That way it will get to hs within a week, but also be 
> in jdk10, while going the other way, it will take much longer before 
> it hits jdk10.
>
> /Erik
>
> On 2017-07-13 19:24, Hohensee, Paul wrote:
>> New webrev with two-line change to flags.m4 at line 1129.
>>
>> http://cr.openjdk.java.net/~phh/8184022/webrev.03/
>>
>> ?xno? now means ?use build system default?, just as if the switch had 
>> not been used.
>>
>> I?m a very inexperienced regex user, so I used what worked first for 
>> me. What would it look like to escape the whole expression or 
>> sub-expressions?
>>
>> Paul
>>
>> On 7/13/17, 10:04 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>>
>>      This looks pretty good. A few points:
>>           * Please use $GREP since configure is doing some work on 
>> finding a good
>>      grep for us. If you want to make the grep patterns more 
>> readable, it's
>>      possible to put the [] escapes around the whole expression, or 
>> at any
>>      level you wish. That way you don't need to repeat them for each 
>> [0-9].
>>      Both styles are used throughout the configure script and I don't 
>> have a
>>      strong preference myself.
>>           * The check for "no" got me thinking. If someone explicitly 
>> sets
>>      --without-macosx-version-max, that probably means they want it 
>> empty.
>>      The reason for doing so would be to override an earlier instance 
>> of the
>>      parameter on the command line (set by some script or automatic 
>> system
>>      that you can't directly influence). This is not a likely usecase 
>> but is
>>      perhaps a more correct action. Sorry for confusing this earlier. 
>> "yes"
>>      is definitely an error though.
>>           I took this patch for a run here and it seems to work as it 
>> should from
>>      the Oracle point of view.
>>           /Erik
>>                On 2017-07-13 17:46, Hohensee, Paul wrote:
>>      > New webrev
>>      >
>>      > http://cr.openjdk.java.net/~phh/8184022/webrev.02/
>>      >
>>      > It includes ?with-macosx-version-max format checks (disallows 
>> ?without-macosx-version-max) and your jib-profiles.js patch. I put 
>> the checking logic in AC_ARG_WITH based on the code in basics.m4 line 
>> 597 that defines BASIC_SETUP_DEVKIT.
>>      >
>>      > --with-macosx-version-max will fail the format checks and 
>> ?without-macosx-version-max will fail the check against ?xno?.
>>      >
>>      > Paul
>>      >
>>      > On 7/12/17, 1:15 AM, "Erik Joelsson" 
>> <erik.joelsson at oracle.com> wrote:
>>      >
>>      >      Hello,
>>      >
>>      >
>>      >      On 2017-07-12 03:19, Hohensee, Paul wrote:
>>      >      > New webrev at
>>      >      >
>>      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
>>      >      For the AC_ARG_WITH, we usually refrain from using the 
>> builtin "if-set,
>>      >      if-not-set" parameters and define our own logic to handle 
>> all 4
>>      >      possibilities: not set, --with-foobar=value, 
>> --with-foobar and
>>      >      --without-foobar. The latter two results in the values 
>> "yes" and "no"
>>      >      respectively and in this case those two are invalid and 
>> needs to result
>>      >      in errors. Also since we are expecting a very specific 
>> format on the
>>      >      input, we need to validate this format so we fail fast 
>> instead of
>>      >      getting weird compile errors much later.
>>      >
>>      >      My understanding of -mmacosx-version-min is that it sets
>>      >      MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add 
>> that. OTOH, it
>>      >      makes it more obvious where this comes from if anyone 
>> stumbles on it in
>>      >      the source.
>>      >      > I defined a new shell variable MACOSX_VERSION_MAX which 
>> is settable via a new configure switch 
>> ?with-macosx-version-max=<version>. Example use: 
>> --with-macosx-version-max=10.12.00. The specified version is passed 
>> via a compiler command line switch, vis 
>> ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
>>      >      At what point did they introduce the double zeros at the 
>> end? Seems like
>>      >      we will need guard the values quite carefully and make 
>> sure we zero pad
>>      >      if needed.
>>      >      > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is 
>> now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070 
>> rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
>>      >      >
>>      >      > Tested by attempting builds on OSX 10.12.04.
>>      >      >
>>      >      > (1) no ?with-macosx-version-max: succeeds as expected 
>> because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so 
>> defaults to 10.12.04.
>>      >      > (2) ?with-macosx-version-max=10.11.00: fails as 
>> expected due to formal parameter type mismatch.
>>      >      > (3) ?with-macosx-version-max=10.12.00: succeeds as 
>> expected because formal parameter types are the same for all 10.12.xx.
>>      >      >
>>      >      > It?d be great if you could try it out.
>>      >      >
>>      >      > Note that successful cases (1) and (3) above provoke 
>> three warnings which I haven?t investigated. Imo, I/we can figure out 
>> how to get rid of these next/later.
>>      >      >
>>      >      > ld: warning: object file 
>> (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a) 
>> was built for newer OSX version (10.12) than being linked (10.7)
>>      >      > ld: warning: object file 
>> (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a) 
>> was built for newer OSX version (10.12) than being linked (10.7)
>>      >      > clang: warning: libstdc++ is deprecated; move to libc++ 
>> with a minimum deployment target of OS X 10.9 [-Wdeprecated]
>>      >      I believe the warnings for static libs is simply caused 
>> by not adding
>>      >      -mmacosx-version-min to the ARFLAGS. Not sure if ar on 
>> mac takes that
>>      >      flag though.
>>      >
>>      >      The libstdc++ warning seems harder to work around until 
>> we change the
>>      >      minimum to 10.9 instead of 10.7.
>>      >
>>      >      I would appreciate if you could also include this patch 
>> as part of this
>>      >      change to make Oracle builds still behave as before:
>>      >
>>      >      diff -r a6c830ee8a67 common/conf/jib-profiles.js
>>      >      --- a/common/conf/jib-profiles.js
>>      >      +++ b/common/conf/jib-profiles.js
>>      >      @@ -436,7 +436,8 @@
>>      >                    target_os: "macosx",
>>      >                    target_cpu: "x64",
>>      >                    dependencies: ["devkit"],
>>      >      -            configure_args: 
>> concat(common.configure_args_64bit,
>>      >      "--with-zlib=system"),
>>      >      +            configure_args: 
>> concat(common.configure_args_64bit,
>>      >      "--with-zlib=system",
>>      >      + "--with-macosx-version-max=10.7.0"),
>>      >                },
>>      >
>>      >                "solaris-x64": {
>>      >
>>      >
>>      >      Thanks!
>>      >      /Erik
>>      >      > Paul
>>      >      >
>>      >      > On 7/11/17, 2:45 AM, "Erik Joelsson" 
>> <erik.joelsson at oracle.com> wrote:
>>      >      >
>>      >      >      The -DMAC_OSX_VERSION_MAX_ALLOWED and 
>> -mmacosx-version-min arguments are
>>      >      >      used in combination to achieve the same thing. I 
>> chose to use both to
>>      >      >      really enforce full compatibility with the 
>> specified version. The
>>      >      >      "official" way of targeting earlier versions of 
>> the OS is just using
>>      >      >      -mmacosx-version-min. This will however still 
>> accept uses of newer APIs,
>>      >      >      but at link time, those will be linked with 
>> weak_import. Essentially
>>      >      >      it's expected that your application should be able 
>> to do without these
>>      >      >      calls if necessary, at the application level. 
>> While better than not
>>      >      >      being able to launch at all on the older OS, by 
>> adding
>>      >      >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a 
>> compile time error if any
>>      >      >      code tries to use a newer API.
>>      >      >
>>      >      >      As I see it, either we fully enforce this at build 
>> time, or we don't at
>>      >      >      all. The natural default is to build for the 
>> current host platform. The
>>      >      >      configure parameter would make it possible to 
>> enforce a minimal
>>      >      >      compatible OS version that the binaries must be 
>> usable on.
>>      >      >
>>      >      >      (Note that if you propose such a change, I will 
>> need to add the Oracle
>>      >      >      bit as well, where we use the parameter, which 
>> would need to go in at
>>      >      >      the same time in common/conf/jib-profiles.js. Also 
>> note that I will be
>>      >      >      on vacation for 5 weeks starting this weekend so 
>> won't be around to
>>      >      >      review for most of that time.)
>>      >      >
>>      >      >      /Erik
>>      >      >
>>      >      >
>>      >      >      On 2017-07-10 19:48, Hohensee, Paul wrote:
>>      >      >      > That?s a good idea, though the option would be 
>> --with-macosx-version-max=<n>, right? The minimum is currently 
>> hard-coded and should probably stay that way since there?s likely a 
>> lot of code that depends on it. Let me see what I can come up with.
>>      >      >      >
>>      >      >      > Thanks,
>>      >      >      >
>>      >      >      > Paul
>>      >      >      >
>>      >      >      > On 7/10/17, 10:01 AM, "Erik Joelsson" 
>> <erik.joelsson at oracle.com> wrote:
>>      >      >      >
>>      >      >      >
>>      >      >      >
>>      >      >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
>>      >      >      >      > Hi Erik,
>>      >      >      >      >
>>      >      >      >      > The problem is that the compiler doesn?t 
>> issue a warning in this case, but rather a type-mismatch error on 
>> NSEventMask, so I can?t turn it off. NSUInteger was being used as an 
>> enum, so Apple changed to using a real enum in 10.12 as a matter of 
>> code hygiene. The new code in NSApplicationAWT.m is doing the right 
>> thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>>      >      >      >      >
>>      >      >      >      > What particular problem were you trying 
>> to solve? Production, QA and JPRT builds and test runs are done on 
>> the oldest supported OSX version, so any use of newer features should 
>> be detected very early in the test process. Restricting builds to old 
>> OSX versions means that engineers who keep their development boxes up 
>> to date (which they should: security, etc.) can?t use them to do JDK 
>> development.
>>      >      >      >      That's not exactly true. Apple is making it 
>> very hard to stay on older
>>      >      >      >      versions of the OS compared to other OS 
>> vendors. For this reason we are
>>      >      >      >      not always able to stay on a particular 
>> version for Macosx in
>>      >      >      >      particular. We also in general try to avoid 
>> having to fill our build
>>      >      >      >      servers/environments with just the oldest 
>> OSes, because older OSes are
>>      >      >      >      harder to maintain and less convenient to 
>> work with. So instead, we try
>>      >      >      >      to maintain working build environments on 
>> newer OSes that produce
>>      >      >      >      binaries that are compatible with the 
>> oldest we support. So, at least
>>      >      >      >      from Oracle's perspective, we prefer if 
>> builds on different OS versions
>>      >      >      >      produce equivalent binaries when possible. 
>> We certainly don't want to
>>      >      >      >      prevent building on newer OS/compilers.
>>      >      >      >
>>      >      >      >      If this can't be worked around at the 
>> source level, then perhaps we need
>>      >      >      >      to consider hiding this macro definition 
>> behind a configure option that
>>      >      >      >      we can use internally. I would be open to 
>> that. Something like
>>      >      >      > --with-macosx-version-min=10.7 which configure 
>> could then translate to
>>      >      >      >      the combination of options currently used. 
>> That way, most openjdk
>>      >      >      >      developers/builders would not need to 
>> suffer this Oracle requirement.
>>      >      >      >
>>      >      >      >      /Erik
>>      >      >      >      > Thanks,
>>      >      >      >      >
>>      >      >      >      > Paul
>>      >      >      >      >
>>      >      >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson" 
>> <erik.joelsson at oracle.com> wrote:
>>      >      >      >      >
>>      >      >      >      >      Hello,
>>      >      >      >      >
>>      >      >      >      >      I do not agree to removing that 
>> macro. I added those options to help
>>      >      >      >      >      guarantee that a build made on a 
>> newer version of macosx would still run
>>      >      >      >      >      on the oldest version currently 
>> supported. The macro is not mainly meant
>>      >      >      >      >      to be used in our code, but is 
>> picked up by system headers to cause an
>>      >      >      >      >      error if any features newer than 
>> 10.7 are used. It may be that we should
>>      >      >      >      >      bump it to a newer version of macosx 
>> in JDK 10, but certainly not to 10.12.
>>      >      >      >      >
>>      >      >      >      >      It seems to me that we instead need 
>> to ignore the particular warning for
>>      >      >      >      >      this case.
>>      >      >      >      >
>>      >      >      >      >      /Erik
>>      >      >      >      >
>>      >      >      >      >
>>      >      >      >      >      On 2017-07-09 15:26, Hohensee, Paul 
>> wrote:
>>      >      >      >      >      > Please review the following change 
>> to get JDK10 to build on OSX 10.12 and above.
>>      >      >      >      >      >
>>      >      >      >      >      > 
>> https://bugs.openjdk.java.net/browse/JDK-8184022
>>      >      >      >      >      > 
>> http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>>      >      >      >      >      >
>>      >      >      >      >      > I?d very much appreciate a sponsor 
>> for this fix. Imo, successful JDK10 builds on all supported platforms 
>> would be sufficient testing, but please let me know what I can do to 
>> help.
>>      >      >      >      >      >
>>      >      >      >      >      > Slightly revised from the RFE:
>>      >      >      >      >      >
>>      >      >      >      >      > 
>> JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled 
>> previously disabled clang warnings and was intended to also enable 
>> builds on OSX 10 + Xcode 8. Due to a mixup, this code in 
>> jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>>      >      >      >      >      >
>>      >      >      >      >      >    #if 
>> defined(MAC_OS_X_VERSION_10_12) && \
>>      >      >      >      >      > MAC_OS_X_VERSION_MAX_ALLOWED >= 
>> MAC_OS_X_VERSION_10_12 && \
>>      >      >      >      >      >       __LP64__
>>      >      >      >      >      >       / 10.12 changed `mask` to 
>> NSEventMask (unsigned long long) for x86_64 builds.
>>      >      >      >      >      >    - (NSEvent 
>> *)nextEventMatchingMask:(NSEventMask)mask
>>      >      >      >      >      >    #else
>>      >      >      >      >      >    - (NSEvent 
>> *)nextEventMatchingMask:(NSUInteger)mask
>>      >      >      >      >      >    #endif
>>      >      >      >      >      > untilDate:(NSDate *)expiration 
>> inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>>      >      >      >      >      >
>>      >      >      >      >      > works fine with OSX versions 
>> earlier than 10.12, but fails to compile starting with OSX 10.12 due 
>> to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command 
>> line as 10.7.
>>      >      >      >      >      >
>>      >      >      >      >      > The fix is to remove that 
>> definition, since it places an artificial upper bound on the OSX 
>> version under which JDK10 can be built. A source code search reveals 
>> no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in 
>> NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp. 
>> The latter won't be affected by this change, since it checks for a 
>> version > 10.5, which is always true in JDK10.
>>      >      >      >      >      >
>>      >      >      >      >      > Thanks,
>>      >      >      >      >      >
>>      >      >      >      >      > Paul
>>      >      >      >      >      >
>>      >      >      >      >
>>      >      >      >      >
>>      >      >      >      >
>>      >      >      >
>>      >      >      >
>>      >      >      >
>>      >      >
>>      >      >
>>      >      >
>>      >
>>      >
>>      >
>>
>



From matthias.baesken at sap.com  Fri Jul 14 15:05:02 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 14 Jul 2017 15:05:02 +0000
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <948004c4-63e7-b0e4-1820-bf2351fc2327@oracle.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
 <948004c4-63e7-b0e4-1820-bf2351fc2327@oracle.com>
Message-ID: <738dc2d22854475f9a15e163f7038872@sap.com>

Thanks , can you push it ( as far as I know someone from Oracle needs to push it because generated-configure.sh  is changed ) ?

Best regards, Matthias



-----Original Message-----
From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
Sent: Freitag, 14. Juli 2017 14:43
To: Baesken, Matthias <matthias.baesken at sap.com>; Simon Nash <simon at cjnash.com>
Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

This looks good to me.

/Erik


On 2017-07-14 13:47, Baesken, Matthias wrote:
> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
> And created a new webrev  :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
>
> - check adjusted to minimum gcc 4.7
> - common/doc/building.md    adjusted  (the part talking about gcc versions)
>
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Freitag, 14. Juli 2017 08:36
> To: 'Simon Nash' <simon at cjnash.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
> Hi Simon,
>     reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
>
> My first  suggestion was  :
>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>   So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Simon Nash [mailto:simon at cjnash.com]
> Sent: Donnerstag, 13. Juli 2017 21:56
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?
>
> Best regards,
> Simon
>
> On 13/07/2017 14:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send the
>> review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>     for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>    ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>


From tim.bell at oracle.com  Fri Jul 14 16:04:53 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 14 Jul 2017 09:04:53 -0700
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <08d70b62-d8a0-e301-6fce-c65d8dbd18af@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
 <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
 <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>
 <BDC77B0E-A828-4195-BEE3-FB81612A0DF4@amazon.com>
 <8ef320d8-63e7-b481-a450-f92999a03615@oracle.com>
 <08d70b62-d8a0-e301-6fce-c65d8dbd18af@oracle.com>
Message-ID: <5968EBA5.2060606@oracle.com>

I can pick this up and sponsor it, but as Erik wrote, I'll be pushing to 
jdk10/jdk10.

Tim

On 07/14/17 07:02, Erik Joelsson wrote:
> I realized I spoke too soon. I won't be able to sponsor this anytime
> soon as I'm about to leave on vacation now. Hopefully someone else will
> be able to pick this up for you.
>
> /Erik
>
>
> On 2017-07-14 08:53, Erik Joelsson wrote:
>> This looks good to me. Never mind the regexps, they are fine.
>>
>> I can sponsor the change since it touches configure and will need a
>> corresponding closed change. Do you mind if I push this to jdk10/jdk10
>> instead of hs? That way it will get to hs within a week, but also be
>> in jdk10, while going the other way, it will take much longer before
>> it hits jdk10.
>>
>> /Erik
>>
>> On 2017-07-13 19:24, Hohensee, Paul wrote:
>>> New webrev with two-line change to flags.m4 at line 1129.
>>>
>>> http://cr.openjdk.java.net/~phh/8184022/webrev.03/
>>>
>>> ?xno? now means ?use build system default?, just as if the switch had
>>> not been used.
>>>
>>> I?m a very inexperienced regex user, so I used what worked first for
>>> me. What would it look like to escape the whole expression or
>>> sub-expressions?
>>>
>>> Paul
>>>
>>> On 7/13/17, 10:04 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>>>
>>>      This looks pretty good. A few points:
>>>           * Please use $GREP since configure is doing some work on
>>> finding a good
>>>      grep for us. If you want to make the grep patterns more
>>> readable, it's
>>>      possible to put the [] escapes around the whole expression, or
>>> at any
>>>      level you wish. That way you don't need to repeat them for each
>>> [0-9].
>>>      Both styles are used throughout the configure script and I don't
>>> have a
>>>      strong preference myself.
>>>           * The check for "no" got me thinking. If someone explicitly
>>> sets
>>>      --without-macosx-version-max, that probably means they want it
>>> empty.
>>>      The reason for doing so would be to override an earlier instance
>>> of the
>>>      parameter on the command line (set by some script or automatic
>>> system
>>>      that you can't directly influence). This is not a likely usecase
>>> but is
>>>      perhaps a more correct action. Sorry for confusing this earlier.
>>> "yes"
>>>      is definitely an error though.
>>>           I took this patch for a run here and it seems to work as it
>>> should from
>>>      the Oracle point of view.
>>>           /Erik
>>>                On 2017-07-13 17:46, Hohensee, Paul wrote:
>>>      > New webrev
>>>      >
>>>      > http://cr.openjdk.java.net/~phh/8184022/webrev.02/
>>>      >
>>>      > It includes ?with-macosx-version-max format checks (disallows
>>> ?without-macosx-version-max) and your jib-profiles.js patch. I put
>>> the checking logic in AC_ARG_WITH based on the code in basics.m4 line
>>> 597 that defines BASIC_SETUP_DEVKIT.
>>>      >
>>>      > --with-macosx-version-max will fail the format checks and
>>> ?without-macosx-version-max will fail the check against ?xno?.
>>>      >
>>>      > Paul
>>>      >
>>>      > On 7/12/17, 1:15 AM, "Erik Joelsson"
>>> <erik.joelsson at oracle.com> wrote:
>>>      >
>>>      >      Hello,
>>>      >
>>>      >
>>>      >      On 2017-07-12 03:19, Hohensee, Paul wrote:
>>>      >      > New webrev at
>>>      >      >
>>>      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
>>>      >      For the AC_ARG_WITH, we usually refrain from using the
>>> builtin "if-set,
>>>      >      if-not-set" parameters and define our own logic to handle
>>> all 4
>>>      >      possibilities: not set, --with-foobar=value,
>>> --with-foobar and
>>>      >      --without-foobar. The latter two results in the values
>>> "yes" and "no"
>>>      >      respectively and in this case those two are invalid and
>>> needs to result
>>>      >      in errors. Also since we are expecting a very specific
>>> format on the
>>>      >      input, we need to validate this format so we fail fast
>>> instead of
>>>      >      getting weird compile errors much later.
>>>      >
>>>      >      My understanding of -mmacosx-version-min is that it sets
>>>      >      MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add
>>> that. OTOH, it
>>>      >      makes it more obvious where this comes from if anyone
>>> stumbles on it in
>>>      >      the source.
>>>      >      > I defined a new shell variable MACOSX_VERSION_MAX which
>>> is settable via a new configure switch
>>> ?with-macosx-version-max=<version>. Example use:
>>> --with-macosx-version-max=10.12.00. The specified version is passed
>>> via a compiler command line switch, vis
>>> ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
>>>      >      At what point did they introduce the double zeros at the
>>> end? Seems like
>>>      >      we will need guard the values quite carefully and make
>>> sure we zero pad
>>>      >      if needed.
>>>      >      > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is
>>> now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070
>>> rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
>>>      >      >
>>>      >      > Tested by attempting builds on OSX 10.12.04.
>>>      >      >
>>>      >      > (1) no ?with-macosx-version-max: succeeds as expected
>>> because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so
>>> defaults to 10.12.04.
>>>      >      > (2) ?with-macosx-version-max=10.11.00: fails as
>>> expected due to formal parameter type mismatch.
>>>      >      > (3) ?with-macosx-version-max=10.12.00: succeeds as
>>> expected because formal parameter types are the same for all 10.12.xx.
>>>      >      >
>>>      >      > It?d be great if you could try it out.
>>>      >      >
>>>      >      > Note that successful cases (1) and (3) above provoke
>>> three warnings which I haven?t investigated. Imo, I/we can figure out
>>> how to get rid of these next/later.
>>>      >      >
>>>      >      > ld: warning: object file
>>> (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>>      >      > ld: warning: object file
>>> (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>>      >      > clang: warning: libstdc++ is deprecated; move to libc++
>>> with a minimum deployment target of OS X 10.9 [-Wdeprecated]
>>>      >      I believe the warnings for static libs is simply caused
>>> by not adding
>>>      >      -mmacosx-version-min to the ARFLAGS. Not sure if ar on
>>> mac takes that
>>>      >      flag though.
>>>      >
>>>      >      The libstdc++ warning seems harder to work around until
>>> we change the
>>>      >      minimum to 10.9 instead of 10.7.
>>>      >
>>>      >      I would appreciate if you could also include this patch
>>> as part of this
>>>      >      change to make Oracle builds still behave as before:
>>>      >
>>>      >      diff -r a6c830ee8a67 common/conf/jib-profiles.js
>>>      >      --- a/common/conf/jib-profiles.js
>>>      >      +++ b/common/conf/jib-profiles.js
>>>      >      @@ -436,7 +436,8 @@
>>>      >                    target_os: "macosx",
>>>      >                    target_cpu: "x64",
>>>      >                    dependencies: ["devkit"],
>>>      >      -            configure_args:
>>> concat(common.configure_args_64bit,
>>>      >      "--with-zlib=system"),
>>>      >      +            configure_args:
>>> concat(common.configure_args_64bit,
>>>      >      "--with-zlib=system",
>>>      >      + "--with-macosx-version-max=10.7.0"),
>>>      >                },
>>>      >
>>>      >                "solaris-x64": {
>>>      >
>>>      >
>>>      >      Thanks!
>>>      >      /Erik
>>>      >      > Paul
>>>      >      >
>>>      >      > On 7/11/17, 2:45 AM, "Erik Joelsson"
>>> <erik.joelsson at oracle.com> wrote:
>>>      >      >
>>>      >      >      The -DMAC_OSX_VERSION_MAX_ALLOWED and
>>> -mmacosx-version-min arguments are
>>>      >      >      used in combination to achieve the same thing. I
>>> chose to use both to
>>>      >      >      really enforce full compatibility with the
>>> specified version. The
>>>      >      >      "official" way of targeting earlier versions of
>>> the OS is just using
>>>      >      >      -mmacosx-version-min. This will however still
>>> accept uses of newer APIs,
>>>      >      >      but at link time, those will be linked with
>>> weak_import. Essentially
>>>      >      >      it's expected that your application should be able
>>> to do without these
>>>      >      >      calls if necessary, at the application level.
>>> While better than not
>>>      >      >      being able to launch at all on the older OS, by
>>> adding
>>>      >      >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a
>>> compile time error if any
>>>      >      >      code tries to use a newer API.
>>>      >      >
>>>      >      >      As I see it, either we fully enforce this at build
>>> time, or we don't at
>>>      >      >      all. The natural default is to build for the
>>> current host platform. The
>>>      >      >      configure parameter would make it possible to
>>> enforce a minimal
>>>      >      >      compatible OS version that the binaries must be
>>> usable on.
>>>      >      >
>>>      >      >      (Note that if you propose such a change, I will
>>> need to add the Oracle
>>>      >      >      bit as well, where we use the parameter, which
>>> would need to go in at
>>>      >      >      the same time in common/conf/jib-profiles.js. Also
>>> note that I will be
>>>      >      >      on vacation for 5 weeks starting this weekend so
>>> won't be around to
>>>      >      >      review for most of that time.)
>>>      >      >
>>>      >      >      /Erik
>>>      >      >
>>>      >      >
>>>      >      >      On 2017-07-10 19:48, Hohensee, Paul wrote:
>>>      >      >      > That?s a good idea, though the option would be
>>> --with-macosx-version-max=<n>, right? The minimum is currently
>>> hard-coded and should probably stay that way since there?s likely a
>>> lot of code that depends on it. Let me see what I can come up with.
>>>      >      >      >
>>>      >      >      > Thanks,
>>>      >      >      >
>>>      >      >      > Paul
>>>      >      >      >
>>>      >      >      > On 7/10/17, 10:01 AM, "Erik Joelsson"
>>> <erik.joelsson at oracle.com> wrote:
>>>      >      >      >
>>>      >      >      >
>>>      >      >      >
>>>      >      >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
>>>      >      >      >      > Hi Erik,
>>>      >      >      >      >
>>>      >      >      >      > The problem is that the compiler doesn?t
>>> issue a warning in this case, but rather a type-mismatch error on
>>> NSEventMask, so I can?t turn it off. NSUInteger was being used as an
>>> enum, so Apple changed to using a real enum in 10.12 as a matter of
>>> code hygiene. The new code in NSApplicationAWT.m is doing the right
>>> thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
>>>      >      >      >      >
>>>      >      >      >      > What particular problem were you trying
>>> to solve? Production, QA and JPRT builds and test runs are done on
>>> the oldest supported OSX version, so any use of newer features should
>>> be detected very early in the test process. Restricting builds to old
>>> OSX versions means that engineers who keep their development boxes up
>>> to date (which they should: security, etc.) can?t use them to do JDK
>>> development.
>>>      >      >      >      That's not exactly true. Apple is making it
>>> very hard to stay on older
>>>      >      >      >      versions of the OS compared to other OS
>>> vendors. For this reason we are
>>>      >      >      >      not always able to stay on a particular
>>> version for Macosx in
>>>      >      >      >      particular. We also in general try to avoid
>>> having to fill our build
>>>      >      >      >      servers/environments with just the oldest
>>> OSes, because older OSes are
>>>      >      >      >      harder to maintain and less convenient to
>>> work with. So instead, we try
>>>      >      >      >      to maintain working build environments on
>>> newer OSes that produce
>>>      >      >      >      binaries that are compatible with the
>>> oldest we support. So, at least
>>>      >      >      >      from Oracle's perspective, we prefer if
>>> builds on different OS versions
>>>      >      >      >      produce equivalent binaries when possible.
>>> We certainly don't want to
>>>      >      >      >      prevent building on newer OS/compilers.
>>>      >      >      >
>>>      >      >      >      If this can't be worked around at the
>>> source level, then perhaps we need
>>>      >      >      >      to consider hiding this macro definition
>>> behind a configure option that
>>>      >      >      >      we can use internally. I would be open to
>>> that. Something like
>>>      >      >      > --with-macosx-version-min=10.7 which configure
>>> could then translate to
>>>      >      >      >      the combination of options currently used.
>>> That way, most openjdk
>>>      >      >      >      developers/builders would not need to
>>> suffer this Oracle requirement.
>>>      >      >      >
>>>      >      >      >      /Erik
>>>      >      >      >      > Thanks,
>>>      >      >      >      >
>>>      >      >      >      > Paul
>>>      >      >      >      >
>>>      >      >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson"
>>> <erik.joelsson at oracle.com> wrote:
>>>      >      >      >      >
>>>      >      >      >      >      Hello,
>>>      >      >      >      >
>>>      >      >      >      >      I do not agree to removing that
>>> macro. I added those options to help
>>>      >      >      >      >      guarantee that a build made on a
>>> newer version of macosx would still run
>>>      >      >      >      >      on the oldest version currently
>>> supported. The macro is not mainly meant
>>>      >      >      >      >      to be used in our code, but is
>>> picked up by system headers to cause an
>>>      >      >      >      >      error if any features newer than
>>> 10.7 are used. It may be that we should
>>>      >      >      >      >      bump it to a newer version of macosx
>>> in JDK 10, but certainly not to 10.12.
>>>      >      >      >      >
>>>      >      >      >      >      It seems to me that we instead need
>>> to ignore the particular warning for
>>>      >      >      >      >      this case.
>>>      >      >      >      >
>>>      >      >      >      >      /Erik
>>>      >      >      >      >
>>>      >      >      >      >
>>>      >      >      >      >      On 2017-07-09 15:26, Hohensee, Paul
>>> wrote:
>>>      >      >      >      >      > Please review the following change
>>> to get JDK10 to build on OSX 10.12 and above.
>>>      >      >      >      >      >
>>>      >      >      >      >      >
>>> https://bugs.openjdk.java.net/browse/JDK-8184022
>>>      >      >      >      >      >
>>> http://cr.openjdk.java.net/~phh/8184022/webrev.00/
>>>      >      >      >      >      >
>>>      >      >      >      >      > I?d very much appreciate a sponsor
>>> for this fix. Imo, successful JDK10 builds on all supported platforms
>>> would be sufficient testing, but please let me know what I can do to
>>> help.
>>>      >      >      >      >      >
>>>      >      >      >      >      > Slightly revised from the RFE:
>>>      >      >      >      >      >
>>>      >      >      >      >      >
>>> JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled
>>> previously disabled clang warnings and was intended to also enable
>>> builds on OSX 10 + Xcode 8. Due to a mixup, this code in
>>> jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
>>>      >      >      >      >      >
>>>      >      >      >      >      >    #if
>>> defined(MAC_OS_X_VERSION_10_12) && \
>>>      >      >      >      >      > MAC_OS_X_VERSION_MAX_ALLOWED >=
>>> MAC_OS_X_VERSION_10_12 && \
>>>      >      >      >      >      >       __LP64__
>>>      >      >      >      >      >       / 10.12 changed `mask` to
>>> NSEventMask (unsigned long long) for x86_64 builds.
>>>      >      >      >      >      >    - (NSEvent
>>> *)nextEventMatchingMask:(NSEventMask)mask
>>>      >      >      >      >      >    #else
>>>      >      >      >      >      >    - (NSEvent
>>> *)nextEventMatchingMask:(NSUInteger)mask
>>>      >      >      >      >      >    #endif
>>>      >      >      >      >      > untilDate:(NSDate *)expiration
>>> inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
>>>      >      >      >      >      >
>>>      >      >      >      >      > works fine with OSX versions
>>> earlier than 10.12, but fails to compile starting with OSX 10.12 due
>>> to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command
>>> line as 10.7.
>>>      >      >      >      >      >
>>>      >      >      >      >      > The fix is to remove that
>>> definition, since it places an artificial upper bound on the OSX
>>> version under which JDK10 can be built. A source code search reveals
>>> no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in
>>> NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp.
>>> The latter won't be affected by this change, since it checks for a
>>> version > 10.5, which is always true in JDK10.
>>>      >      >      >      >      >
>>>      >      >      >      >      > Thanks,
>>>      >      >      >      >      >
>>>      >      >      >      >      > Paul
>>>      >      >      >      >      >
>>>      >      >      >      >
>>>      >      >      >      >
>>>      >      >      >      >
>>>      >      >      >
>>>      >      >      >
>>>      >      >      >
>>>      >      >
>>>      >      >
>>>      >      >
>>>      >
>>>      >
>>>      >
>>>
>>
>



From hohensee at amazon.com  Fri Jul 14 16:17:29 2017
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 14 Jul 2017 16:17:29 +0000
Subject: RFR(S): 8184022: Build JDK 10 on OSX 10.12 and above
In-Reply-To: <5968EBA5.2060606@oracle.com>
References: <76CC6A9B-CA42-45FE-BFAE-A4F62D1BE5BE@amazon.com>
 <13b66715-b546-d31b-5556-43f71a934249@oracle.com>
 <13FEC21B-5F41-4311-8A78-D3FDB11D96A4@amazon.com>
 <d56c7877-a4fa-e798-071f-37c626cd29e0@oracle.com>
 <8FA0C3B8-D7F9-4F0F-AE9B-99A0625E0C0A@amazon.com>
 <450f976f-2ae1-c442-409e-2d73e9a1f769@oracle.com>
 <83BBFF3A-CDC4-4E02-8563-0C3FEE5655A4@amazon.com>
 <aa248351-21aa-d21e-1c9a-c26df9dfa440@oracle.com>
 <98BCE326-858B-4B58-9138-6565728291AE@amazon.com>
 <8da9b037-24ce-0028-6716-1f0c12b37c7f@oracle.com>
 <BDC77B0E-A828-4195-BEE3-FB81612A0DF4@amazon.com>
 <8ef320d8-63e7-b481-a450-f92999a03615@oracle.com>
 <08d70b62-d8a0-e301-6fce-c65d8dbd18af@oracle.com>
 <5968EBA5.2060606@oracle.com>
Message-ID: <6D8B1007-D564-4971-9A2A-9F2EFEB5B45A@amazon.com>

No problem, and thanks for picking this up. And thanks, Erik, for the review and advice.

Paul

On 7/14/17, 9:04 AM, "Tim Bell" <tim.bell at oracle.com> wrote:

    I can pick this up and sponsor it, but as Erik wrote, I'll be pushing to 
    jdk10/jdk10.
    
    Tim
    
    On 07/14/17 07:02, Erik Joelsson wrote:
    > I realized I spoke too soon. I won't be able to sponsor this anytime
    > soon as I'm about to leave on vacation now. Hopefully someone else will
    > be able to pick this up for you.
    >
    > /Erik
    >
    >
    > On 2017-07-14 08:53, Erik Joelsson wrote:
    >> This looks good to me. Never mind the regexps, they are fine.
    >>
    >> I can sponsor the change since it touches configure and will need a
    >> corresponding closed change. Do you mind if I push this to jdk10/jdk10
    >> instead of hs? That way it will get to hs within a week, but also be
    >> in jdk10, while going the other way, it will take much longer before
    >> it hits jdk10.
    >>
    >> /Erik
    >>
    >> On 2017-07-13 19:24, Hohensee, Paul wrote:
    >>> New webrev with two-line change to flags.m4 at line 1129.
    >>>
    >>> http://cr.openjdk.java.net/~phh/8184022/webrev.03/
    >>>
    >>> ?xno? now means ?use build system default?, just as if the switch had
    >>> not been used.
    >>>
    >>> I?m a very inexperienced regex user, so I used what worked first for
    >>> me. What would it look like to escape the whole expression or
    >>> sub-expressions?
    >>>
    >>> Paul
    >>>
    >>> On 7/13/17, 10:04 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
    >>>
    >>>      This looks pretty good. A few points:
    >>>           * Please use $GREP since configure is doing some work on
    >>> finding a good
    >>>      grep for us. If you want to make the grep patterns more
    >>> readable, it's
    >>>      possible to put the [] escapes around the whole expression, or
    >>> at any
    >>>      level you wish. That way you don't need to repeat them for each
    >>> [0-9].
    >>>      Both styles are used throughout the configure script and I don't
    >>> have a
    >>>      strong preference myself.
    >>>           * The check for "no" got me thinking. If someone explicitly
    >>> sets
    >>>      --without-macosx-version-max, that probably means they want it
    >>> empty.
    >>>      The reason for doing so would be to override an earlier instance
    >>> of the
    >>>      parameter on the command line (set by some script or automatic
    >>> system
    >>>      that you can't directly influence). This is not a likely usecase
    >>> but is
    >>>      perhaps a more correct action. Sorry for confusing this earlier.
    >>> "yes"
    >>>      is definitely an error though.
    >>>           I took this patch for a run here and it seems to work as it
    >>> should from
    >>>      the Oracle point of view.
    >>>           /Erik
    >>>                On 2017-07-13 17:46, Hohensee, Paul wrote:
    >>>      > New webrev
    >>>      >
    >>>      > http://cr.openjdk.java.net/~phh/8184022/webrev.02/
    >>>      >
    >>>      > It includes ?with-macosx-version-max format checks (disallows
    >>> ?without-macosx-version-max) and your jib-profiles.js patch. I put
    >>> the checking logic in AC_ARG_WITH based on the code in basics.m4 line
    >>> 597 that defines BASIC_SETUP_DEVKIT.
    >>>      >
    >>>      > --with-macosx-version-max will fail the format checks and
    >>> ?without-macosx-version-max will fail the check against ?xno?.
    >>>      >
    >>>      > Paul
    >>>      >
    >>>      > On 7/12/17, 1:15 AM, "Erik Joelsson"
    >>> <erik.joelsson at oracle.com> wrote:
    >>>      >
    >>>      >      Hello,
    >>>      >
    >>>      >
    >>>      >      On 2017-07-12 03:19, Hohensee, Paul wrote:
    >>>      >      > New webrev at
    >>>      >      >
    >>>      >      > http://cr.openjdk.java.net/~phh/8184022/webrev.01/
    >>>      >      For the AC_ARG_WITH, we usually refrain from using the
    >>> builtin "if-set,
    >>>      >      if-not-set" parameters and define our own logic to handle
    >>> all 4
    >>>      >      possibilities: not set, --with-foobar=value,
    >>> --with-foobar and
    >>>      >      --without-foobar. The latter two results in the values
    >>> "yes" and "no"
    >>>      >      respectively and in this case those two are invalid and
    >>> needs to result
    >>>      >      in errors. Also since we are expecting a very specific
    >>> format on the
    >>>      >      input, we need to validate this format so we fail fast
    >>> instead of
    >>>      >      getting weird compile errors much later.
    >>>      >
    >>>      >      My understanding of -mmacosx-version-min is that it sets
    >>>      >      MAC_OS_X_VERSION_MIN_REQUIRED for you so no need to add
    >>> that. OTOH, it
    >>>      >      makes it more obvious where this comes from if anyone
    >>> stumbles on it in
    >>>      >      the source.
    >>>      >      > I defined a new shell variable MACOSX_VERSION_MAX which
    >>> is settable via a new configure switch
    >>> ?with-macosx-version-max=<version>. Example use:
    >>> --with-macosx-version-max=10.12.00. The specified version is passed
    >>> via a compiler command line switch, vis
    >>> ?DMAC_OS_X_VERSION_MAX_ALLOWED=101200 (de-dotted <version>).
    >>>      >      At what point did they introduce the double zeros at the
    >>> end? Seems like
    >>>      >      we will need guard the values quite carefully and make
    >>> sure we zero pad
    >>>      >      if needed.
    >>>      >      > MACOSX_VERSION_MIN remains hardcoded to 10.7.0, but is
    >>> now passed to the compilers via -DMAC_OS_X_VERSION_MIN_REQUIRED=1070
    >>> rather than via -DMAC_OS_X_VERSION_MAX_ALLOWED=1070.
    >>>      >      >
    >>>      >      > Tested by attempting builds on OSX 10.12.04.
    >>>      >      >
    >>>      >      > (1) no ?with-macosx-version-max: succeeds as expected
    >>> because no ?DMAC_OS_X_VERSION_MAX_ALLOWED passed to compilers, so
    >>> defaults to 10.12.04.
    >>>      >      > (2) ?with-macosx-version-max=10.11.00: fails as
    >>> expected due to formal parameter type mismatch.
    >>>      >      > (3) ?with-macosx-version-max=10.12.00: succeeds as
    >>> expected because formal parameter types are the same for all 10.12.xx.
    >>>      >      >
    >>>      >      > It?d be great if you could try it out.
    >>>      >      >
    >>>      >      > Note that successful cases (1) and (3) above provoke
    >>> three warnings which I haven?t investigated. Imo, I/we can figure out
    >>> how to get rid of these next/later.
    >>>      >      >
    >>>      >      > ld: warning: object file
    >>> (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base//libfdlibm.a)
    >>> was built for newer OSX version (10.12) than being linked (10.7)
    >>>      >      > ld: warning: object file
    >>> (/Users/hohensee/workspaces/jdk10-hs/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a)
    >>> was built for newer OSX version (10.12) than being linked (10.7)
    >>>      >      > clang: warning: libstdc++ is deprecated; move to libc++
    >>> with a minimum deployment target of OS X 10.9 [-Wdeprecated]
    >>>      >      I believe the warnings for static libs is simply caused
    >>> by not adding
    >>>      >      -mmacosx-version-min to the ARFLAGS. Not sure if ar on
    >>> mac takes that
    >>>      >      flag though.
    >>>      >
    >>>      >      The libstdc++ warning seems harder to work around until
    >>> we change the
    >>>      >      minimum to 10.9 instead of 10.7.
    >>>      >
    >>>      >      I would appreciate if you could also include this patch
    >>> as part of this
    >>>      >      change to make Oracle builds still behave as before:
    >>>      >
    >>>      >      diff -r a6c830ee8a67 common/conf/jib-profiles.js
    >>>      >      --- a/common/conf/jib-profiles.js
    >>>      >      +++ b/common/conf/jib-profiles.js
    >>>      >      @@ -436,7 +436,8 @@
    >>>      >                    target_os: "macosx",
    >>>      >                    target_cpu: "x64",
    >>>      >                    dependencies: ["devkit"],
    >>>      >      -            configure_args:
    >>> concat(common.configure_args_64bit,
    >>>      >      "--with-zlib=system"),
    >>>      >      +            configure_args:
    >>> concat(common.configure_args_64bit,
    >>>      >      "--with-zlib=system",
    >>>      >      + "--with-macosx-version-max=10.7.0"),
    >>>      >                },
    >>>      >
    >>>      >                "solaris-x64": {
    >>>      >
    >>>      >
    >>>      >      Thanks!
    >>>      >      /Erik
    >>>      >      > Paul
    >>>      >      >
    >>>      >      > On 7/11/17, 2:45 AM, "Erik Joelsson"
    >>> <erik.joelsson at oracle.com> wrote:
    >>>      >      >
    >>>      >      >      The -DMAC_OSX_VERSION_MAX_ALLOWED and
    >>> -mmacosx-version-min arguments are
    >>>      >      >      used in combination to achieve the same thing. I
    >>> chose to use both to
    >>>      >      >      really enforce full compatibility with the
    >>> specified version. The
    >>>      >      >      "official" way of targeting earlier versions of
    >>> the OS is just using
    >>>      >      >      -mmacosx-version-min. This will however still
    >>> accept uses of newer APIs,
    >>>      >      >      but at link time, those will be linked with
    >>> weak_import. Essentially
    >>>      >      >      it's expected that your application should be able
    >>> to do without these
    >>>      >      >      calls if necessary, at the application level.
    >>> While better than not
    >>>      >      >      being able to launch at all on the older OS, by
    >>> adding
    >>>      >      >      -DMAC_OSX_VERSION_MAX_ALLOWED, it becomes a
    >>> compile time error if any
    >>>      >      >      code tries to use a newer API.
    >>>      >      >
    >>>      >      >      As I see it, either we fully enforce this at build
    >>> time, or we don't at
    >>>      >      >      all. The natural default is to build for the
    >>> current host platform. The
    >>>      >      >      configure parameter would make it possible to
    >>> enforce a minimal
    >>>      >      >      compatible OS version that the binaries must be
    >>> usable on.
    >>>      >      >
    >>>      >      >      (Note that if you propose such a change, I will
    >>> need to add the Oracle
    >>>      >      >      bit as well, where we use the parameter, which
    >>> would need to go in at
    >>>      >      >      the same time in common/conf/jib-profiles.js. Also
    >>> note that I will be
    >>>      >      >      on vacation for 5 weeks starting this weekend so
    >>> won't be around to
    >>>      >      >      review for most of that time.)
    >>>      >      >
    >>>      >      >      /Erik
    >>>      >      >
    >>>      >      >
    >>>      >      >      On 2017-07-10 19:48, Hohensee, Paul wrote:
    >>>      >      >      > That?s a good idea, though the option would be
    >>> --with-macosx-version-max=<n>, right? The minimum is currently
    >>> hard-coded and should probably stay that way since there?s likely a
    >>> lot of code that depends on it. Let me see what I can come up with.
    >>>      >      >      >
    >>>      >      >      > Thanks,
    >>>      >      >      >
    >>>      >      >      > Paul
    >>>      >      >      >
    >>>      >      >      > On 7/10/17, 10:01 AM, "Erik Joelsson"
    >>> <erik.joelsson at oracle.com> wrote:
    >>>      >      >      >
    >>>      >      >      >
    >>>      >      >      >
    >>>      >      >      >      On 2017-07-10 18:09, Hohensee, Paul wrote:
    >>>      >      >      >      > Hi Erik,
    >>>      >      >      >      >
    >>>      >      >      >      > The problem is that the compiler doesn?t
    >>> issue a warning in this case, but rather a type-mismatch error on
    >>> NSEventMask, so I can?t turn it off. NSUInteger was being used as an
    >>> enum, so Apple changed to using a real enum in 10.12 as a matter of
    >>> code hygiene. The new code in NSApplicationAWT.m is doing the right
    >>> thing by checking MAC_OS_X_VERSION_MAX_ALLOWED.
    >>>      >      >      >      >
    >>>      >      >      >      > What particular problem were you trying
    >>> to solve? Production, QA and JPRT builds and test runs are done on
    >>> the oldest supported OSX version, so any use of newer features should
    >>> be detected very early in the test process. Restricting builds to old
    >>> OSX versions means that engineers who keep their development boxes up
    >>> to date (which they should: security, etc.) can?t use them to do JDK
    >>> development.
    >>>      >      >      >      That's not exactly true. Apple is making it
    >>> very hard to stay on older
    >>>      >      >      >      versions of the OS compared to other OS
    >>> vendors. For this reason we are
    >>>      >      >      >      not always able to stay on a particular
    >>> version for Macosx in
    >>>      >      >      >      particular. We also in general try to avoid
    >>> having to fill our build
    >>>      >      >      >      servers/environments with just the oldest
    >>> OSes, because older OSes are
    >>>      >      >      >      harder to maintain and less convenient to
    >>> work with. So instead, we try
    >>>      >      >      >      to maintain working build environments on
    >>> newer OSes that produce
    >>>      >      >      >      binaries that are compatible with the
    >>> oldest we support. So, at least
    >>>      >      >      >      from Oracle's perspective, we prefer if
    >>> builds on different OS versions
    >>>      >      >      >      produce equivalent binaries when possible.
    >>> We certainly don't want to
    >>>      >      >      >      prevent building on newer OS/compilers.
    >>>      >      >      >
    >>>      >      >      >      If this can't be worked around at the
    >>> source level, then perhaps we need
    >>>      >      >      >      to consider hiding this macro definition
    >>> behind a configure option that
    >>>      >      >      >      we can use internally. I would be open to
    >>> that. Something like
    >>>      >      >      > --with-macosx-version-min=10.7 which configure
    >>> could then translate to
    >>>      >      >      >      the combination of options currently used.
    >>> That way, most openjdk
    >>>      >      >      >      developers/builders would not need to
    >>> suffer this Oracle requirement.
    >>>      >      >      >
    >>>      >      >      >      /Erik
    >>>      >      >      >      > Thanks,
    >>>      >      >      >      >
    >>>      >      >      >      > Paul
    >>>      >      >      >      >
    >>>      >      >      >      > On 7/10/17, 1:10 AM, "Erik Joelsson"
    >>> <erik.joelsson at oracle.com> wrote:
    >>>      >      >      >      >
    >>>      >      >      >      >      Hello,
    >>>      >      >      >      >
    >>>      >      >      >      >      I do not agree to removing that
    >>> macro. I added those options to help
    >>>      >      >      >      >      guarantee that a build made on a
    >>> newer version of macosx would still run
    >>>      >      >      >      >      on the oldest version currently
    >>> supported. The macro is not mainly meant
    >>>      >      >      >      >      to be used in our code, but is
    >>> picked up by system headers to cause an
    >>>      >      >      >      >      error if any features newer than
    >>> 10.7 are used. It may be that we should
    >>>      >      >      >      >      bump it to a newer version of macosx
    >>> in JDK 10, but certainly not to 10.12.
    >>>      >      >      >      >
    >>>      >      >      >      >      It seems to me that we instead need
    >>> to ignore the particular warning for
    >>>      >      >      >      >      this case.
    >>>      >      >      >      >
    >>>      >      >      >      >      /Erik
    >>>      >      >      >      >
    >>>      >      >      >      >
    >>>      >      >      >      >      On 2017-07-09 15:26, Hohensee, Paul
    >>> wrote:
    >>>      >      >      >      >      > Please review the following change
    >>> to get JDK10 to build on OSX 10.12 and above.
    >>>      >      >      >      >      >
    >>>      >      >      >      >      >
    >>> https://bugs.openjdk.java.net/browse/JDK-8184022
    >>>      >      >      >      >      >
    >>> http://cr.openjdk.java.net/~phh/8184022/webrev.00/
    >>>      >      >      >      >      >
    >>>      >      >      >      >      > I?d very much appreciate a sponsor
    >>> for this fix. Imo, successful JDK10 builds on all supported platforms
    >>> would be sufficient testing, but please let me know what I can do to
    >>> help.
    >>>      >      >      >      >      >
    >>>      >      >      >      >      > Slightly revised from the RFE:
    >>>      >      >      >      >      >
    >>>      >      >      >      >      >
    >>> JDK-8182299<https://bugs.openjdk.java.net/browse/JDK-8182299> enabled
    >>> previously disabled clang warnings and was intended to also enable
    >>> builds on OSX 10 + Xcode 8. Due to a mixup, this code in
    >>> jdk/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
    >>>      >      >      >      >      >
    >>>      >      >      >      >      >    #if
    >>> defined(MAC_OS_X_VERSION_10_12) && \
    >>>      >      >      >      >      > MAC_OS_X_VERSION_MAX_ALLOWED >=
    >>> MAC_OS_X_VERSION_10_12 && \
    >>>      >      >      >      >      >       __LP64__
    >>>      >      >      >      >      >       / 10.12 changed `mask` to
    >>> NSEventMask (unsigned long long) for x86_64 builds.
    >>>      >      >      >      >      >    - (NSEvent
    >>> *)nextEventMatchingMask:(NSEventMask)mask
    >>>      >      >      >      >      >    #else
    >>>      >      >      >      >      >    - (NSEvent
    >>> *)nextEventMatchingMask:(NSUInteger)mask
    >>>      >      >      >      >      >    #endif
    >>>      >      >      >      >      > untilDate:(NSDate *)expiration
    >>> inMode:(NSString *)mode dequeue:(BOOL)deqFlag {
    >>>      >      >      >      >      >
    >>>      >      >      >      >      > works fine with OSX versions
    >>> earlier than 10.12, but fails to compile starting with OSX 10.12 due
    >>> to MAC_OSX_VERSION_MAX_ALLOWED being defined on the compile command
    >>> line as 10.7.
    >>>      >      >      >      >      >
    >>>      >      >      >      >      > The fix is to remove that
    >>> definition, since it places an artificial upper bound on the OSX
    >>> version under which JDK10 can be built. A source code search reveals
    >>> no uses of MAC_OSX_VERSION_MAX_ALLOWED other than in
    >>> NSApplicationAWT.m and hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp.
    >>> The latter won't be affected by this change, since it checks for a
    >>> version > 10.5, which is always true in JDK10.
    >>>      >      >      >      >      >
    >>>      >      >      >      >      > Thanks,
    >>>      >      >      >      >      >
    >>>      >      >      >      >      > Paul
    >>>      >      >      >      >      >
    >>>      >      >      >      >
    >>>      >      >      >      >
    >>>      >      >      >      >
    >>>      >      >      >
    >>>      >      >      >
    >>>      >      >      >
    >>>      >      >
    >>>      >      >
    >>>      >      >
    >>>      >
    >>>      >
    >>>      >
    >>>
    >>
    >
    
    


From Roger.Riggs at Oracle.com  Fri Jul 14 17:46:17 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 14 Jul 2017 13:46:17 -0400
Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib
In-Reply-To: <8610a85e-f12a-2a27-2be7-b25da7ac899e@oracle.com>
References: <8610a85e-f12a-2a27-2be7-b25da7ac899e@oracle.com>
Message-ID: <17fffb60-6581-64cb-273c-0273da435e1d@Oracle.com>

Hi Nishit,

I haven't seen any comments in the past month...

 From the code perspective, this looks ok.

It should have a build Reviewer too.

Thanks, Roger

On 6/13/2017 12:57 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8176583
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176583
> Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.02/
>
> Fix: Relocated currency.data from java.base module 
> (/java.base/java/util/currency.data) to /lib directory
>
> Review mail thread of JDK-8176583 at i18n-dev: 
> http://mail.openjdk.java.net/pipermail/i18n-dev/2017-June/002307.html
>
> Regards,
> Nishit Jain



From jiangli.zhou at oracle.com  Sat Jul 15 04:37:18 2017
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Fri, 14 Jul 2017 21:37:18 -0700
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS
 macro
In-Reply-To: <4d2f3964b0924ffa897074759e508653@sap.com>
References: <4d2f3964b0924ffa897074759e508653@sap.com>
Message-ID: <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>

Hi Baesken,

Thank you for making the changes.

Related to the change in universe_init() (universe.cpp), the 'if (DumpSharedSpaces)? block at line 715 is also CDS only. To be consistent, you might want to include it under #if INCLUDE_CDS as well.
--- 695,716 ----
    Universe::_loader_addClass_cache    = new LatestMethodCache();
    Universe::_pd_implies_cache         = new LatestMethodCache();
    Universe::_throw_illegal_access_error_cache = new LatestMethodCache();
    Universe::_do_stack_walk_cache = new LatestMethodCache();
  
+ #if INCLUDE_CDS
    if (UseSharedSpaces) {
      // Read the data structures supporting the shared spaces (shared
      // system dictionary, symbol table, etc.).  After that, access to
      // the file (other than the mapped regions) is no longer needed, and
      // the file is closed. Closing the file does not affect the
      // currently mapped regions.
      MetaspaceShared::initialize_shared_spaces();
      StringTable::create_table();
!   } else
! #endif
!   {
      SymbolTable::create_table();
      StringTable::create_table();
  
      if (DumpSharedSpaces) {
        MetaspaceShared::prepare_for_dumping();
In the past we have been trying to avoid adding too many #if in the code for better readability. For the CDS only code in universe.cpp (and a few other files), since the callee functions (e.g. initialize_shared_spaces()) are already defined with two versions (with and without INCLUDE_CDS). The builds without CDS also works fine even #if INCLUDE_CDS are not added.

Thanks,
Jiangli

> On Jul 13, 2017, at 5:18 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
>> Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. 
>> I can help you integrate the changes after they are reviewed.
> 
> Thanks for your feedback !
> 
> I created a bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8184323
> 
> 
> and a webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/
> 
> 
> Best regards, Matthias
> 
> 
> -----Original Message-----
> From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com] 
> Sent: Montag, 10. Juli 2017 17:54
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net
> Subject: Re: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
> 
> Hi Matthias,
> 
> Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. I can help you integrate the changes after they are reviewed.
> 
> Thanks!
> Jiangli
> 
>> On Jul 5, 2017, at 6:36 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
>> 
>> Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
>> are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
>> when  CDS is disabled at compile time  :
>> 
>> 
>> See  hotspot/make/lib/JvmFeatures.gmk  :
>> 
>> ifneq ($(call check-jvm-feature, cds), true)
>> JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0
>> 
>> 
>> 
>> However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in
>> 
>> 
>> share/vm/prims/jvmtiRedefineClasses.cpp
>> share/vm/memory/universe.cpp
>> 
>> (also some other places)
>> 
>> 
>> Should I prepare a change and add the compile-time guard at the places where missing as well ?
>> 
>> Best regards, Matthias
> 



From nishit.jain at oracle.com  Mon Jul 17 04:00:52 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 17 Jul 2017 09:30:52 +0530
Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib
In-Reply-To: <17fffb60-6581-64cb-273c-0273da435e1d@Oracle.com>
References: <8610a85e-f12a-2a27-2be7-b25da7ac899e@oracle.com>
 <17fffb60-6581-64cb-273c-0273da435e1d@Oracle.com>
Message-ID: <e7c4c5fe-5754-3c31-e301-faaa865941a5@oracle.com>

Hi Roger,

This change is put on hold. After some internal discussion, no strong 
reason came up to move it out of java.base, unless currency data 
requires frequent updates and that too should be allowed through a 
service provider mechanism. Please refer the comments section of 
JDK-8176583.

Regards,
Nishit Jain
On 14-07-2017 23:16, Roger Riggs wrote:
> Hi Nishit,
>
> I haven't seen any comments in the past month...
>
> From the code perspective, this looks ok.
>
> It should have a build Reviewer too.
>
> Thanks, Roger
>
> On 6/13/2017 12:57 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8176583
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176583
>> Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.02/
>>
>> Fix: Relocated currency.data from java.base module 
>> (/java.base/java/util/currency.data) to /lib directory
>>
>> Review mail thread of JDK-8176583 at i18n-dev: 
>> http://mail.openjdk.java.net/pipermail/i18n-dev/2017-June/002307.html
>>
>> Regards,
>> Nishit Jain
>



From christoph.langer at sap.com  Mon Jul 17 13:19:08 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 17 Jul 2017 13:19:08 +0000
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
Message-ID: <7b309c4ccbef441084cf327f37e40947@sap.com>

Hi Thomas,

the fix looks ok to me.

I?m copying build-dev because of the changes in generated-configure.sh. Don?t know if this can just be pushed from extern or if it needs some special handling from Oracle folks or other things to take care of?

Best regards
Christoph

From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
Sent: Montag, 17. Juli 2017 12:55
To: ppc-aix-port-dev at openjdk.java.net
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug

Hi all,

may I please have a review for the following fix:

webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/
Issue: https://bugs.openjdk.java.net/browse/JDK-8184344

Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet which change caused that - I suspect one of the recent template-metaprogramming changes but have not investigated yet.

Thanks, Thomas


From thomas.stuefe at gmail.com  Mon Jul 17 13:29:53 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 17 Jul 2017 15:29:53 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <7b309c4ccbef441084cf327f37e40947@sap.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
Message-ID: <CAA-vtUyKeXBvnE5cCDvOO0f0kVq0eW2PzX9rWJ_cA3gvxipaYQ@mail.gmail.com>

Thank you Christoph!

On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph <christoph.langer at sap.com
> wrote:

> Hi Thomas,
>
>
>
> the fix looks ok to me.
>
>
>
> I?m copying build-dev because of the changes in generated-configure.sh.
> Don?t know if this can just be pushed from extern or if it needs some
> special handling from Oracle folks or other things to take care of?
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net]
> *On Behalf Of *Thomas St?fe
> *Sent:* Montag, 17. Juli 2017 12:55
> *To:* ppc-aix-port-dev at openjdk.java.net
> *Subject:* RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
>
>
>
> Hi all,
>
>
>
> may I please have a review for the following fix:
>
>
>
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-
> overflow/webrev.00/webrev/
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>
>
>
> Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet
> which change caused that - I suspect one of the recent
> template-metaprogramming changes but have not investigated yet.
>
>
>
> Thanks, Thomas
>
>
>


From tim.bell at oracle.com  Mon Jul 17 14:34:03 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 17 Jul 2017 07:34:03 -0700
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CAA-vtUyKeXBvnE5cCDvOO0f0kVq0eW2PzX9rWJ_cA3gvxipaYQ@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CAA-vtUyKeXBvnE5cCDvOO0f0kVq0eW2PzX9rWJ_cA3gvxipaYQ@mail.gmail.com>
Message-ID: <596CCADB.2000705@oracle.com>

Thomas, Christoph

>> I?m copying build-dev because of the changes in generated-configure.sh.
>> Don?t know if this can just be pushed from extern or if it needs some
>> special handling from Oracle folks or other things to take care of?

Thanks for the heads up.  I asked the current gatekeeper for jdk10/hs to 
sponsor this.  You should be hearing from Dan soon.

Tim


>>
>>
>>
>> Best regards
>>
>> Christoph
>>
>>
>>
>> *From:* ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net]
>> *On Behalf Of *Thomas St?fe
>> *Sent:* Montag, 17. Juli 2017 12:55
>> *To:* ppc-aix-port-dev at openjdk.java.net
>> *Subject:* RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
>>
>>
>>
>> Hi all,
>>
>>
>>
>> may I please have a review for the following fix:
>>
>>
>>
>> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-
>> overflow/webrev.00/webrev/
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>>
>>
>>
>> Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet
>> which change caused that - I suspect one of the recent
>> template-metaprogramming changes but have not investigated yet.
>>
>>
>>
>> Thanks, Thomas
>>
>>
>>



From volker.simonis at gmail.com  Mon Jul 17 15:46:32 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 17 Jul 2017 17:46:32 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <7b309c4ccbef441084cf327f37e40947@sap.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
Message-ID: <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>

Hi Thomas,

the change looks good, but I'd prefer if you leave the initial comment
in place which also mentions "-qminimaltoc" as a way of resolving TOC
overflow errors.

I actually don't remember exactly, but I think "-qminimaltoc" works by
creating distinct TOCs for each compilation unit. That comes with an
performance impact, but  "-qpic=large" / "-bbigtoc" can have an
performance impact as well.

As I said, for the slowdebug build your changes are fine. I'd just
like to keep the reference to "-qminimaltoc" for the case where we
have to re-evaluate the different solutions for the product build.

Thank you and best regards,
Volker


On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
<christoph.langer at sap.com> wrote:
> Hi Thomas,
>
> the fix looks ok to me.
>
> I?m copying build-dev because of the changes in generated-configure.sh. Don?t know if this can just be pushed from extern or if it needs some special handling from Oracle folks or other things to take care of?
>
> Best regards
> Christoph
>
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
> Sent: Montag, 17. Juli 2017 12:55
> To: ppc-aix-port-dev at openjdk.java.net
> Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
>
> Hi all,
>
> may I please have a review for the following fix:
>
> webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>
> Basically, the TOC on AIX overflows on slowdebug builds. I am not sure yet which change caused that - I suspect one of the recent template-metaprogramming changes but have not investigated yet.
>
> Thanks, Thomas
>


From thomas.stuefe at gmail.com  Tue Jul 18 05:46:48 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 18 Jul 2017 07:46:48 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
Message-ID: <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>

Thank you Volker!

I'll restore the original comment and prepare a new webrev.

..Thomas

On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> the change looks good, but I'd prefer if you leave the initial comment
> in place which also mentions "-qminimaltoc" as a way of resolving TOC
> overflow errors.
>
> I actually don't remember exactly, but I think "-qminimaltoc" works by
> creating distinct TOCs for each compilation unit. That comes with an
> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
> performance impact as well.
>
> As I said, for the slowdebug build your changes are fine. I'd just
> like to keep the reference to "-qminimaltoc" for the case where we
> have to re-evaluate the different solutions for the product build.
>
> Thank you and best regards,
> Volker
>
>
> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
> <christoph.langer at sap.com> wrote:
> > Hi Thomas,
> >
> > the fix looks ok to me.
> >
> > I?m copying build-dev because of the changes in generated-configure.sh.
> Don?t know if this can just be pushed from extern or if it needs some
> special handling from Oracle folks or other things to take care of?
> >
> > Best regards
> > Christoph
> >
> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net]
> On Behalf Of Thomas St?fe
> > Sent: Montag, 17. Juli 2017 12:55
> > To: ppc-aix-port-dev at openjdk.java.net
> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
> >
> > Hi all,
> >
> > may I please have a review for the following fix:
> >
> > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-
> overflow/webrev.00/webrev/
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
> >
> > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure
> yet which change caused that - I suspect one of the recent
> template-metaprogramming changes but have not investigated yet.
> >
> > Thanks, Thomas
> >
>


From thomas.stuefe at gmail.com  Tue Jul 18 06:30:10 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 18 Jul 2017 08:30:10 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
Message-ID: <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>

Hi Volker,

new webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/

Only change is the comment, as you suggested.

Kind Regards, Thomas

On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Thank you Volker!
>
> I'll restore the original comment and prepare a new webrev.
>
> ..Thomas
>
> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>
>> Hi Thomas,
>>
>> the change looks good, but I'd prefer if you leave the initial comment
>> in place which also mentions "-qminimaltoc" as a way of resolving TOC
>> overflow errors.
>>
>> I actually don't remember exactly, but I think "-qminimaltoc" works by
>> creating distinct TOCs for each compilation unit. That comes with an
>> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
>> performance impact as well.
>>
>> As I said, for the slowdebug build your changes are fine. I'd just
>> like to keep the reference to "-qminimaltoc" for the case where we
>> have to re-evaluate the different solutions for the product build.
>>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
>> <christoph.langer at sap.com> wrote:
>> > Hi Thomas,
>> >
>> > the fix looks ok to me.
>> >
>> > I?m copying build-dev because of the changes in generated-configure.sh.
>> Don?t know if this can just be pushed from extern or if it needs some
>> special handling from Oracle folks or other things to take care of?
>> >
>> > Best regards
>> > Christoph
>> >
>> > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounc
>> es at openjdk.java.net] On Behalf Of Thomas St?fe
>> > Sent: Montag, 17. Juli 2017 12:55
>> > To: ppc-aix-port-dev at openjdk.java.net
>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
>> >
>> > Hi all,
>> >
>> > may I please have a review for the following fix:
>> >
>> > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overf
>> low/webrev.00/webrev/
>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>> >
>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure
>> yet which change caused that - I suspect one of the recent
>> template-metaprogramming changes but have not investigated yet.
>> >
>> > Thanks, Thomas
>> >
>>
>
>


From volker.simonis at gmail.com  Tue Jul 18 06:58:06 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 18 Jul 2017 08:58:06 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
Message-ID: <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>

Looks good!

Thanks,
Volker

On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Hi Volker,
>
> new webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/
>
> Only change is the comment, as you suggested.
>
> Kind Regards, Thomas
>
> On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>>
>> Thank you Volker!
>>
>> I'll restore the original comment and prepare a new webrev.
>>
>> ..Thomas
>>
>> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis <volker.simonis at gmail.com>
>> wrote:
>>>
>>> Hi Thomas,
>>>
>>> the change looks good, but I'd prefer if you leave the initial comment
>>> in place which also mentions "-qminimaltoc" as a way of resolving TOC
>>> overflow errors.
>>>
>>> I actually don't remember exactly, but I think "-qminimaltoc" works by
>>> creating distinct TOCs for each compilation unit. That comes with an
>>> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
>>> performance impact as well.
>>>
>>> As I said, for the slowdebug build your changes are fine. I'd just
>>> like to keep the reference to "-qminimaltoc" for the case where we
>>> have to re-evaluate the different solutions for the product build.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>>
>>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
>>> <christoph.langer at sap.com> wrote:
>>> > Hi Thomas,
>>> >
>>> > the fix looks ok to me.
>>> >
>>> > I?m copying build-dev because of the changes in generated-configure.sh.
>>> > Don?t know if this can just be pushed from extern or if it needs some
>>> > special handling from Oracle folks or other things to take care of?
>>> >
>>> > Best regards
>>> > Christoph
>>> >
>>> > From: ppc-aix-port-dev
>>> > [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
>>> > Sent: Montag, 17. Juli 2017 12:55
>>> > To: ppc-aix-port-dev at openjdk.java.net
>>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
>>> >
>>> > Hi all,
>>> >
>>> > may I please have a review for the following fix:
>>> >
>>> > webrev:
>>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/
>>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>>> >
>>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not sure
>>> > yet which change caused that - I suspect one of the recent
>>> > template-metaprogramming changes but have not investigated yet.
>>> >
>>> > Thanks, Thomas
>>> >
>>
>>
>


From thomas.stuefe at gmail.com  Tue Jul 18 07:18:39 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 18 Jul 2017 09:18:39 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
 <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
Message-ID: <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>

Danke Volker!

...

So, do I need a sponsor for this or can I push this on my own?

Thanks, Thomas

On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Looks good!
>
> Thanks,
> Volker
>
> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> > Hi Volker,
> >
> > new webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-
> overflow/webrev.01/webrev/
> >
> > Only change is the comment, as you suggested.
> >
> > Kind Regards, Thomas
> >
> > On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> > wrote:
> >>
> >> Thank you Volker!
> >>
> >> I'll restore the original comment and prepare a new webrev.
> >>
> >> ..Thomas
> >>
> >> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis <
> volker.simonis at gmail.com>
> >> wrote:
> >>>
> >>> Hi Thomas,
> >>>
> >>> the change looks good, but I'd prefer if you leave the initial comment
> >>> in place which also mentions "-qminimaltoc" as a way of resolving TOC
> >>> overflow errors.
> >>>
> >>> I actually don't remember exactly, but I think "-qminimaltoc" works by
> >>> creating distinct TOCs for each compilation unit. That comes with an
> >>> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
> >>> performance impact as well.
> >>>
> >>> As I said, for the slowdebug build your changes are fine. I'd just
> >>> like to keep the reference to "-qminimaltoc" for the case where we
> >>> have to re-evaluate the different solutions for the product build.
> >>>
> >>> Thank you and best regards,
> >>> Volker
> >>>
> >>>
> >>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
> >>> <christoph.langer at sap.com> wrote:
> >>> > Hi Thomas,
> >>> >
> >>> > the fix looks ok to me.
> >>> >
> >>> > I?m copying build-dev because of the changes in
> generated-configure.sh.
> >>> > Don?t know if this can just be pushed from extern or if it needs some
> >>> > special handling from Oracle folks or other things to take care of?
> >>> >
> >>> > Best regards
> >>> > Christoph
> >>> >
> >>> > From: ppc-aix-port-dev
> >>> > [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of
> Thomas St?fe
> >>> > Sent: Montag, 17. Juli 2017 12:55
> >>> > To: ppc-aix-port-dev at openjdk.java.net
> >>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
> >>> >
> >>> > Hi all,
> >>> >
> >>> > may I please have a review for the following fix:
> >>> >
> >>> > webrev:
> >>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-
> overflow/webrev.00/webrev/
> >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
> >>> >
> >>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not
> sure
> >>> > yet which change caused that - I suspect one of the recent
> >>> > template-metaprogramming changes but have not investigated yet.
> >>> >
> >>> > Thanks, Thomas
> >>> >
> >>
> >>
> >
>


From matthias.baesken at sap.com  Tue Jul 18 07:24:37 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 18 Jul 2017 07:24:37 +0000
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and
 INCLUDE_CDS macro
In-Reply-To: <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>
References: <4d2f3964b0924ffa897074759e508653@sap.com>
 <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>
Message-ID: <6f85d82587e349579cc7d5be62914ab5@sap.com>

Hi , thanks for the review .


>Related to the change in universe_init() (universe.cpp), the 'if (DumpSharedSpaces)? block at line 715 is also CDS only.
>To be consistent, you might want to include it under #if INCLUDE_CDS as well.

I  added the suggested  change and  created a second webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8184323.1/


Is a second review needed ?


Best regards, Matthias

From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com]
Sent: Samstag, 15. Juli 2017 06:37
To: Baesken, Matthias <matthias.baesken at sap.com>
Cc: hotspot-dev at openjdk.java.net; build-dev at openjdk.java.net
Subject: Re: RFR: compile-time guard some UseSharedSpaces-only coding with the INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro

Hi Baesken,

Thank you for making the changes.

Related to the change in universe_init() (universe.cpp), the 'if (DumpSharedSpaces)? block at line 715 is also CDS only. To be consistent, you might want to include it under #if INCLUDE_CDS as well.

--- 695,716 ----

    Universe::_loader_addClass_cache    = new LatestMethodCache();

    Universe::_pd_implies_cache         = new LatestMethodCache();

    Universe::_throw_illegal_access_error_cache = new LatestMethodCache();

    Universe::_do_stack_walk_cache = new LatestMethodCache();



+ #if INCLUDE_CDS

    if (UseSharedSpaces) {

      // Read the data structures supporting the shared spaces (shared

      // system dictionary, symbol table, etc.).  After that, access to

      // the file (other than the mapped regions) is no longer needed, and

      // the file is closed. Closing the file does not affect the

      // currently mapped regions.

      MetaspaceShared::initialize_shared_spaces();

      StringTable::create_table();

!   } else

! #endif

!   {

      SymbolTable::create_table();

      StringTable::create_table();



      if (DumpSharedSpaces) {

        MetaspaceShared::prepare_for_dumping();
In the past we have been trying to avoid adding too many #if in the code for better readability. For the CDS only code in universe.cpp (and a few other files), since the callee functions (e.g. initialize_shared_spaces()) are already defined with two versions (with and without INCLUDE_CDS). The builds without CDS also works fine even #if INCLUDE_CDS are not added.

Thanks,
Jiangli

On Jul 13, 2017, at 5:18 AM, Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:

Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code.
I can help you integrate the changes after they are reviewed.

Thanks for your feedback !

I created a bug :

https://bugs.openjdk.java.net/browse/JDK-8184323


and a webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/


Best regards, Matthias


-----Original Message-----
From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com]
Sent: Montag, 10. Juli 2017 17:54
To: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
Cc: hotspot-dev at openjdk.java.net<mailto:hotspot-dev at openjdk.java.net>; build-dev at openjdk.java.net<mailto:build-dev at openjdk.java.net>
Subject: Re: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro

Hi Matthias,

Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. I can help you integrate the changes after they are reviewed.

Thanks!
Jiangli


On Jul 5, 2017, at 6:36 AM, Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>> wrote:

Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
when  CDS is disabled at compile time  :


See  hotspot/make/lib/JvmFeatures.gmk  :

ifneq ($(call check-jvm-feature, cds), true)
JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0



However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in


share/vm/prims/jvmtiRedefineClasses.cpp
share/vm/memory/universe.cpp

(also some other places)


Should I prepare a change and add the compile-time guard at the places where missing as well ?

Best regards, Matthias



From matthias.baesken at sap.com  Tue Jul 18 08:35:20 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 18 Jul 2017 08:35:20 +0000
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and
 INCLUDE_CDS macro
In-Reply-To: <fd5db5fd-643b-f20e-c5b1-8e737d20ebdc@redhat.com>
References: <4d2f3964b0924ffa897074759e508653@sap.com>
 <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>
 <6f85d82587e349579cc7d5be62914ab5@sap.com>
 <fd5db5fd-643b-f20e-c5b1-8e737d20ebdc@redhat.com>
Message-ID: <34d6ade2d4c2428bb4aae85d9527eb65@sap.com>

Thanks !

-----Original Message-----
From: Aleksey Shipilev [mailto:shade at redhat.com] 
Sent: Dienstag, 18. Juli 2017 09:31
To: Baesken, Matthias <matthias.baesken at sap.com>; Jiangli Zhou <jiangli.zhou at oracle.com>
Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
Subject: Re: RFR: compile-time guard some UseSharedSpaces-only coding with the INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro

On 07/18/2017 09:24 AM, Baesken, Matthias wrote:
> I created a bug :
> https://bugs.openjdk.java.net/browse/JDK-8184323
> 
> 
> and a webrev :
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/

This looks good.

-Aleksey


From volker.simonis at gmail.com  Tue Jul 18 08:58:20 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 18 Jul 2017 10:58:20 +0200
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
 <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
 <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>
Message-ID: <CA+3eh10gu=71=mMz0Q5uJRqv+nMioQZ6u1EyA1r0WuWi7a1apw@mail.gmail.com>

You need a sponsor from Oracle because of the generated configure file
which also needs to be generated for the Oracle closed parts.

Can somebody from the build folks please push this?

Thanks,
Volker


On Tue, Jul 18, 2017 at 9:18 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> Danke Volker!
>
> ...
>
> So, do I need a sponsor for this or can I push this on my own?
>
> Thanks, Thomas
>
> On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis <volker.simonis at gmail.com>
> wrote:
>>
>> Looks good!
>>
>> Thanks,
>> Volker
>>
>> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> wrote:
>> > Hi Volker,
>> >
>> > new webrev:
>> >
>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/
>> >
>> > Only change is the comment, as you suggested.
>> >
>> > Kind Regards, Thomas
>> >
>> > On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>> > wrote:
>> >>
>> >> Thank you Volker!
>> >>
>> >> I'll restore the original comment and prepare a new webrev.
>> >>
>> >> ..Thomas
>> >>
>> >> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis
>> >> <volker.simonis at gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi Thomas,
>> >>>
>> >>> the change looks good, but I'd prefer if you leave the initial comment
>> >>> in place which also mentions "-qminimaltoc" as a way of resolving TOC
>> >>> overflow errors.
>> >>>
>> >>> I actually don't remember exactly, but I think "-qminimaltoc" works by
>> >>> creating distinct TOCs for each compilation unit. That comes with an
>> >>> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
>> >>> performance impact as well.
>> >>>
>> >>> As I said, for the slowdebug build your changes are fine. I'd just
>> >>> like to keep the reference to "-qminimaltoc" for the case where we
>> >>> have to re-evaluate the different solutions for the product build.
>> >>>
>> >>> Thank you and best regards,
>> >>> Volker
>> >>>
>> >>>
>> >>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
>> >>> <christoph.langer at sap.com> wrote:
>> >>> > Hi Thomas,
>> >>> >
>> >>> > the fix looks ok to me.
>> >>> >
>> >>> > I?m copying build-dev because of the changes in
>> >>> > generated-configure.sh.
>> >>> > Don?t know if this can just be pushed from extern or if it needs
>> >>> > some
>> >>> > special handling from Oracle folks or other things to take care of?
>> >>> >
>> >>> > Best regards
>> >>> > Christoph
>> >>> >
>> >>> > From: ppc-aix-port-dev
>> >>> > [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of
>> >>> > Thomas St?fe
>> >>> > Sent: Montag, 17. Juli 2017 12:55
>> >>> > To: ppc-aix-port-dev at openjdk.java.net
>> >>> > Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for
>> >>> > slowdebug
>> >>> >
>> >>> > Hi all,
>> >>> >
>> >>> > may I please have a review for the following fix:
>> >>> >
>> >>> > webrev:
>> >>> >
>> >>> > http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/
>> >>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>> >>> >
>> >>> > Basically, the TOC on AIX overflows on slowdebug builds. I am not
>> >>> > sure
>> >>> > yet which change caused that - I suspect one of the recent
>> >>> > template-metaprogramming changes but have not investigated yet.
>> >>> >
>> >>> > Thanks, Thomas
>> >>> >
>> >>
>> >>
>> >
>
>


From matthias.baesken at sap.com  Tue Jul 18 10:36:20 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 18 Jul 2017 10:36:20 +0000
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <738dc2d22854475f9a15e163f7038872@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
 <948004c4-63e7-b0e4-1820-bf2351fc2327@oracle.com>
 <738dc2d22854475f9a15e163f7038872@sap.com>
Message-ID: <2232715d41bd453abdc339a988bdce3c@sap.com>

Ping :  could someone from oracle please push it ?
(reason is that it touches the generated-configure.sh   files )

Thanks, Matthias


-----Original Message-----
From: Baesken, Matthias 
Sent: Freitag, 14. Juli 2017 17:05
To: 'Erik Joelsson' <erik.joelsson at oracle.com>; Simon Nash <simon at cjnash.com>
Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

Thanks , can you push it ( as far as I know someone from Oracle needs to push it because generated-configure.sh  is changed ) ?

Best regards, Matthias



-----Original Message-----
From: Erik Joelsson [mailto:erik.joelsson at oracle.com] 
Sent: Freitag, 14. Juli 2017 14:43
To: Baesken, Matthias <matthias.baesken at sap.com>; Simon Nash <simon at cjnash.com>
Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

This looks good to me.

/Erik


On 2017-07-14 13:47, Baesken, Matthias wrote:
> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
> And created a new webrev  :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
>
> - check adjusted to minimum gcc 4.7
> - common/doc/building.md    adjusted  (the part talking about gcc versions)
>
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Freitag, 14. Juli 2017 08:36
> To: 'Simon Nash' <simon at cjnash.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
> Hi Simon,
>     reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
>
> My first  suggestion was  :
>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>   So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Simon Nash [mailto:simon at cjnash.com]
> Sent: Donnerstag, 13. Juli 2017 21:56
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> I am currently building JDK 9 for arm32 (hard float and soft float) using
> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
> this cannot be supported for JDK 10?
>
> Best regards,
> Simon
>
> On 13/07/2017 14:40, Baesken, Matthias wrote:
>> Hi Erik, I prepared the change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>
>> bug :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>
>> Asking for review(s) ...
>>
>>
>> Best regards, Matthias
>>
>>
>>
>>
>> -----Original Message-----
>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>> Sent: Donnerstag, 13. Juli 2017 13:34
>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> Hello,
>>
>> That would be the correct place. If you prepare the change and send the
>> review I can sponsor the push.
>>
>> /Erik
>>
>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>> Hi Erik,
>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>     for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>    ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>> configure works nicely and then the build fails in the middle of the HS make )
>>>
>>> autoconf/toolchain.m4
>>>
>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>
>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello Matthias,
>>>
>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>> guys at SAP, so if you would suggest dropping support, that would of
>>> course be the simplest solution.
>>>
>>> If you want to keep support but make the use of this flag optional, the
>>> preferred method is to add a test in flags.m4. We have macros defined
>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>> it to check if the flag is valid for the current compiler. If so, you
>>> can define a variable
>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>> and empty otherwise, and in the makefile use this variable in the
>>> assignement.
>>>
>>> We want to avoid static shell expressions in the makefiles if possible
>>> and keep that kind of logic in configure. It's also better to explicitly
>>> check for features rather than versions.
>>>
>>> /Erik
>>>
>>>
>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>
>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>
>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>
>>>>
>>>> 1) disallow usage of old gcc versions here :
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>
>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>
>>>>
>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>
>>>> What is your preferred solution ?
>>>>
>>>>
>>>> Thanks, Matthias
>>>>
>>>>


From volker.simonis at gmail.com  Tue Jul 18 14:12:17 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 18 Jul 2017 16:12:17 +0200
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and
 INCLUDE_CDS macro
In-Reply-To: <34d6ade2d4c2428bb4aae85d9527eb65@sap.com>
References: <4d2f3964b0924ffa897074759e508653@sap.com>
 <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>
 <6f85d82587e349579cc7d5be62914ab5@sap.com>
 <fd5db5fd-643b-f20e-c5b1-8e737d20ebdc@redhat.com>
 <34d6ade2d4c2428bb4aae85d9527eb65@sap.com>
Message-ID: <CA+3eh12ZgSzK0upu5oaySw1+EwTRtswpPSxCf4Vw7=hudXK8gg@mail.gmail.com>

Hi Matthias,

thanks for doing this change. It looks good!

Can somebody from Oracle (maybe you Jiangli) please sponsor it?
Unfortunately I still can't push it because it is in shared code :(

Thank you and best regards,
Volker


On Tue, Jul 18, 2017 at 10:35 AM, Baesken, Matthias
<matthias.baesken at sap.com> wrote:
> Thanks !
>
> -----Original Message-----
> From: Aleksey Shipilev [mailto:shade at redhat.com]
> Sent: Dienstag, 18. Juli 2017 09:31
> To: Baesken, Matthias <matthias.baesken at sap.com>; Jiangli Zhou <jiangli.zhou at oracle.com>
> Cc: build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net
> Subject: Re: RFR: compile-time guard some UseSharedSpaces-only coding with the INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
>
> On 07/18/2017 09:24 AM, Baesken, Matthias wrote:
>> I created a bug :
>> https://bugs.openjdk.java.net/browse/JDK-8184323
>>
>>
>> and a webrev :
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/
>
> This looks good.
>
> -Aleksey
>


From jiangli.zhou at oracle.com  Tue Jul 18 21:53:19 2017
From: jiangli.zhou at oracle.com (Jiangli Zhou)
Date: Tue, 18 Jul 2017 14:53:19 -0700
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS
 macro
In-Reply-To: <6f85d82587e349579cc7d5be62914ab5@sap.com>
References: <4d2f3964b0924ffa897074759e508653@sap.com>
 <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>
 <6f85d82587e349579cc7d5be62914ab5@sap.com>
Message-ID: <66AA4D76-7526-4C11-BCDC-66EC368900F9@oracle.com>

Hi Matthias,

> On Jul 18, 2017, at 12:24 AM, Baesken, Matthias <matthias.baesken at sap.com> wrote:
> 
> Hi , thanks for the review .
>  
>  
> >Related to the change in universe_init() (universe.cpp), the 'if (DumpSharedSpaces)? block at line 715 is also CDS only.
> >To be consistent, you might want to include it under #if INCLUDE_CDS as well.
>  
> I  added the suggested  change and  created a second webrev :
>  
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184323.1/ <http://cr.openjdk.java.net/~mbaesken/webrevs/8184323.1/>
Looks good. I see Coleen already said she will push the change for you.

Thanks,
Jiangli

>  
>  
> Is a second review needed ?
>  
>  
> Best regards, Matthias
>  
> From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com <mailto:jiangli.zhou at oracle.com>] 
> Sent: Samstag, 15. Juli 2017 06:37
> To: Baesken, Matthias <matthias.baesken at sap.com <mailto:matthias.baesken at sap.com>>
> Cc: hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>; build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>
> Subject: Re: RFR: compile-time guard some UseSharedSpaces-only coding with the INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
>  
> Hi Baesken,
>  
> Thank you for making the changes.
>  
> Related to the change in universe_init() (universe.cpp), the 'if (DumpSharedSpaces)? block at line 715 is also CDS only. To be consistent, you might want to include it under #if INCLUDE_CDS as well.
> --- 695,716 ----
>     Universe::_loader_addClass_cache    = new LatestMethodCache();
>     Universe::_pd_implies_cache         = new LatestMethodCache();
>     Universe::_throw_illegal_access_error_cache = new LatestMethodCache();
>     Universe::_do_stack_walk_cache = new LatestMethodCache();
>   
> + #if INCLUDE_CDS
>     if (UseSharedSpaces) {
>       // Read the data structures supporting the shared spaces (shared
>       // system dictionary, symbol table, etc.).  After that, access to
>       // the file (other than the mapped regions) is no longer needed, and
>       // the file is closed. Closing the file does not affect the
>       // currently mapped regions.
>       MetaspaceShared::initialize_shared_spaces();
>       StringTable::create_table();
> !   } else
> ! #endif
> !   {
>       SymbolTable::create_table();
>       StringTable::create_table();
>   
>       if (DumpSharedSpaces) {
>         MetaspaceShared::prepare_for_dumping();
> In the past we have been trying to avoid adding too many #if in the code for better readability. For the CDS only code in universe.cpp (and a few other files), since the callee functions (e.g. initialize_shared_spaces()) are already defined with two versions (with and without INCLUDE_CDS). The builds without CDS also works fine even #if INCLUDE_CDS are not added.
>  
> Thanks,
> Jiangli
>  
> On Jul 13, 2017, at 5:18 AM, Baesken, Matthias <matthias.baesken at sap.com <mailto:matthias.baesken at sap.com>> wrote:
>  
> Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. 
> I can help you integrate the changes after they are reviewed.
> 
> Thanks for your feedback !
> 
> I created a bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8184323 <https://bugs.openjdk.java.net/browse/JDK-8184323>
> 
> 
> and a webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/ <http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/>
> 
> 
> Best regards, Matthias
> 
> 
> -----Original Message-----
> From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com <mailto:jiangli.zhou at oracle.com>] 
> Sent: Montag, 10. Juli 2017 17:54
> To: Baesken, Matthias <matthias.baesken at sap.com <mailto:matthias.baesken at sap.com>>
> Cc: hotspot-dev at openjdk.java.net <mailto:hotspot-dev at openjdk.java.net>; build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>
> Subject: Re: jdk10 : UseSharedSpaces flag and INCLUDE_CDS macro
> 
> Hi Matthias,
> 
> Thank you for noticing that. Yes, it would be helpful if you can add the #if INCLUDE_CDS for CDS only code. I can help you integrate the changes after they are reviewed.
> 
> Thanks!
> Jiangli
> 
> 
> On Jul 5, 2017, at 6:36 AM, Baesken, Matthias <matthias.baesken at sap.com <mailto:matthias.baesken at sap.com>> wrote:
> 
> Hello, when looking into CDS related build options,  I noticed  that most  code-parts  that are executed only when UseSharedSpaces is set,
> are guarded by  the compile-time macro    INCLUDE_CDS   to support  switching off   compilation of this coding
> when  CDS is disabled at compile time  :
> 
> 
> See  hotspot/make/lib/JvmFeatures.gmk  :
> 
> ifneq ($(call check-jvm-feature, cds), true)
> JVM_CFLAGS_FEATURES += -DINCLUDE_CDS=0
> 
> 
> 
> However some places miss the compile-time guarding ( #if INCLUDE_CDS  ....) for example in
> 
> 
> share/vm/prims/jvmtiRedefineClasses.cpp
> share/vm/memory/universe.cpp
> 
> (also some other places)
> 
> 
> Should I prepare a change and add the compile-time guard at the places where missing as well ?
> 
> Best regards, Matthias



From shade at redhat.com  Tue Jul 18 07:30:53 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 18 Jul 2017 09:30:53 +0200
Subject: RFR: compile-time guard some UseSharedSpaces-only coding with the
 INCLUDE_CDS macro - was :RE: jdk10 : UseSharedSpaces flag and
 INCLUDE_CDS macro
In-Reply-To: <6f85d82587e349579cc7d5be62914ab5@sap.com>
References: <4d2f3964b0924ffa897074759e508653@sap.com>
 <BFEE01D8-8EE5-4861-ADFB-3475E8EE75B0@oracle.com>
 <6f85d82587e349579cc7d5be62914ab5@sap.com>
Message-ID: <fd5db5fd-643b-f20e-c5b1-8e737d20ebdc@redhat.com>

On 07/18/2017 09:24 AM, Baesken, Matthias wrote:
> I created a bug :
> https://bugs.openjdk.java.net/browse/JDK-8184323
> 
> 
> and a webrev :
> http://cr.openjdk.java.net/~mbaesken/webrevs/8184323/

This looks good.

-Aleksey



From tim.bell at oracle.com  Wed Jul 19 01:29:26 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 18 Jul 2017 18:29:26 -0700
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8
 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag
 in hotspot build
In-Reply-To: <2232715d41bd453abdc339a988bdce3c@sap.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
 <948004c4-63e7-b0e4-1820-bf2351fc2327@oracle.com>
 <738dc2d22854475f9a15e163f7038872@sap.com>
 <2232715d41bd453abdc339a988bdce3c@sap.com>
Message-ID: <596EB5F6.1000802@oracle.com>

Hello -

This fix has been pushed to OpenJDK jdk10/jdk10:

    http://hg.openjdk.java.net/jdk10/jdk10/rev/49a15c503104

Tim

On 07/18/17 03:36, Baesken, Matthias wrote:
> Ping :  could someone from oracle please push it ?
> (reason is that it touches the generated-configure.sh   files )
>
> Thanks, Matthias
>
>
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Freitag, 14. Juli 2017 17:05
> To: 'Erik Joelsson' <erik.joelsson at oracle.com>; Simon Nash <simon at cjnash.com>
> Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> Thanks , can you push it ( as far as I know someone from Oracle needs to push it because generated-configure.sh  is changed ) ?
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Freitag, 14. Juli 2017 14:43
> To: Baesken, Matthias <matthias.baesken at sap.com>; Simon Nash <simon at cjnash.com>
> Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> This looks good to me.
>
> /Erik
>
>
> On 2017-07-14 13:47, Baesken, Matthias wrote:
>> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
>> And created a new webrev  :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
>>
>> - check adjusted to minimum gcc 4.7
>> - common/doc/building.md    adjusted  (the part talking about gcc versions)
>>
>>
>> Best regards, Matthias
>>
>>
>>
>> -----Original Message-----
>> From: Baesken, Matthias
>> Sent: Freitag, 14. Juli 2017 08:36
>> To: 'Simon Nash' <simon at cjnash.com>
>> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
>> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>>> this cannot be supported for JDK 10?
>> Hi Simon,
>>      reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
>> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
>> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
>>
>> My first  suggestion was  :
>>
>>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>    So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
>> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
>>
>> Best regards, Matthias
>>
>>
>>
>> -----Original Message-----
>> From: Simon Nash [mailto:simon at cjnash.com]
>> Sent: Donnerstag, 13. Juli 2017 21:56
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
>> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
>>
>> Best regards,
>> Simon
>>
>> On 13/07/2017 14:40, Baesken, Matthias wrote:
>>> Hi Erik, I prepared the change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>>
>>> bug :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>>
>>> Asking for review(s) ...
>>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 13:34
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello,
>>>
>>> That would be the correct place. If you prepare the change and send the
>>> review I can sponsor the push.
>>>
>>> /Erik
>>>
>>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>>> Hi Erik,
>>>>
>>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>>> course be the simplest solution.
>>>>      for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>>     ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>>> configure works nicely and then the build fails in the middle of the HS make )
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>>
>>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>>
>>>> Hello Matthias,
>>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>>
>>>> If you want to keep support but make the use of this flag optional, the
>>>> preferred method is to add a test in flags.m4. We have macros defined
>>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>>> it to check if the flag is valid for the current compiler. If so, you
>>>> can define a variable
>>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>>> and empty otherwise, and in the makefile use this variable in the
>>>> assignement.
>>>>
>>>> We want to avoid static shell expressions in the makefiles if possible
>>>> and keep that kind of logic in configure. It's also better to explicitly
>>>> check for features rather than versions.
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>>
>>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>>
>>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>>
>>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>>
>>>>>
>>>>> 1) disallow usage of old gcc versions here :
>>>>>
>>>>> autoconf/toolchain.m4
>>>>>
>>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>>
>>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>>
>>>>>
>>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>>
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>>
>>>>> What is your preferred solution ?
>>>>>
>>>>>
>>>>> Thanks, Matthias
>>>>>
>>>>>
>



From tim.bell at oracle.com  Wed Jul 19 01:30:14 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 18 Jul 2017 18:30:14 -0700
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <CA+3eh10gu=71=mMz0Q5uJRqv+nMioQZ6u1EyA1r0WuWi7a1apw@mail.gmail.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
 <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
 <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>
 <CA+3eh10gu=71=mMz0Q5uJRqv+nMioQZ6u1EyA1r0WuWi7a1apw@mail.gmail.com>
Message-ID: <596EB626.9060504@oracle.com>

Hello -

This fix has been pushed to OpenJDK jdk10/jdk10:

   http://hg.openjdk.java.net/jdk10/jdk10/rev/2fe66ca1e2b3

Tim

On 07/18/17 01:58, Volker Simonis wrote:
> You need a sponsor from Oracle because of the generated configure file
> which also needs to be generated for the Oracle closed parts.
>
> Can somebody from the build folks please push this?
>
> Thanks,
> Volker
>
>
> On Tue, Jul 18, 2017 at 9:18 AM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>> Danke Volker!
>>
>> ...
>>
>> So, do I need a sponsor for this or can I push this on my own?
>>
>> Thanks, Thomas
>>
>> On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis <volker.simonis at gmail.com>
>> wrote:
>>>
>>> Looks good!
>>>
>>> Thanks,
>>> Volker
>>>
>>> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>>> wrote:
>>>> Hi Volker,
>>>>
>>>> new webrev:
>>>>
>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/
>>>>
>>>> Only change is the comment, as you suggested.
>>>>
>>>> Kind Regards, Thomas
>>>>
>>>> On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe <thomas.stuefe at gmail.com>
>>>> wrote:
>>>>>
>>>>> Thank you Volker!
>>>>>
>>>>> I'll restore the original comment and prepare a new webrev.
>>>>>
>>>>> ..Thomas
>>>>>
>>>>> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis
>>>>> <volker.simonis at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi Thomas,
>>>>>>
>>>>>> the change looks good, but I'd prefer if you leave the initial comment
>>>>>> in place which also mentions "-qminimaltoc" as a way of resolving TOC
>>>>>> overflow errors.
>>>>>>
>>>>>> I actually don't remember exactly, but I think "-qminimaltoc" works by
>>>>>> creating distinct TOCs for each compilation unit. That comes with an
>>>>>> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
>>>>>> performance impact as well.
>>>>>>
>>>>>> As I said, for the slowdebug build your changes are fine. I'd just
>>>>>> like to keep the reference to "-qminimaltoc" for the case where we
>>>>>> have to re-evaluate the different solutions for the product build.
>>>>>>
>>>>>> Thank you and best regards,
>>>>>> Volker
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
>>>>>> <christoph.langer at sap.com> wrote:
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>> the fix looks ok to me.
>>>>>>>
>>>>>>> I?m copying build-dev because of the changes in
>>>>>>> generated-configure.sh.
>>>>>>> Don?t know if this can just be pushed from extern or if it needs
>>>>>>> some
>>>>>>> special handling from Oracle folks or other things to take care of?
>>>>>>>
>>>>>>> Best regards
>>>>>>> Christoph
>>>>>>>
>>>>>>> From: ppc-aix-port-dev
>>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of
>>>>>>> Thomas St?fe
>>>>>>> Sent: Montag, 17. Juli 2017 12:55
>>>>>>> To: ppc-aix-port-dev at openjdk.java.net
>>>>>>> Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for
>>>>>>> slowdebug
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> may I please have a review for the following fix:
>>>>>>>
>>>>>>> webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/
>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
>>>>>>>
>>>>>>> Basically, the TOC on AIX overflows on slowdebug builds. I am not
>>>>>>> sure
>>>>>>> yet which change caused that - I suspect one of the recent
>>>>>>> template-metaprogramming changes but have not investigated yet.
>>>>>>>
>>>>>>> Thanks, Thomas
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>



From matthias.baesken at sap.com  Wed Jul 19 05:29:21 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 19 Jul 2017 05:29:21 +0000
Subject: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 -
 was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++
 flag in hotspot build
In-Reply-To: <596EB5F6.1000802@oracle.com>
References: <6c85b34b225e417788f794a99269e9fb@sap.com>
 <5967D063.1010808@cjnash.com> <424e7257bc504fe09d967ce56d64afd1@sap.com>
 <2ac4b05d05434369bdeb72f7018d00f8@sap.com>
 <948004c4-63e7-b0e4-1820-bf2351fc2327@oracle.com>
 <738dc2d22854475f9a15e163f7038872@sap.com>
 <2232715d41bd453abdc339a988bdce3c@sap.com> <596EB5F6.1000802@oracle.com>
Message-ID: <27b86a87108d441dad8b7b0d56dba76e@sap.com>

Hi Tim , Thanks !

-----Original Message-----
From: Tim Bell [mailto:tim.bell at oracle.com] 
Sent: Mittwoch, 19. Juli 2017 03:29
To: Baesken, Matthias <matthias.baesken at sap.com>; Erik Joelsson <erik.joelsson at oracle.com>; Simon Nash <simon at cjnash.com>; Simonis, Volker <volker.simonis at sap.com>
Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build

Hello -

This fix has been pushed to OpenJDK jdk10/jdk10:

    http://hg.openjdk.java.net/jdk10/jdk10/rev/49a15c503104

Tim

On 07/18/17 03:36, Baesken, Matthias wrote:
> Ping :  could someone from oracle please push it ?
> (reason is that it touches the generated-configure.sh   files )
>
> Thanks, Matthias
>
>
> -----Original Message-----
> From: Baesken, Matthias
> Sent: Freitag, 14. Juli 2017 17:05
> To: 'Erik Joelsson' <erik.joelsson at oracle.com>; Simon Nash <simon at cjnash.com>
> Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> Thanks , can you push it ( as far as I know someone from Oracle needs to push it because generated-configure.sh  is changed ) ?
>
> Best regards, Matthias
>
>
>
> -----Original Message-----
> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
> Sent: Freitag, 14. Juli 2017 14:43
> To: Baesken, Matthias <matthias.baesken at sap.com>; Simon Nash <simon at cjnash.com>
> Cc: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>
> This looks good to me.
>
> /Erik
>
>
> On 2017-07-14 13:47, Baesken, Matthias wrote:
>> After Simons question , I checked   that  the jdk10 builds  still works  with gcc 4.7 on linux x86_64 as well .
>> And created a new webrev  :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338.1/
>>
>> - check adjusted to minimum gcc 4.7
>> - common/doc/building.md    adjusted  (the part talking about gcc versions)
>>
>>
>> Best regards, Matthias
>>
>>
>>
>> -----Original Message-----
>> From: Baesken, Matthias
>> Sent: Freitag, 14. Juli 2017 08:36
>> To: 'Simon Nash' <simon at cjnash.com>
>> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
>> Subject: RE: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>>> this cannot be supported for JDK 10?
>> Hi Simon,
>>      reason was that  we know gcc-4.8 works nicely because we do a lot of builds (+tests) with this compiler .
>> For gcc 4.7 we just do not know  ( but for old 4.3 / 4.4  it was obvious that the current flags do not work any more).
>> If you are using a gcc  compiler < 4.8 only a warning is reported , it does not mean that you cannot build  any more.
>>
>> My first  suggestion was  :
>>
>>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>    So if you see a benefit to  test for minimum gcc 4.7 and not 4.8  I am fine with this too (Erik what do you think?).
>> We at SAP just cannot tell  that gcc 4.7 still works (because our builds do not use it).
>>
>> Best regards, Matthias
>>
>>
>>
>> -----Original Message-----
>> From: Simon Nash [mailto:simon at cjnash.com]
>> Sent: Donnerstag, 13. Juli 2017 21:56
>> To: Baesken, Matthias <matthias.baesken at sap.com>
>> Cc: Erik Joelsson <erik.joelsson at oracle.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com>
>> Subject: Re: RFR: [XS] 8184338 : switch minimum supported gcc version to 4.8 - was : RE: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>
>> I am currently building JDK 9 for arm32 (hard float and soft float) using
>> a Linaro GCC 4.7 cross-compiler (binary download).  What is the reason that
>> this cannot be supported for JDK 10?
>>
>> Best regards,
>> Simon
>>
>> On 13/07/2017 14:40, Baesken, Matthias wrote:
>>> Hi Erik, I prepared the change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8184338/
>>>
>>> bug :
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8184338
>>>
>>> Asking for review(s) ...
>>>
>>>
>>> Best regards, Matthias
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>> Sent: Donnerstag, 13. Juli 2017 13:34
>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>
>>> Hello,
>>>
>>> That would be the correct place. If you prepare the change and send the
>>> review I can sponsor the push.
>>>
>>> /Erik
>>>
>>> On 2017-07-13 13:16, Baesken, Matthias wrote:
>>>> Hi Erik,
>>>>
>>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>>> course be the simplest solution.
>>>>      for jdk10  it is fine for us to  use  minimum gcc 4.8  . That would be probably the most simple solution to avoid running into the  "-fno-var-tracking-assignments"  issue
>>>>     ( I now and then run into it when I forget to set the PATH to gcc-4.8 one should use for compiling on the SLES11 machine, so I pick up instead the default gcc 4.3.4 from the machine  ,
>>>> configure works nicely and then the build fails in the middle of the HS make )
>>>>
>>>> autoconf/toolchain.m4
>>>>
>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.8"
>>>>
>>>> Is there right place to  adjust I think, I guess we need someone for Oracle to regenerate the generated-configure.sh files ?
>>>>
>>>> Best regards, Matthias
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com]
>>>> Sent: Donnerstag, 13. Juli 2017 11:59
>>>> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>; 'hotspot-dev at openjdk.java.net' <hotspot-dev at openjdk.java.net>
>>>> Subject: Re: jdk10 build : usage of -fno-var-tracking-assignments g++ flag in hotspot build
>>>>
>>>> Hello Matthias,
>>>>
>>>> AFAIK, the only reason we support GCC versions older than 4.9 is for you
>>>> guys at SAP, so if you would suggest dropping support, that would of
>>>> course be the simplest solution.
>>>>
>>>> If you want to keep support but make the use of this flag optional, the
>>>> preferred method is to add a test in flags.m4. We have macros defined
>>>> for this. FLAGS_COMPILER_CHECK_ARGUMENTS or
>>>> FLAGS_CXX_COMPILER_CHECK_ARGUMENTS would be suitable in this case. Use
>>>> it to check if the flag is valid for the current compiler. If so, you
>>>> can define a variable
>>>> "CXXFLAGS_GCC_NO_VAR_TRACKING_ASSIGNMENTS=-fno-var-tracking-assignment"
>>>> and empty otherwise, and in the makefile use this variable in the
>>>> assignement.
>>>>
>>>> We want to avoid static shell expressions in the makefiles if possible
>>>> and keep that kind of logic in configure. It's also better to explicitly
>>>> check for features rather than versions.
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-07-13 11:21, Baesken, Matthias wrote:
>>>>> Hello,  when building jdk10 on Suse Linux 11 with default gcc/g++  4.3.4 installed, I was running into
>>>>> compilation errors because of the  missing support for  g++ flag -fno-var-tracking-assignments .
>>>>>
>>>>> It seems gcc-4.6  has the -fvar-tracking-assignments / -fnovar-tracking-assignments  flags , see
>>>>>
>>>>> https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Option-Summary.html#Option-Summary
>>>>>
>>>>> I have no gcc-4.6 at hand but could verify that gcc-4.7 and gcc-4.8 "know" the flag.
>>>>> There are various solutions one could do  to avoid  the  compilation error .
>>>>>
>>>>>
>>>>> 1) disallow usage of old gcc versions here :
>>>>>
>>>>> autoconf/toolchain.m4
>>>>>
>>>>> TOOLCHAIN_MINIMUM_VERSION_gcc="4.3"
>>>>>
>>>>> ( e.g. change to minimum gcc   4.6 or gcc  4.7  supporting the flags used in the build )
>>>>>
>>>>>
>>>>> 2) remove the flag  -fno-var-tracking-assignments for older gcc versions here :
>>>>> (in a similar way it was done :  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/37e693211deb  )
>>>>>
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk-32-ifeq ($(TOOLCHAIN_TYPE), gcc)
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk:33:  BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk:34:  BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments
>>>>> hotspot/make/lib/JvmOverrideFiles.gmk-35-endif
>>>>>
>>>>> What is your preferred solution ?
>>>>>
>>>>>
>>>>> Thanks, Matthias
>>>>>
>>>>>
>


From volker.simonis at gmail.com  Wed Jul 19 06:09:10 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Jul 2017 06:09:10 +0000
Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for slowdebug
In-Reply-To: <596EB626.9060504@oracle.com>
References: <CAA-vtUyU3FzmkL3zJsCdR+1nzWOv+UvLzXft617=t3ibMy-cKQ@mail.gmail.com>
 <7b309c4ccbef441084cf327f37e40947@sap.com>
 <CA+3eh11S4p-c53Fy6c7giUMFL3x-7oCqkpyKkBJvSnPTsHCvUA@mail.gmail.com>
 <CAA-vtUyxz=XcyduRwr9SYHBkVbZ6XrD8JCZa1YASfD=mjM_zAg@mail.gmail.com>
 <CAA-vtUzDk7sFuMYcG4eJRXQZ127Z3hx_k=GN=mUA1HN8wowRmQ@mail.gmail.com>
 <CA+3eh13R3naYhVg+ctbYQS=QF9ROEdcpMkg-a0Y8E_hOrWf_gw@mail.gmail.com>
 <CAA-vtUzpwqQyS-T9nTG17NpDjLjTWT-81xgGZHva_V0isVxW8Q@mail.gmail.com>
 <CA+3eh10gu=71=mMz0Q5uJRqv+nMioQZ6u1EyA1r0WuWi7a1apw@mail.gmail.com>
 <596EB626.9060504@oracle.com>
Message-ID: <CA+3eh12k=pon9wfNt73eFobOngnrUe4dhZuLQVhw3WcQfEo_RQ@mail.gmail.com>

Thanks, Tim!

Regards,
Volker

Tim Bell <tim.bell at oracle.com> schrieb am Mi. 19. Juli 2017 um 03:30:

> Hello -
>
> This fix has been pushed to OpenJDK jdk10/jdk10:
>
>    http://hg.openjdk.java.net/jdk10/jdk10/rev/2fe66ca1e2b3
>
> Tim
>
> On 07/18/17 01:58, Volker Simonis wrote:
> > You need a sponsor from Oracle because of the generated configure file
> > which also needs to be generated for the Oracle closed parts.
> >
> > Can somebody from the build folks please push this?
> >
> > Thanks,
> > Volker
> >
> >
> > On Tue, Jul 18, 2017 at 9:18 AM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >> Danke Volker!
> >>
> >> ...
> >>
> >> So, do I need a sponsor for this or can I push this on my own?
> >>
> >> Thanks, Thomas
> >>
> >> On Tue, Jul 18, 2017 at 8:58 AM, Volker Simonis <
> volker.simonis at gmail.com>
> >> wrote:
> >>>
> >>> Looks good!
> >>>
> >>> Thanks,
> >>> Volker
> >>>
> >>> On Tue, Jul 18, 2017 at 8:30 AM, Thomas St?fe <thomas.stuefe at gmail.com
> >
> >>> wrote:
> >>>> Hi Volker,
> >>>>
> >>>> new webrev:
> >>>>
> >>>>
> http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.01/webrev/
> >>>>
> >>>> Only change is the comment, as you suggested.
> >>>>
> >>>> Kind Regards, Thomas
> >>>>
> >>>> On Tue, Jul 18, 2017 at 7:46 AM, Thomas St?fe <
> thomas.stuefe at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Thank you Volker!
> >>>>>
> >>>>> I'll restore the original comment and prepare a new webrev.
> >>>>>
> >>>>> ..Thomas
> >>>>>
> >>>>> On Mon, Jul 17, 2017 at 5:46 PM, Volker Simonis
> >>>>> <volker.simonis at gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi Thomas,
> >>>>>>
> >>>>>> the change looks good, but I'd prefer if you leave the initial
> comment
> >>>>>> in place which also mentions "-qminimaltoc" as a way of resolving
> TOC
> >>>>>> overflow errors.
> >>>>>>
> >>>>>> I actually don't remember exactly, but I think "-qminimaltoc" works
> by
> >>>>>> creating distinct TOCs for each compilation unit. That comes with an
> >>>>>> performance impact, but  "-qpic=large" / "-bbigtoc" can have an
> >>>>>> performance impact as well.
> >>>>>>
> >>>>>> As I said, for the slowdebug build your changes are fine. I'd just
> >>>>>> like to keep the reference to "-qminimaltoc" for the case where we
> >>>>>> have to re-evaluate the different solutions for the product build.
> >>>>>>
> >>>>>> Thank you and best regards,
> >>>>>> Volker
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Jul 17, 2017 at 3:19 PM, Langer, Christoph
> >>>>>> <christoph.langer at sap.com> wrote:
> >>>>>>> Hi Thomas,
> >>>>>>>
> >>>>>>> the fix looks ok to me.
> >>>>>>>
> >>>>>>> I?m copying build-dev because of the changes in
> >>>>>>> generated-configure.sh.
> >>>>>>> Don?t know if this can just be pushed from extern or if it needs
> >>>>>>> some
> >>>>>>> special handling from Oracle folks or other things to take care of?
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>> Christoph
> >>>>>>>
> >>>>>>> From: ppc-aix-port-dev
> >>>>>>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of
> >>>>>>> Thomas St?fe
> >>>>>>> Sent: Montag, 17. Juli 2017 12:55
> >>>>>>> To: ppc-aix-port-dev at openjdk.java.net
> >>>>>>> Subject: RFR(xs): 8184344: [aix] libjvm.so TOC overflow for
> >>>>>>> slowdebug
> >>>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> may I please have a review for the following fix:
> >>>>>>>
> >>>>>>> webrev:
> >>>>>>>
> >>>>>>>
> http://cr.openjdk.java.net/~stuefe/webrevs/8184344-TOC-overflow/webrev.00/webrev/
> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8184344
> >>>>>>>
> >>>>>>> Basically, the TOC on AIX overflows on slowdebug builds. I am not
> >>>>>>> sure
> >>>>>>> yet which change caused that - I suspect one of the recent
> >>>>>>> template-metaprogramming changes but have not investigated yet.
> >>>>>>>
> >>>>>>> Thanks, Thomas
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >>
>
>


From volker.simonis at gmail.com  Wed Jul 19 13:06:13 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Jul 2017 15:06:13 +0200
Subject: C++11/C++14 support in XLC ?
In-Reply-To: <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com>
References: <OFC998CE95.664CE6A1-ON8025814B.00305A4B-8025814B.00306D2D@LocalDomain>
 <OF8F25A920.5614A9EC-ON0025814E.00730630-8525814E.0074F488@notes.na.collabserv.com>
 <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com>
 <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com>
Message-ID: <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>

On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Jun 30, 2017, at 6:08 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>>> On Jun 29, 2017, at 5:17 PM, Jeff Heath <jrheath at ca.ibm.com> wrote:
>>>
>>> Hi all,
>>>
>>> On the LE Linux platform, XL C/C++ V13.1.5 has full support of C++11 and partial support of C++14.  On AIX, XL C/C++ V13.1.3 has partial support of C++11.  The exact feature list is described in the language reference, but is available in a more consumable form here [1]. This is still a pretty current list.
>>>
>>> [1] https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/What_new_C_11_language_features_you_will_get_by_using_the_latest_XL_C_C_V13_1_2_and_a_sneak_peak_at_C_14?lang=en
>>>
>>> Regards,
>>>
>>> Jeff
>>
>> Thanks for the link.
>>
>> [?]
>> However, just the sheer number of holes in the AIX column is a
>> significant concern. [?]
>
> We're planning another round of compiler upgrades and platform
> refreshes for the JDK support by Oracle.  (Some downstream providers
> are already building with much more recent compilers.)  Absent the
> XLC++ on AIX deficiencies we would be looking at enabling the use of
> C++14 as part of that upgrade; all of the other supported compilers
> can easily handle that.  Is there any information that can be shared
> regarding expected availability of C++11/14 features for XLC++ on AIX?
>

..first of all, adding build-dev because that seems to be the most
appropriate list for such discussions.

For new OpenJDK releases, upgrading the minimal required platforms and
compilers is natural and per se OK.

Requiring new C++ language features is a much more heavyweight change
and needs careful reasoning and discussion:

- OpenJDK is not a "pure" open source project. It is also available as
a commercial version which Oracle licenses to various customers
(including SAP). These customers support more/different platforms than
the ones available in the OpenJDK (i.e. we also support HPUX with
aCC). That said, this is an OpenJDK mailing list and I won't go into
more details here. Such issues should be addressed trough the
corresponding license engineering channels. I just wanted to point out
that (unfortunately) such a discussion probably won't happen
completely in the open.

- I suppose the requirement for C++ 14 is planned only for jdk10 and
beyond  and not for jdk8/jdk9, right? It should be clear however, that
once we start using these new C++ features, downports of
fixes/features will become increasingly hard. And not only if the
fixes/feature uses the new C++ 14 features, but also if they
indirectly rely on them. The exact amount of these costs depends on
how many fixes/features will be downported in the future. If we really
come to a more frequent release model (as discussed in other threads),
this may be not that much of a problem.

- Related to the previous topic, I suppose you don't plan to upgrade
the compiler requirements for already released versions of OpenJDK. Is
this correct?

- SAP is currently maintaining the AIX port in the OpenJDK and we're
willing to do that in the future. But we're not IBM and we can not
decide about the XLC feature list. If Oracle and the OpenJDK community
finally decide to use C++11/14 features which are not available in XLC
we have to live with that. We can either escalate the XLC deficiencies
to IBM and suspend the port until the compiler gets fixed. Or we can
switch the port to use the GCC tool chain with all the pros (bigger
compatibility with Linux platforms) and cons (porting effort, testing,
compatibility with other AIX software compiled with XLC, compiler
support). While the GCC alternative sounds very appealing at a first
glance it really isn't that perfect in reality, especially not for our
commercial SAP JVM version of OpenJDK. One problem is the fact that
there's no official support for GCC on AIX, the other is
compatibility. Just think you had to replace Solaris Studio by GCC on
Solaris :)

@Tim, Jeff: could you pleas escalate this issue to XLC product
management and get back to us with the outcome?

Finally, I'm not sure what would be the right format to discuss this
issue (maybe a JEP, maybe an enhancement request in JBS, maybe just a
mail thread) and how to proceed? Pragmatically, we could already now
start to add code which uses new C++ features as long as it is
supported on ALL current OpenJDK platforms (and in fact we are already
doing this as the recent "type_traits metaprogramming" change 8183927
has demonstrated). Ideally, we would come up with a fixed set of
required features to avoid compatibility discussions for every single
change.

Regards,
Volker

PS: please don't shoot the messenger :) Personally I'm all for using
new compiler features if they deem useful but professionally I get
paid for supporting some exotic platforms...

>


From kim.barrett at oracle.com  Wed Jul 19 22:35:03 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 19 Jul 2017 18:35:03 -0400
Subject: C++11/C++14 support in XLC ?
In-Reply-To: <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>
References: <OFC998CE95.664CE6A1-ON8025814B.00305A4B-8025814B.00306D2D@LocalDomain>
 <OF8F25A920.5614A9EC-ON0025814E.00730630-8525814E.0074F488@notes.na.collabserv.com>
 <083560E9-DBE7-49F1-8EBE-3BB5339DED4F@oracle.com>
 <4A07D214-D69A-4010-8E60-984DA46DC6F4@oracle.com>
 <CA+3eh12f2Og2+BiMQaemLLE0UJRR-TcjtQKpj93rP_tCw8RrHw@mail.gmail.com>
Message-ID: <C05FB9AE-63AD-44B7-9BE6-E2461E557B86@oracle.com>

> On Jul 19, 2017, at 9:06 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> We're planning another round of compiler upgrades and platform
>> refreshes for the JDK support by Oracle. 
> 
> ..first of all, adding build-dev because that seems to be the most
> appropriate list for such discussions.

Seems as good as any for now.  hotspot-dev might be an alternative, though
there?s C++ code elsewhere in the jdk.

> For new OpenJDK releases, upgrading the minimal required platforms and
> compilers is natural and per se OK.
> 
> Requiring new C++ language features is a much more heavyweight change
> and needs careful reasoning and discussion:
> 
> - OpenJDK is not a "pure" open source project. It is also available as
> a commercial version which Oracle licenses to various customers
> (including SAP). These customers support more/different platforms than
> the ones available in the OpenJDK (i.e. we also support HPUX with
> aCC).

A compiler I'd forgotten about.

> That said, this is an OpenJDK mailing list and I won't go into
> more details here. Such issues should be addressed trough the
> corresponding license engineering channels. I just wanted to point out
> that (unfortunately) such a discussion probably won't happen
> completely in the open.
> 
> - I suppose the requirement for C++ 14 is planned only for jdk10 and
> beyond  and not for jdk8/jdk9, right? It should be clear however, that
> once we start using these new C++ features, downports of
> fixes/features will become increasingly hard. And not only if the
> fixes/feature uses the new C++ 14 features, but also if they
> indirectly rely on them. The exact amount of these costs depends on
> how many fixes/features will be downported in the future. If we really
> come to a more frequent release model (as discussed in other threads),
> this may be not that much of a problem.

I don't think there's any intent to backport such a change.  I don't
think there's a specific jdk version being targeted yet either; this
is all still in a preliminary discussion phase.  The possibility of a
more frequent release model is one of the considerations.  There is
also a substantial amount of work to be done to get to that point;
there's some problematic code in Hotspot :)

> - Related to the previous topic, I suppose you don't plan to upgrade
> the compiler requirements for already released versions of OpenJDK. Is
> this correct?

So far as I know, that's correct.  

> - SAP is currently maintaining the AIX port in the OpenJDK and we're
> willing to do that in the future. But we're not IBM and we can not
> decide about the XLC feature list. If Oracle and the OpenJDK community
> finally decide to use C++11/14 features which are not available in XLC
> we have to live with that. We can either escalate the XLC deficiencies
> to IBM and suspend the port until the compiler gets fixed. Or we can
> switch the port to use the GCC tool chain with all the pros (bigger
> compatibility with Linux platforms) and cons (porting effort, testing,
> compatibility with other AIX software compiled with XLC, compiler
> support). While the GCC alternative sounds very appealing at a first
> glance it really isn't that perfect in reality, especially not for our
> commercial SAP JVM version of OpenJDK. One problem is the fact that
> there's no official support for GCC on AIX, the other is
> compatibility. Just think you had to replace Solaris Studio by GCC on
> Solaris :)
> 
> @Tim, Jeff: could you pleas escalate this issue to XLC product
> management and get back to us with the outcome?
> 
> Finally, I'm not sure what would be the right format to discuss this
> issue (maybe a JEP, maybe an enhancement request in JBS, maybe just a
> mail thread) and how to proceed?

Right now I think email discussion like we're doing here makes sense.
More formality will be needed eventually, but doesn't seem helpful
yet.

> Pragmatically, we could already now
> start to add code which uses new C++ features as long as it is
> supported on ALL current OpenJDK platforms (and in fact we are already
> doing this as the recent "type_traits metaprogramming" change 8183927
> has demonstrated).

I wouldn't describe 8183927 as using new C++ features.  There's
nothing there that hasn't existed in other C++98 code bases for a long
time.  C++11 simply codified some existing practice in that area
(specifically Boost.TypeTraits).  C++11 also includes a number of type
traits that are at least hard, if not impossible, to implement in a
portable fashion in C++98.  So far we haven't required any of those...

> Ideally, we would come up with a fixed set of
> required features to avoid compatibility discussions for every single
> change.

I've seen this tried, and it can be pretty hard.  For example, Boost
has a long list of configuration macros for various C++98/11/14
features; that list is both interesting and daunting.  (I don't
propose we do anything similar and have multiple implementations based
on supported language features.  We already have way more than enough
of that kind of thing because of multiple platforms.)



From nishit.jain at oracle.com  Thu Jul 20 05:33:24 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 20 Jul 2017 11:03:24 +0530
Subject: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map in
 LocaleEquivalentMap.java
Message-ID: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>

Hi,

Please review the fix for JDK-8177472

Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/

Issue:The existing process of updating the LSR data requires manual 
execution of EquivMapsGenerator.java for generation of the updated maps.
Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
included in the JDK build process. After this change updation of LSR 
data will mostly require replacement of old language-subtag-registry.txt 
file with the new one and changing the copyright year in 
EquivMapsGenerator.java (if required) for the generated maps file.

Regards,
Nishit Jain


From prasanta.sadhukhan at oracle.com  Thu Jul 20 08:45:01 2017
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Thu, 20 Jul 2017 14:15:01 +0530
Subject: [10] RFR JDK-8184813:Class
 javax/swing/plaf/metal/MetalFontDesktopProperty is broken in JDK10
Message-ID: <44afd87f-00a4-585a-a9e8-d68b4e18667b@oracle.com>

Hi All,

This is a back-out of 6461834: Minimize WindowsLookAndFeel classes 
included with Unix JDKs
fix which was done to make sure WindowsLookAndFeel classes are not built 
for non-windows platform

but it seems there are some classes in shared folder which uses 
com/sun/java/swing/plaf/windows/ class.
It will require moving around those classes to windows and test.
But to aid jdk10 integration, I guess it is best to back-out the earlier 
fix and work on this later.

Bug: https://bugs.openjdk.java.net/browse/JDK-8184813
webrev: http://cr.openjdk.java.net/~psadhukhan/8184813/

Regards
Prasanta


From naoto.sato at oracle.com  Thu Jul 20 18:06:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Jul 2017 11:06:07 -0700
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
Message-ID: <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>

Looks good to me.

Naoto

On 7/19/17 10:33 PM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8177472
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
> 
> Issue:The existing process of updating the LSR data requires manual 
> execution of EquivMapsGenerator.java for generation of the updated maps.
> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
> included in the JDK build process. After this change updation of LSR 
> data will mostly require replacement of old language-subtag-registry.txt 
> file with the new one and changing the copyright year in 
> EquivMapsGenerator.java (if required) for the generated maps file.
> 
> Regards,
> Nishit Jain


From philip.race at oracle.com  Thu Jul 20 21:01:14 2017
From: philip.race at oracle.com (Phil Race)
Date: Thu, 20 Jul 2017 14:01:14 -0700
Subject: <Swing Dev> [10] RFR JDK-8184813:Class
 javax/swing/plaf/metal/MetalFontDesktopProperty is broken in JDK10
In-Reply-To: <44afd87f-00a4-585a-a9e8-d68b4e18667b@oracle.com>
References: <44afd87f-00a4-585a-a9e8-d68b4e18667b@oracle.com>
Message-ID: <b8298420-4141-ab6f-6fcc-3fef816e4b9e@oracle.com>

+1

-phil.

On 07/20/2017 01:45 AM, Prasanta Sadhukhan wrote:
> Hi All,
>
> This is a back-out of 6461834: Minimize WindowsLookAndFeel classes 
> included with Unix JDKs
> fix which was done to make sure WindowsLookAndFeel classes are not 
> built for non-windows platform
>
> but it seems there are some classes in shared folder which uses 
> com/sun/java/swing/plaf/windows/ class.
> It will require moving around those classes to windows and test.
> But to aid jdk10 integration, I guess it is best to back-out the 
> earlier fix and work on this later.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184813
> webrev: http://cr.openjdk.java.net/~psadhukhan/8184813/
>
> Regards
> Prasanta



From rocky.sloan at oracle.com  Thu Jul 20 21:15:45 2017
From: rocky.sloan at oracle.com (Rocky Sloan)
Date: Thu, 20 Jul 2017 14:15:45 -0700
Subject: <Swing Dev> [10] RFR JDK-8184813:Class
 javax/swing/plaf/metal/MetalFontDesktopProperty is broken in JDK10
In-Reply-To: <b8298420-4141-ab6f-6fcc-3fef816e4b9e@oracle.com>
References: <44afd87f-00a4-585a-a9e8-d68b4e18667b@oracle.com>
 <b8298420-4141-ab6f-6fcc-3fef816e4b9e@oracle.com>
Message-ID: <E98B149B-D0CC-401D-AF8C-76DA9C7F422A@oracle.com>

+1

- Rocky

On Jul 20, 2017, at 2:01 PM, Phil Race <philip.race at oracle.com> wrote:

> +1
> 
> -phil.
> 
> On 07/20/2017 01:45 AM, Prasanta Sadhukhan wrote:
>> Hi All,
>> 
>> This is a back-out of 6461834: Minimize WindowsLookAndFeel classes included with Unix JDKs
>> fix which was done to make sure WindowsLookAndFeel classes are not built for non-windows platform
>> 
>> but it seems there are some classes in shared folder which uses com/sun/java/swing/plaf/windows/ class.
>> It will require moving around those classes to windows and test.
>> But to aid jdk10 integration, I guess it is best to back-out the earlier fix and work on this later.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184813
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8184813/
>> 
>> Regards
>> Prasanta
> 


From sergey.bylokhov at oracle.com  Fri Jul 21 02:15:55 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 20 Jul 2017 19:15:55 -0700 (PDT)
Subject: <Swing Dev> [10] RFR JDK-8184813:Class
 javax/swing/plaf/metal/MetalFontDesktopProperty is broken in JDK10
Message-ID: <f7ace859-b197-4d30-a5ec-1b6905da3893@default>

+1

----- philip.race at oracle.com wrote:

> +1
> 
> -phil.
> 
> On 07/20/2017 01:45 AM, Prasanta Sadhukhan wrote:
> > Hi All,
> >
> > This is a back-out of 6461834: Minimize WindowsLookAndFeel classes 
> > included with Unix JDKs
> > fix which was done to make sure WindowsLookAndFeel classes are not 
> > built for non-windows platform
> >
> > but it seems there are some classes in shared folder which uses 
> > com/sun/java/swing/plaf/windows/ class.
> > It will require moving around those classes to windows and test.
> > But to aid jdk10 integration, I guess it is best to back-out the 
> > earlier fix and work on this later.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8184813
> > webrev: http://cr.openjdk.java.net/~psadhukhan/8184813/
> >
> > Regards
> > Prasanta


From claes.redestad at oracle.com  Sun Jul 23 13:37:44 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 23 Jul 2017 15:37:44 +0200
Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly
Message-ID: <a88eef59-133c-e0ce-7309-ed6adca82f25@oracle.com>

Hi,

java.lang.CharacterDataLatin1 and others are generated at build time by 
the GenerateCharacter tool, which has a -string mode to generate lookup 
tables as Strings literals rather than arrays directly. This serves 
multiple purposes:

1. it reduces the size of the generated bytecode, which is necessary to 
keep code below method bytecode limits if the arrays generated are very 
large
2. it may under certain circumstances (large enough arrays, JITed code) 
be a performance optimization

While having other performance benefits, the compact strings feature 
that went into 9 made String::toCharArray less friendly to startup, and 
since the same feature means we're now always loading 
CharacterDataLatin1 on bootstrap in all locales it seemed reasonable to 
re-examine whether this class in particular really gains from generating 
its lookup tables via String literals.

Turns out it doesn't. By generating CharacterDataLatin1 tables as arrays 
explicitly:

- executed bytecode drop from 21,782 to 2,077 when initializing this 
class (approximately 2% of executed bytecode; 1.5% of total instructions)
- slight reduction (~1Kb) in the minimum retained heap usage
- the size of CharacterDataLatin1.class only grows from 6458 to 7385 bytes

Proposed patch is to drop passing -string to GenerateCharacter for the 
latin1 case:

Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/
Bug:    https://bugs.openjdk.java.net/browse/JDK-8185104

Thanks!

/Claes


From Alan.Bateman at oracle.com  Mon Jul 24 08:29:00 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 24 Jul 2017 09:29:00 +0100
Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables
 directly
In-Reply-To: <a88eef59-133c-e0ce-7309-ed6adca82f25@oracle.com>
References: <a88eef59-133c-e0ce-7309-ed6adca82f25@oracle.com>
Message-ID: <f517e736-bc25-3241-378d-3a0510ba7ab2@oracle.com>



On 23/07/2017 14:37, Claes Redestad wrote:
> Hi,
>
> java.lang.CharacterDataLatin1 and others are generated at build time 
> by the GenerateCharacter tool, which has a -string mode to generate 
> lookup tables as Strings literals rather than arrays directly. This 
> serves multiple purposes:
>
> 1. it reduces the size of the generated bytecode, which is necessary 
> to keep code below method bytecode limits if the arrays generated are 
> very large
> 2. it may under certain circumstances (large enough arrays, JITed 
> code) be a performance optimization
>
> While having other performance benefits, the compact strings feature 
> that went into 9 made String::toCharArray less friendly to startup, 
> and since the same feature means we're now always loading 
> CharacterDataLatin1 on bootstrap in all locales it seemed reasonable 
> to re-examine whether this class in particular really gains from 
> generating its lookup tables via String literals.
>
> Turns out it doesn't. By generating CharacterDataLatin1 tables as 
> arrays explicitly:
>
> - executed bytecode drop from 21,782 to 2,077 when initializing this 
> class (approximately 2% of executed bytecode; 1.5% of total instructions)
> - slight reduction (~1Kb) in the minimum retained heap usage
> - the size of CharacterDataLatin1.class only grows from 6458 to 7385 
> bytes
>
> Proposed patch is to drop passing -string to GenerateCharacter for the 
> latin1 case:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8185104
This is a good sleuthing. I can't see of any reason why the tables in 
CharacterDataLatin1 need to be generated as Strings now I think this 
change is good.

-Alan


From claes.redestad at oracle.com  Mon Jul 24 08:32:55 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 24 Jul 2017 10:32:55 +0200
Subject: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables
 directly
In-Reply-To: <f517e736-bc25-3241-378d-3a0510ba7ab2@oracle.com>
References: <a88eef59-133c-e0ce-7309-ed6adca82f25@oracle.com>
 <f517e736-bc25-3241-378d-3a0510ba7ab2@oracle.com>
Message-ID: <a7095965-7abf-8bf5-2e00-eb342fa197ad@oracle.com>


On 07/24/2017 10:29 AM, Alan Bateman wrote:
>
> On 23/07/2017 14:37, Claes Redestad wrote:
>> Proposed patch is to drop passing -string to GenerateCharacter for 
>> the latin1 case:
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8185104/jdk.00/
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8185104
> This is a good sleuthing. I can't see of any reason why the tables in 
> CharacterDataLatin1 need to be generated as Strings now I think this 
> change is good.

Thanks for reviewing, Alan!

/Claes


From nishit.jain at oracle.com  Tue Jul 25 08:59:38 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 25 Jul 2017 14:29:38 +0530
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>
Message-ID: <0731abb3-a165-c1c2-3c71-dca72f89c72a@oracle.com>

A gentle reminder! Requesting for a build review

Regards,
Nishit Jain
On 20-07-2017 23:36, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 7/19/17 10:33 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8177472
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>
>> Issue:The existing process of updating the LSR data requires manual 
>> execution of EquivMapsGenerator.java for generation of the updated maps.
>> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
>> included in the JDK build process. After this change updation of LSR 
>> data will mostly require replacement of old 
>> language-subtag-registry.txt file with the new one and changing the 
>> copyright year in EquivMapsGenerator.java (if required) for the 
>> generated maps file.
>>
>> Regards,
>> Nishit Jain



From Roger.Riggs at Oracle.com  Tue Jul 25 15:58:30 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 25 Jul 2017 11:58:30 -0400
Subject: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map
 in LocaleEquivalentMap.java
In-Reply-To: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
Message-ID: <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>

Hi Nishit,

Can the hardcoded copyright be made more automatic?

I see the make/src/classes/build/tools/cldrconverter has functions to 
create/convert copyrights.
Can that be leveraged to generate the needed copyright and reduce some 
potential maintenance
of the copyright date and or contents?

Can the latest copyright date be taken from the File-Date field of the 
subtag-registry?

Thanks, Roger

On 7/20/2017 1:33 AM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8177472
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>
> Issue:The existing process of updating the LSR data requires manual 
> execution of EquivMapsGenerator.java for generation of the updated maps.
> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
> included in the JDK build process. After this change updation of LSR 
> data will mostly require replacement of old 
> language-subtag-registry.txt file with the new one and changing the 
> copyright year in EquivMapsGenerator.java (if required) for the 
> generated maps file.
>
> Regards,
> Nishit Jain



From nishit.jain at oracle.com  Tue Jul 25 17:16:43 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 25 Jul 2017 22:46:43 +0530
Subject: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map
 in LocaleEquivalentMap.java
In-Reply-To: <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
Message-ID: <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>

Hi Roger,

CLDR converter generate the copyright year by the current date in which 
it is getting executed. I think the copyright year in 
LocaleEquivalentMaps.java should be the year in which the lsr data is 
last updated in jdk i.e. the year in which LocaleEquivalentMaps.java is 
last modified. This makes it difficult to compute the year automatically 
unless someone specifies it while updating the data.

 > Can the latest copyright date be taken from the File-Date field of 
the subtag-registry?
This may not be necessarily same as the year in which lsr data is 
updated in jdk.

Regards,
Nishit Jain
On 25-07-2017 21:28, Roger Riggs wrote:
> Hi Nishit,
>
> Can the hardcoded copyright be made more automatic?
>
> I see the make/src/classes/build/tools/cldrconverter has functions to 
> create/convert copyrights.
> Can that be leveraged to generate the needed copyright and reduce some 
> potential maintenance
> of the copyright date and or contents?
>
> Can the latest copyright date be taken from the File-Date field of the 
> subtag-registry?
>
> Thanks, Roger
>
> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8177472
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>
>> Issue:The existing process of updating the LSR data requires manual 
>> execution of EquivMapsGenerator.java for generation of the updated maps.
>> Fix:The execution of EquivMapsGenerator.javafor generation of maps is 
>> included in the JDK build process. After this change updation of LSR 
>> data will mostly require replacement of old 
>> language-subtag-registry.txt file with the new one and changing the 
>> copyright year in EquivMapsGenerator.java (if required) for the 
>> generated maps file.
>>
>> Regards,
>> Nishit Jain
>



From Roger.Riggs at Oracle.com  Tue Jul 25 17:25:07 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 25 Jul 2017 13:25:07 -0400
Subject: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map
 in LocaleEquivalentMap.java
In-Reply-To: <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
 <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
Message-ID: <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>

Hi,

I was focused mostly on *not *hardcoding the copyright text in yet 
another place
and if possible avoiding a manual update of the year.

And yet since the source is being generated and is transient (not 
retained after the build), the current year
is correct. (Same as cldr)

Roger


On 7/25/2017 1:16 PM, Nishit Jain wrote:
> Hi Roger,
>
> CLDR converter generate the copyright year by the current date in 
> which it is getting executed. I think the copyright year in 
> LocaleEquivalentMaps.java should be the year in which the lsr data is 
> last updated in jdk i.e. the year in which LocaleEquivalentMaps.java 
> is last modified. This makes it difficult to compute the year 
> automatically unless someone specifies it while updating the data.
>
> > Can the latest copyright date be taken from the File-Date field of 
> the subtag-registry?
> This may not be necessarily same as the year in which lsr data is 
> updated in jdk.
>
> Regards,
> Nishit Jain
> On 25-07-2017 21:28, Roger Riggs wrote:
>> Hi Nishit,
>>
>> Can the hardcoded copyright be made more automatic?
>>
>> I see the make/src/classes/build/tools/cldrconverter has functions to 
>> create/convert copyrights.
>> Can that be leveraged to generate the needed copyright and reduce 
>> some potential maintenance
>> of the copyright date and or contents?
>>
>> Can the latest copyright date be taken from the File-Date field of 
>> the subtag-registry?
>>
>> Thanks, Roger
>>
>> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8177472
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>
>>> Issue:The existing process of updating the LSR data requires manual 
>>> execution of EquivMapsGenerator.java for generation of the updated 
>>> maps.
>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps 
>>> is included in the JDK build process. After this change updation of 
>>> LSR data will mostly require replacement of old 
>>> language-subtag-registry.txt file with the new one and changing the 
>>> copyright year in EquivMapsGenerator.java (if required) for the 
>>> generated maps file.
>>>
>>> Regards,
>>> Nishit Jain
>>
>



From tim.bell at oracle.com  Wed Jul 26 04:24:05 2017
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 25 Jul 2017 21:24:05 -0700
Subject: <i18n dev> [10] RFR JDK-8177472: Remove hard-coded IANA Subtag
 Registry map in LocaleEquivalentMap.java
In-Reply-To: <0731abb3-a165-c1c2-3c71-dca72f89c72a@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <ce41d465-b014-e5c3-09fd-0e3216dd8ae6@oracle.com>
 <0731abb3-a165-c1c2-3c71-dca72f89c72a@oracle.com>
Message-ID: <59781965.7080503@oracle.com>

Hello Nishit:

> A gentle reminder! Requesting for a build review
>
> Regards,
> Nishit Jain

The build changes look fine.

Tim


> On 20-07-2017 23:36, Naoto Sato wrote:
>> Looks good to me.
>>
>> Naoto
>>
>> On 7/19/17 10:33 PM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8177472
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>
>>> Issue:The existing process of updating the LSR data requires manual
>>> execution of EquivMapsGenerator.java for generation of the updated maps.
>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps is
>>> included in the JDK build process. After this change updation of LSR
>>> data will mostly require replacement of old
>>> language-subtag-registry.txt file with the new one and changing the
>>> copyright year in EquivMapsGenerator.java (if required) for the
>>> generated maps file.
>>>
>>> Regards,
>>> Nishit Jain
>



From nishit.jain at oracle.com  Wed Jul 26 06:34:47 2017
From: nishit.jain at oracle.com (Nishit Jain)
Date: Wed, 26 Jul 2017 12:04:47 +0530
Subject: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map
 in LocaleEquivalentMap.java
In-Reply-To: <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
 <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
 <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>
Message-ID: <c9d50ad6-d611-a700-058e-3174e6dbb781@oracle.com>

Thanks Roger,

Made the suggested changes related to hardcoded copyright year. Please 
check the updated webrev
http://cr.openjdk.java.net/~nishjain/8177472/webrev.06/

Regards,
Nishit Jain
On 25-07-2017 22:55, Roger Riggs wrote:
> Hi,
>
> I was focused mostly on *not *hardcoding the copyright text in yet 
> another place
> and if possible avoiding a manual update of the year.
>
> And yet since the source is being generated and is transient (not 
> retained after the build), the current year
> is correct. (Same as cldr)
>
> Roger
>
>
> On 7/25/2017 1:16 PM, Nishit Jain wrote:
>> Hi Roger,
>>
>> CLDR converter generate the copyright year by the current date in 
>> which it is getting executed. I think the copyright year in 
>> LocaleEquivalentMaps.java should be the year in which the lsr data is 
>> last updated in jdk i.e. the year in which LocaleEquivalentMaps.java 
>> is last modified. This makes it difficult to compute the year 
>> automatically unless someone specifies it while updating the data.
>>
>> > Can the latest copyright date be taken from the File-Date field of 
>> the subtag-registry?
>> This may not be necessarily same as the year in which lsr data is 
>> updated in jdk.
>>
>> Regards,
>> Nishit Jain
>> On 25-07-2017 21:28, Roger Riggs wrote:
>>> Hi Nishit,
>>>
>>> Can the hardcoded copyright be made more automatic?
>>>
>>> I see the make/src/classes/build/tools/cldrconverter has functions 
>>> to create/convert copyrights.
>>> Can that be leveraged to generate the needed copyright and reduce 
>>> some potential maintenance
>>> of the copyright date and or contents?
>>>
>>> Can the latest copyright date be taken from the File-Date field of 
>>> the subtag-registry?
>>>
>>> Thanks, Roger
>>>
>>> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>>>> Hi,
>>>>
>>>> Please review the fix for JDK-8177472
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>>
>>>> Issue:The existing process of updating the LSR data requires manual 
>>>> execution of EquivMapsGenerator.java for generation of the updated 
>>>> maps.
>>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps 
>>>> is included in the JDK build process. After this change updation of 
>>>> LSR data will mostly require replacement of old 
>>>> language-subtag-registry.txt file with the new one and changing the 
>>>> copyright year in EquivMapsGenerator.java (if required) for the 
>>>> generated maps file.
>>>>
>>>> Regards,
>>>> Nishit Jain
>>>
>>
>



From Roger.Riggs at Oracle.com  Wed Jul 26 13:10:11 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 26 Jul 2017 09:10:11 -0400
Subject: [10] RFR JDK-8177472: Remove hard-coded IANA Subtag Registry map
 in LocaleEquivalentMap.java
In-Reply-To: <c9d50ad6-d611-a700-058e-3174e6dbb781@oracle.com>
References: <2992c14a-c8ec-2127-be42-181d271bc12a@oracle.com>
 <416b6ca7-4715-f3b4-ce07-73cdc9dbe2f3@Oracle.com>
 <988d53a4-e57e-9f6b-9d04-c834f73bd652@oracle.com>
 <ba72cfd8-88c5-75b4-bdd8-cece297f6ca6@Oracle.com>
 <c9d50ad6-d611-a700-058e-3174e6dbb781@oracle.com>
Message-ID: <79b952ca-c088-6b37-0bb3-155eab55860a@Oracle.com>

good enough.

Roger


On 7/26/2017 2:34 AM, Nishit Jain wrote:
> Thanks Roger,
>
> Made the suggested changes related to hardcoded copyright year. Please 
> check the updated webrev
> http://cr.openjdk.java.net/~nishjain/8177472/webrev.06/
>
> Regards,
> Nishit Jain
> On 25-07-2017 22:55, Roger Riggs wrote:
>> Hi,
>>
>> I was focused mostly on *not *hardcoding the copyright text in yet 
>> another place
>> and if possible avoiding a manual update of the year.
>>
>> And yet since the source is being generated and is transient (not 
>> retained after the build), the current year
>> is correct. (Same as cldr)
>>
>> Roger
>>
>>
>> On 7/25/2017 1:16 PM, Nishit Jain wrote:
>>> Hi Roger,
>>>
>>> CLDR converter generate the copyright year by the current date in 
>>> which it is getting executed. I think the copyright year in 
>>> LocaleEquivalentMaps.java should be the year in which the lsr data 
>>> is last updated in jdk i.e. the year in which 
>>> LocaleEquivalentMaps.java is last modified. This makes it difficult 
>>> to compute the year automatically unless someone specifies it while 
>>> updating the data.
>>>
>>> > Can the latest copyright date be taken from the File-Date field of 
>>> the subtag-registry?
>>> This may not be necessarily same as the year in which lsr data is 
>>> updated in jdk.
>>>
>>> Regards,
>>> Nishit Jain
>>> On 25-07-2017 21:28, Roger Riggs wrote:
>>>> Hi Nishit,
>>>>
>>>> Can the hardcoded copyright be made more automatic?
>>>>
>>>> I see the make/src/classes/build/tools/cldrconverter has functions 
>>>> to create/convert copyrights.
>>>> Can that be leveraged to generate the needed copyright and reduce 
>>>> some potential maintenance
>>>> of the copyright date and or contents?
>>>>
>>>> Can the latest copyright date be taken from the File-Date field of 
>>>> the subtag-registry?
>>>>
>>>> Thanks, Roger
>>>>
>>>> On 7/20/2017 1:33 AM, Nishit Jain wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix for JDK-8177472
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177472
>>>>> Webrev: http://cr.openjdk.java.net/~nishjain/8177472/webrev.05/
>>>>>
>>>>> Issue:The existing process of updating the LSR data requires 
>>>>> manual execution of EquivMapsGenerator.java for generation of the 
>>>>> updated maps.
>>>>> Fix:The execution of EquivMapsGenerator.javafor generation of maps 
>>>>> is included in the JDK build process. After this change updation 
>>>>> of LSR data will mostly require replacement of old 
>>>>> language-subtag-registry.txt file with the new one and changing 
>>>>> the copyright year in EquivMapsGenerator.java (if required) for 
>>>>> the generated maps file.
>>>>>
>>>>> Regards,
>>>>> Nishit Jain
>>>>
>>>
>>
>