From asmundak at google.com  Tue Dec  1 03:31:03 2015
From: asmundak at google.com (Alexander Smundak)
Date: Mon, 30 Nov 2015 19:31:03 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <565C4477.4090708@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
Message-ID: <CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>

> On 2015-11-30 05:23, David Holmes wrote:
>>..
>> At the top level if we see ppc64le then we set VAR_CPU to ppc64le instead
>> of ppc64. However, once we get into hotspot build we want ARCH to be ppc64
>> again (in hotspot-spec.gmk.in) - why is that?
>>
>> Inside hotpot we want:
>>
>> SRCARCH := ppc
>> BUILDARCH := ppc64
>> LIBARCH := ppc64le
>>
>> right? So can ARCH not be ppc64le from the top-level and then we adjust
>> SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH.
The new revision does that:
http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/

common/autoconf/hotspot-spec.gmk.in has been left alone, and
hotspot/make/defs.make sets BUILDARCH and LIBARCH
(BUILDARCH should be the same for ppc64 and ppc64le because the file
linux/makefiels/$)BUILDARCH).make is pulled in by vm.make)
I have also reduced the changeset for hotspot by making
sun.jvm.hotspot.utilities.PlatformInfo.getCPU() return "ppc64" both
when
"os.arch" propertie's value is "ppc64" and "ppc64le".

>>
>> agent/src/os/linux/LinuxDebuggerLocal.c
>> agent/src/os/linux/libproc.h
>>
>> Is it not the case that ppc64le -> ppc64, so that we can avoid "if
>> defined(ppc64) | defined(ppc64le) ? I would hope that the only places in the
>> sources where you need to check for ppc64le is where that code differs from
>> the ppc64 code.
This is defined as -D$(OPENJDK_TARGET_CPU_LEGACY), but the same variable
is used in the generated hotspot-spec.gmk file, so I decided it's
easier to fix the
SA code.

>> src/share/vm/runtime/vm_version.cpp
>>
>> I think this messy code block relates to builds where CPU is not set -
>> which should never be the case these days. Maybe just put in a check "ifndef
>> CPU -> error" ?
>
> I agree. There might be a case for handling zero, though. If I remember
> correctly the hotspot build might not set CPU, or set it incorrectly, when
> building zero. (Then again, zero is a strange beast, a mix between a variant
> and a platform...)

I have listed platform-specific options for building Hotspot above,
but here's the full command line to build vm_version.o for ppc64le:

/usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
-I<JDK9>/hotspot/src/share/vm/prims -I<JDK9>/hotspot/src/share/vm
-I<JDK9>/hotspot/src/share/vm/precompiled
-I<JDK9>/hotspot/src/cpu/ppc/vm
-I<JDK9>/hotspot/src/os_cpu/linux_ppc/vm
-I<JDK9>/hotspot/src/os/linux/vm -I<JDK9>/hotspot/src/os/posix/vm
-I../generated -DHOTSPOT_BUILD_USER="\"asmundak\""
-DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
-DHOTSPOT_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\""
-DJRE_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\""
-DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\""
-DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"b00\""
-DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
-DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
-DTARGET_COMPILER_gcc -DCOMPILER2 -DINCLUDE_JVMCI=0 -fPIC -fno-rtti
-fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64
-pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3   -g -D_LP64=1
-DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8
-minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror
-Wpointer-arith -Wsign-compare -Wundef -Wunused-function
-Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual
-Wtype-limits -Wno-format-zero-length -Wuninitialized   -c -MMD -MP
-MF ../generated/dependencies/vm_version.o.d -fpch-deps -o
vm_version.o <JDK9>/hotspot/src/share/vm/runtime/vm_version.cpp
(I have replaced the actual path to the source tree with <JDK9>)

Preprocessor variable 'CPU' is not defined on the command line, and if I add
#error CPU is not defined
right after
#fndef CPU
on line 193 in vm_version.cpp,
it will fail to compile at least on Linux ppc64le and Linux x86_64.

> I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is defined
> to ppc for both ppc64 and the new ppc64le platform, that it, it explicitely
> excludes address size. I think it's reasonable that it excludes endianness
> as well, but we have not really had to make that discussion before. In any
> case, it should not contain "64", otherwise the value will be "ppc" for
> ppc64 and "ppc64le" for ppc64le, and that's just plain wrong.
With the proposed patches the generated spec.gmk will contain
   OPENJDK_TARGET_CPU_OSARCH:=ppc64le
when building JDK for the little endian and ppc64 for the big endian.
"os.arch" property is set from ARCHPROPNAME preprocessor variable,
whose value is $(OPENJDK_TARGET_CPU_ARCH). Did I misunderstand
something?


From erik.joelsson at oracle.com  Tue Dec  1 09:55:31 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 1 Dec 2015 10:55:31 +0100
Subject: RFR: JDK-8144312: Remove limitations on the default number of jobs in
	the build
Message-ID: <565D6E93.8000603@oracle.com>

Hello,

The current heuristic for figuring out what to default set the -j flag 
to make needs some tweaking.

In JDK 9, it looks at the amount of memory and the number of cpus in the 
system. It divides memory by 1024 to get a safe number of jobs that will 
fit into memory. The lower of that number and the number of cpus is then 
picked. The number is then scaled down to about 90% of the number of 
cpus to leave some resources for other activities. It is also capped at 16.

Since we now have the build using "nice" to make sure the build isn't 
bogging down the system, I see no reason to do the 90% scaling anymore. 
Also, the performance issues that forced us to cap at 16 have long been 
fixed, and even if we don't scale well beyond 16, we do still scale. So 
I propose we remove that arbitrary limitation too.

Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/

/Erik


From sean.mullan at oracle.com  Tue Dec  1 14:34:21 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 Dec 2015 09:34:21 -0500
Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not
	complete
In-Reply-To: <4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com>
References: <DD0A4ABD-3176-4276-BFD4-86512F20E88C@oracle.com>
	<58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com>
	<5654458D.1080705@oracle.com> <5655CE04.2000004@oracle.com>
	<4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com>
Message-ID: <565DAFED.90408@oracle.com>

Looks good, although the location of the new test (test/sun/security) 
doesn't seem right. A new directory named test/conf/security would 
probably make the most sense, but I think putting it in the new 
test/jdk/security directory is also a better option.

--Sean

On 11/25/2015 09:36 PM, Wang Weijun wrote:
>
>> On Nov 25, 2015, at 11:04 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> The fix looks fine to me. For testing, can you create a test that uses a custom java.security file with "#ifndef solaris-sparc" in it, and check whether the property is used or not depending on what system is being tested?
>
> The tool is inside another repo. I can still write one though.
>
> Please take a look at the updated webrev:
>
>     http://cr.openjdk.java.net/~weijun/8141690/webrev.01/
>
> I also fixed a bug inside MakeJavaSecurity.java. If package.access or package.definition happens to be the last property, an NPE will be thrown.
>
> Thanks
> Max
>
>>
>> --Sean
>>>>>
>>>>>    http://cr.openjdk.java.net/~weijun/8141690/webrev.00/
>>>>>
>


From tim.bell at oracle.com  Tue Dec  1 16:06:08 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 01 Dec 2015 08:06:08 -0800
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <565D6E93.8000603@oracle.com>
References: <565D6E93.8000603@oracle.com>
Message-ID: <565DC570.2050804@oracle.com>

Erik:

> The current heuristic for figuring out what to default set the -j flag 
> to make needs some tweaking.
>
> In JDK 9, it looks at the amount of memory and the number of cpus in 
> the system. It divides memory by 1024 to get a safe number of jobs 
> that will fit into memory. The lower of that number and the number of 
> cpus is then picked. The number is then scaled down to about 90% of 
> the number of cpus to leave some resources for other activities. It is 
> also capped at 16.
>
> Since we now have the build using "nice" to make sure the build isn't 
> bogging down the system, I see no reason to do the 90% scaling 
> anymore. Also, the performance issues that forced us to cap at 16 have 
> long been fixed, and even if we don't scale well beyond 16, we do 
> still scale. So I propose we remove that arbitrary limitation too.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/

Looks good to me.

/Tim



From gnu.andrew at redhat.com  Wed Dec  2 21:38:15 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 2 Dec 2015 16:38:15 -0500 (EST)
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch
	value	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
Message-ID: <902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com>

snip...

> The new revision does that:
> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/
> 

This has grown a lot from my version.

The main change seems to be in having to handle a ppc64le define
in numerous places, which seems unnecessary as ppc64 is present there.
The version I'm looking at that we used in 8 deliberately avoids this
by forcing ARCH back to ppc64 on ppc64le. Was there a reason not to do that?

The only case where ppc64le is different to ppc64, the ABI is used:

-#if defined(__ia64) || defined(__powerpc__)
+#if defined(__ia64) || (defined(__powerpc__) && !defined(ABI_ELFv2))

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From asmundak at google.com  Wed Dec  2 22:02:35 2015
From: asmundak at google.com (Alexander Smundak)
Date: Wed, 2 Dec 2015 14:02:35 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com>
Message-ID: <CAHQ51u6R6E7a6Li5kBuXWSM8nZZiqtrr8RcQxiJLjUYxMJUR3w@mail.gmail.com>

On Wed, Dec 2, 2015 at 1:38 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> snip...
>
>> The new revision does that:
>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/
>>
> This has grown a lot from my version.
I guess you are referring to the three additional files under hotspot/agent.

> The main change seems to be in having to handle a ppc64le define
> in numerous places, which seems unnecessary as ppc64 is present there.
> The version I'm looking at that we used in 8 deliberately avoids this
> by forcing ARCH back to ppc64 on ppc64le. Was there a reason not to do that?
I think fiddling with ARCH is fragile. IMHO it's easier to have ppc64le checked
explicitly in the agent.


From gnu.andrew at redhat.com  Wed Dec  2 22:18:54 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 2 Dec 2015 17:18:54 -0500 (EST)
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch
	value on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6R6E7a6Li5kBuXWSM8nZZiqtrr8RcQxiJLjUYxMJUR3w@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<902231413.22551266.1449092295615.JavaMail.zimbra@redhat.com>
	<CAHQ51u6R6E7a6Li5kBuXWSM8nZZiqtrr8RcQxiJLjUYxMJUR3w@mail.gmail.com>
Message-ID: <501801523.22574565.1449094734051.JavaMail.zimbra@redhat.com>

----- Original Message -----
> On Wed, Dec 2, 2015 at 1:38 PM, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> > snip...
> >
> >> The new revision does that:
> >> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
> >> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
> >> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/
> >>
> > This has grown a lot from my version.
> I guess you are referring to the three additional files under hotspot/agent.
> 

The extra define patches mainly.

> > The main change seems to be in having to handle a ppc64le define
> > in numerous places, which seems unnecessary as ppc64 is present there.
> > The version I'm looking at that we used in 8 deliberately avoids this
> > by forcing ARCH back to ppc64 on ppc64le. Was there a reason not to do
> > that?
> I think fiddling with ARCH is fragile. IMHO it's easier to have ppc64le
> checked
> explicitly in the agent.
> 

I can see that point.

Ok by me then.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07



From magnus.ihse.bursie at oracle.com  Wed Dec  2 22:59:33 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2015 23:59:33 +0100
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
Message-ID: <565F77D5.7090603@oracle.com>

On 2015-12-01 04:31, Alexander Smundak wrote:
>> On 2015-11-30 05:23, David Holmes wrote:
>>> ..
>>> At the top level if we see ppc64le then we set VAR_CPU to ppc64le instead
>>> of ppc64. However, once we get into hotspot build we want ARCH to be ppc64
>>> again (in hotspot-spec.gmk.in) - why is that?
>>>
>>> Inside hotpot we want:
>>>
>>> SRCARCH := ppc
>>> BUILDARCH := ppc64
>>> LIBARCH := ppc64le
>>>
>>> right? So can ARCH not be ppc64le from the top-level and then we adjust
>>> SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH.
> The new revision does that:
> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/
This version looks good to me.

/Magnus

>
> common/autoconf/hotspot-spec.gmk.in has been left alone, and
> hotspot/make/defs.make sets BUILDARCH and LIBARCH
> (BUILDARCH should be the same for ppc64 and ppc64le because the file
> linux/makefiels/$)BUILDARCH).make is pulled in by vm.make)
> I have also reduced the changeset for hotspot by making
> sun.jvm.hotspot.utilities.PlatformInfo.getCPU() return "ppc64" both
> when
> "os.arch" propertie's value is "ppc64" and "ppc64le".
>
>>> agent/src/os/linux/LinuxDebuggerLocal.c
>>> agent/src/os/linux/libproc.h
>>>
>>> Is it not the case that ppc64le -> ppc64, so that we can avoid "if
>>> defined(ppc64) | defined(ppc64le) ? I would hope that the only places in the
>>> sources where you need to check for ppc64le is where that code differs from
>>> the ppc64 code.
> This is defined as -D$(OPENJDK_TARGET_CPU_LEGACY), but the same variable
> is used in the generated hotspot-spec.gmk file, so I decided it's
> easier to fix the
> SA code.
>
>>> src/share/vm/runtime/vm_version.cpp
>>>
>>> I think this messy code block relates to builds where CPU is not set -
>>> which should never be the case these days. Maybe just put in a check "ifndef
>>> CPU -> error" ?
>> I agree. There might be a case for handling zero, though. If I remember
>> correctly the hotspot build might not set CPU, or set it incorrectly, when
>> building zero. (Then again, zero is a strange beast, a mix between a variant
>> and a platform...)
> I have listed platform-specific options for building Hotspot above,
> but here's the full command line to build vm_version.o for ppc64le:
>
> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
> -I<JDK9>/hotspot/src/share/vm/prims -I<JDK9>/hotspot/src/share/vm
> -I<JDK9>/hotspot/src/share/vm/precompiled
> -I<JDK9>/hotspot/src/cpu/ppc/vm
> -I<JDK9>/hotspot/src/os_cpu/linux_ppc/vm
> -I<JDK9>/hotspot/src/os/linux/vm -I<JDK9>/hotspot/src/os/posix/vm
> -I../generated -DHOTSPOT_BUILD_USER="\"asmundak\""
> -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
> -DHOTSPOT_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\""
> -DJRE_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\""
> -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\""
> -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"b00\""
> -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
> -DTARGET_COMPILER_gcc -DCOMPILER2 -DINCLUDE_JVMCI=0 -fPIC -fno-rtti
> -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64
> -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3   -g -D_LP64=1
> -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8
> -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror
> -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
> -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual
> -Wtype-limits -Wno-format-zero-length -Wuninitialized   -c -MMD -MP
> -MF ../generated/dependencies/vm_version.o.d -fpch-deps -o
> vm_version.o <JDK9>/hotspot/src/share/vm/runtime/vm_version.cpp
> (I have replaced the actual path to the source tree with <JDK9>)
>
> Preprocessor variable 'CPU' is not defined on the command line, and if I add
> #error CPU is not defined
> right after
> #fndef CPU
> on line 193 in vm_version.cpp,
> it will fail to compile at least on Linux ppc64le and Linux x86_64.
>
>> I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is defined
>> to ppc for both ppc64 and the new ppc64le platform, that it, it explicitely
>> excludes address size. I think it's reasonable that it excludes endianness
>> as well, but we have not really had to make that discussion before. In any
>> case, it should not contain "64", otherwise the value will be "ppc" for
>> ppc64 and "ppc64le" for ppc64le, and that's just plain wrong.
> With the proposed patches the generated spec.gmk will contain
>     OPENJDK_TARGET_CPU_OSARCH:=ppc64le
> when building JDK for the little endian and ppc64 for the big endian.
> "os.arch" property is set from ARCHPROPNAME preprocessor variable,
> whose value is $(OPENJDK_TARGET_CPU_ARCH). Did I misunderstand
> something?



From martinrb at google.com  Wed Dec  2 23:59:08 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 2 Dec 2015 15:59:08 -0800
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <565D6E93.8000603@oracle.com>
References: <565D6E93.8000603@oracle.com>
Message-ID: <CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>

Not to say you shouldn't do this, but I worry that increasingly computing
is being done in "containers" where e.g. the number of cpus is doubling
every year but only a small number are available to actually be used by a
given process.  if availableProcessors reports 1 million, what should we
do?  (no need to answer...)

On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello,
>
> The current heuristic for figuring out what to default set the -j flag to
> make needs some tweaking.
>
> In JDK 9, it looks at the amount of memory and the number of cpus in the
> system. It divides memory by 1024 to get a safe number of jobs that will
> fit into memory. The lower of that number and the number of cpus is then
> picked. The number is then scaled down to about 90% of the number of cpus
> to leave some resources for other activities. It is also capped at 16.
>
> Since we now have the build using "nice" to make sure the build isn't
> bogging down the system, I see no reason to do the 90% scaling anymore.
> Also, the performance issues that forced us to cap at 16 have long been
> fixed, and even if we don't scale well beyond 16, we do still scale. So I
> propose we remove that arbitrary limitation too.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>
> /Erik
>


From roger.riggs at oracle.com  Thu Dec  3 02:11:57 2015
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 2 Dec 2015 21:11:57 -0500
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
Message-ID: <565FA4ED.8080904@oracle.com>

Hi,

It would be useful to figure out the number of cpus available when in a 
container.
Some comments have added to:
8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793> 
getAvailableProcessors may incorrectly report the number of cpus in 
Docker container

But so far we haven't dug deep enough.   Suggestions are welcome?

Roger


On 12/2/15 6:59 PM, Martin Buchholz wrote:
> Not to say you shouldn't do this, but I worry that increasingly computing
> is being done in "containers" where e.g. the number of cpus is doubling
> every year but only a small number are available to actually be used by a
> given process.  if availableProcessors reports 1 million, what should we
> do?  (no need to answer...)
>
> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson <erik.joelsson at oracle.com>
> wrote:
>
>> Hello,
>>
>> The current heuristic for figuring out what to default set the -j flag to
>> make needs some tweaking.
>>
>> In JDK 9, it looks at the amount of memory and the number of cpus in the
>> system. It divides memory by 1024 to get a safe number of jobs that will
>> fit into memory. The lower of that number and the number of cpus is then
>> picked. The number is then scaled down to about 90% of the number of cpus
>> to leave some resources for other activities. It is also capped at 16.
>>
>> Since we now have the build using "nice" to make sure the build isn't
>> bogging down the system, I see no reason to do the 90% scaling anymore.
>> Also, the performance issues that forced us to cap at 16 have long been
>> fixed, and even if we don't scale well beyond 16, we do still scale. So I
>> propose we remove that arbitrary limitation too.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>
>> /Erik
>>



From david.holmes at oracle.com  Thu Dec  3 06:30:30 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Dec 2015 16:30:30 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
Message-ID: <565FE186.7090508@oracle.com>

On 1/12/2015 1:31 PM, Alexander Smundak wrote:
>> On 2015-11-30 05:23, David Holmes wrote:
>>> ..
>>> At the top level if we see ppc64le then we set VAR_CPU to ppc64le instead
>>> of ppc64. However, once we get into hotspot build we want ARCH to be ppc64
>>> again (in hotspot-spec.gmk.in) - why is that?
>>>
>>> Inside hotpot we want:
>>>
>>> SRCARCH := ppc
>>> BUILDARCH := ppc64
>>> LIBARCH := ppc64le
>>>
>>> right? So can ARCH not be ppc64le from the top-level and then we adjust
>>> SRCARCH and BUILDARCH? And avoid the top-level changes to ARCH.
> The new revision does that:
> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03/

Looks good.

> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03

Looks good.

> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03

agent code:

I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and 
-Dppc64le, such that you don't need to check for either being defined ??

---

src/share/vm/runtime/vm_version.cpp

Just a follow up note that I was surprised to see CPU not being set. 
This code needs cleaning up in the future as we definitely do not need 
this additional place that defines architecture names.

Thanks,
David
-----

>
> common/autoconf/hotspot-spec.gmk.in has been left alone, and
> hotspot/make/defs.make sets BUILDARCH and LIBARCH
> (BUILDARCH should be the same for ppc64 and ppc64le because the file
> linux/makefiels/$)BUILDARCH).make is pulled in by vm.make)
> I have also reduced the changeset for hotspot by making
> sun.jvm.hotspot.utilities.PlatformInfo.getCPU() return "ppc64" both
> when
> "os.arch" propertie's value is "ppc64" and "ppc64le".
>
>>>
>>> agent/src/os/linux/LinuxDebuggerLocal.c
>>> agent/src/os/linux/libproc.h
>>>
>>> Is it not the case that ppc64le -> ppc64, so that we can avoid "if
>>> defined(ppc64) | defined(ppc64le) ? I would hope that the only places in the
>>> sources where you need to check for ppc64le is where that code differs from
>>> the ppc64 code.
> This is defined as -D$(OPENJDK_TARGET_CPU_LEGACY), but the same variable
> is used in the generated hotspot-spec.gmk file, so I decided it's
> easier to fix the
> SA code.
>
>>> src/share/vm/runtime/vm_version.cpp
>>>
>>> I think this messy code block relates to builds where CPU is not set -
>>> which should never be the case these days. Maybe just put in a check "ifndef
>>> CPU -> error" ?
>>
>> I agree. There might be a case for handling zero, though. If I remember
>> correctly the hotspot build might not set CPU, or set it incorrectly, when
>> building zero. (Then again, zero is a strange beast, a mix between a variant
>> and a platform...)
>
> I have listed platform-specific options for building Hotspot above,
> but here's the full command line to build vm_version.o for ppc64le:
>
> /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DPPC64 -DPRODUCT -I.
> -I<JDK9>/hotspot/src/share/vm/prims -I<JDK9>/hotspot/src/share/vm
> -I<JDK9>/hotspot/src/share/vm/precompiled
> -I<JDK9>/hotspot/src/cpu/ppc/vm
> -I<JDK9>/hotspot/src/os_cpu/linux_ppc/vm
> -I<JDK9>/hotspot/src/os/linux/vm -I<JDK9>/hotspot/src/os/posix/vm
> -I../generated -DHOTSPOT_BUILD_USER="\"asmundak\""
> -DHOTSPOT_LIB_ARCH=\"ppc64le\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
> -DHOTSPOT_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\""
> -DJRE_RELEASE_VERSION="\"1.9.0-internal-asmundak_2015_11_26_17_11-b00\""
> -DJDK_MAJOR_VERSION="\"1\"" -DJDK_MINOR_VERSION="\"9\""
> -DJDK_MICRO_VERSION="\"0\"" -DJDK_BUILD_NUMBER="\"b00\""
> -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_ppc -DTARGET_ARCH_MODEL_ppc_64
> -DTARGET_OS_ARCH_linux_ppc -DTARGET_OS_ARCH_MODEL_linux_ppc_64
> -DTARGET_COMPILER_gcc -DCOMPILER2 -DINCLUDE_JVMCI=0 -fPIC -fno-rtti
> -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64
> -pipe -fno-strict-aliasing -fno-omit-frame-pointer -O3   -g -D_LP64=1
> -DVM_LITTLE_ENDIAN -DABI_ELFv2 -mcpu=power7 -mtune=power8
> -minsert-sched-nops=regroup_exact -mno-multiple -mno-string -Werror
> -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
> -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual
> -Wtype-limits -Wno-format-zero-length -Wuninitialized   -c -MMD -MP
> -MF ../generated/dependencies/vm_version.o.d -fpch-deps -o
> vm_version.o <JDK9>/hotspot/src/share/vm/runtime/vm_version.cpp
> (I have replaced the actual path to the source tree with <JDK9>)
>
> Preprocessor variable 'CPU' is not defined on the command line, and if I add
> #error CPU is not defined
> right after
> #fndef CPU
> on line 193 in vm_version.cpp,
> it will fail to compile at least on Linux ppc64le and Linux x86_64.
>
>> I also think something's very weird here. OPENJDK_TARGET_CPU_ARCH is defined
>> to ppc for both ppc64 and the new ppc64le platform, that it, it explicitely
>> excludes address size. I think it's reasonable that it excludes endianness
>> as well, but we have not really had to make that discussion before. In any
>> case, it should not contain "64", otherwise the value will be "ppc" for
>> ppc64 and "ppc64le" for ppc64le, and that's just plain wrong.
> With the proposed patches the generated spec.gmk will contain
>     OPENJDK_TARGET_CPU_OSARCH:=ppc64le
> when building JDK for the little endian and ppc64 for the big endian.
> "os.arch" property is set from ARCHPROPNAME preprocessor variable,
> whose value is $(OPENJDK_TARGET_CPU_ARCH). Did I misunderstand
> something?
>


From david.holmes at oracle.com  Thu Dec  3 06:51:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Dec 2015 16:51:49 +1000
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <565C5E91.5050102@gmail.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
Message-ID: <565FE685.4020601@oracle.com>

On 1/12/2015 12:34 AM, Yasumasa Suenaga wrote:
> Hi Magnus,
>
> I've uploaded new webrev:
>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.05/

common/autoconf/jdk-options.m4

Can you reinstate the comment:

  581   # This must be done after the toolchain is setup, since we're 
looking at objcopy.

as this constraint still exists.

It would be nice if the external and zipped cases could somehow be 
shared so that we don't have to duplicate everything just to alter the 
value of a single variable.

  634   # --enable-zip-debug-info is deprecated.
  635   # Please use --with-debug-symbols=zipped .
  636   BASIC_DEPRECATED_ARG_ENABLE(zip-debug-info, zip_debug_info)

I would have hoped that the deprecation macro enabled you to inform the 
user what the replacement is as per the comments! This seems 
unsatisfactory. :(

I'm assuming there is no change to the default behaviour if none of 
these options are specified. I'm unclear whether we will need to 
coordinate this change with any internal processes that might explicitly 
be using the deprecated options - I think Magnus should have a better 
idea about that.

Thanks,
David
-----

>> If we do implement this flag, it should work as expected. If you
>> believe this is too hard to get right, I'm alright with fixing this as
>> a separate bug.
>
> Okay, I removed --enable-java-debug-symbols in this webrev.
> I will file to JBS and try to create patch for it after this issue.
>
>
>> That is, have you tried building with the four different values of
>> --with-native-debug-symbols and verified that the result is indeed as
>> you specified?
>
> Of course, I've checked all pattern of --with-native-debug-symbols.
> I ran readelf -S for libjvm, libnio, libsaproc, and java command.
> I checked debug section (.debug_info, and more) in ELF binaries.
>
>
>> Just by my quick glance I can already spot what I believe is a
>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>> reasonably be no_strip.
>
> I've fixed in this webrev.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/11/30 21:26, Magnus Ihse Bursie wrote:
>>
>>
>> On 2015-11-26 15:19, Yasumasa Suenaga wrote:
>>> I uploaded a new webrev:
>>>   http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/
>>>
>>> I implemented --with-native-debug-symbols and
>>> --enable-java-debug-symbols in it.
>>> And I deprecated --enable-debug-symbols and --enable-zip-debug-info .
>>
>> Hi Yasumasa,
>>
>> I apologize I have not been able to spend more time on this. I still
>> only had time to take a short glimpse, but I found a few issues anyway.
>>
>> First, the new -enable-java-debug-symbols is problematic. If you build
>> with "--enable-debug --disable-java-debug-symbols", then this implies
>> that you would get a build without java debug symbols. However, this
>> will not happen, since changing debug level wil enable java debug
>> symbols, but the new java-debug-symbols flag will not manage to
>> disable this.
>>
>> If we do implement this flag, it should work as expected. If you
>> believe this is too hard to get right, I'm alright with fixing this as
>> a separate bug.
>>
>> Second, all the flags we use to manage this internally makes me
>> nervous. :) Are you sure you're getting them right? That is, have you
>> tried building with the four different values of
>> --with-native-debug-symbols and verified that the result is indeed as
>> you specified? You'd need to check both libjvm.so and at least a jdk
>> library, like libjava.so or so, since they use different build system
>> and flags.
>>
>> Just by my quick glance I can already spot what I believe is a
>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>> reasonably be no_strip. (I'd be surprised if strip was run if I
>> compiled without debug symbols).
>>
>> Other than that, I believe this patch is starting to get ready.
>>
>> /Magnus
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2015/11/25 23:52, Yasumasa Suenaga wrote:
>>>> Hi Magnus,
>>>>
>>>>> --with-java-debug-symbols=none,all
>>>>> (or "none,internal" for consistency).
>>>>
>>>> Can I change this option to --enable-java-debug-symbols ?
>>>> This value set to none or all. So I think that we should use
>>>> AC_ARG_ENABLE for it.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2015/11/25 23:35, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-21 14:12, Yasumasa Suenaga wrote:
>>>>>>> My point with current proposal is that either it doesn't touch
>>>>>>> the zipping because we already have an option for that; or it
>>>>>>> should deprecate the existing option (now Erik has pointed out
>>>>>>> that capability).
>>>>>>
>>>>>> I'm using BASIC_DEPRECATED_ARG_ENABLE for debug-symbols and
>>>>>> zip-debug-info in new webrev:
>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.03/
>>>>>>
>>>>>> I had thought this new option as a wrapper for existing options.
>>>>>> However, if current options should be deprecated, I will follow it.
>>>>>
>>>>> Hi Yasumasa,
>>>>>
>>>>> Sorry for the delay in my response.
>>>>>
>>>>> I had to go back and re-read the old discussions and my personal
>>>>> notes about this. It turned out that some of the complications that
>>>>> existed then is not relevant from Oracle's point of view anymore
>>>>> (more specifically, stripping to several distinct levels). With
>>>>> that complication gone, the basic case boils down to the three ways
>>>>> of doing this:
>>>>> 1) Compile without debug information ("none")
>>>>> 2) Compile with debug information and keep it ("internal")
>>>>> 3) Compile with debug information, copy it to an external file, and
>>>>> strip the binary ("external")
>>>>>
>>>>> So far, so good. I agree with David Holmes that the zipping
>>>>> complicates things somewhat. The problem here is two-fold: Firstly,
>>>>> I believe that the "external" choice will be relevant to nobody (as
>>>>> in, neither the community nor Oracle), and secondly, there have
>>>>> been discussions of handling the external debuginfo differently
>>>>> (namely, to move all debug info, unzipped, into a separate image,
>>>>> and zip them all at once). It's a bit unfortunate if we create an
>>>>> interface to configure that cannot grow properly with future changes.
>>>>>
>>>>> On the other hand, it does seem convenient to express the end
>>>>> result for the Oracle build as "zipped" (or possibly
>>>>> "external-zipped", to emphasize  the connection to "external"?).
>>>>>
>>>>> So I'm not sure what to think myself. But if David agrees that
>>>>> adding "zipped" (or "external-zipped") to the new argument, and
>>>>> deprecating the old, then I agree with it as well. :-)
>>>>>
>>>>> The second discussion here is the connection between java and
>>>>> native debug symbols.
>>>>>
>>>>> Fact: We do not currently have a story for setting java debug
>>>>> symbols. That's bad, and a regression as pointed out.
>>>>> Fact: That does not mean it has to be fixed in this patch.
>>>>>
>>>>> I do think that java and native debug symbols are different things
>>>>> and should be treated differently. But I also think we should have
>>>>> configure arguments that show their similarity. So, I propose that
>>>>> we have a
>>>>> --with-native-debug-symbols=none,internal,external,zipped
>>>>> as you propose, and then also a
>>>>> --with-java-debug-symbols=none,all
>>>>> (or "none,internal" for consistency).
>>>>>
>>>>> I think it would be nice if that flag could be implemented in the
>>>>> same patch, but since it is a different thing I understand if you
>>>>> want to leave it out. There is some added complication here, since
>>>>> we already set -g for java compilation depending on debug level,
>>>>> and the native debug symbol patch is obviously tricky as it is.
>>>>>
>>>>> /Magnus
>>


From david.holmes at oracle.com  Thu Dec  3 07:15:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Dec 2015 17:15:00 +1000
Subject: Running native code test
In-Reply-To: <CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>
References: <CAP_pwnW8S_yuFQgbbuP3S9AMo9c6uag7u9ZN1RsEtwH9k=uvQg@mail.gmail.com>
	<565CCAE4.2080905@oracle.com>
	<CAP_pwnXBerMzSG8aH6cU=AQ4wR7oSqN-CSgcgyZXMeE6YtQLqQ@mail.gmail.com>
	<565D4BA5.2030704@oracle.com>
	<CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>
Message-ID: <565FEBF4.7070506@oracle.com>

cc'ing build-dev

On 2/12/2015 1:28 AM, Carsten Varming wrote:
> Dear David,
>
> See inline.
>
> On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Carsten,
>
>     On 1/12/2015 8:21 AM, Carsten Varming wrote:
>
>         Dear Ioi,
>
>         Absolutely,
>
>         diff -r 7606b8556225 test/Makefile
>         --- a/test/Makefile     Thu Nov 26 13:13:03 2015 +0100
>         +++ b/test/Makefile     Mon Nov 30 17:20:30 2015 -0500
>         @@ -156,7 +156,7 @@
>              TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
>            endif
>            ifdef TESTNATIVE_DIR
>         -  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>         "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>         +  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>         "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
>            endif
>
>
>     In hotspot/make/test/JtregNative.gmk we have:
>
>     BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
>     $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native
>
>
> The SetupTestFilesCompilation macro adds the subdirectory "lib" to the
> path such that the ".so" files (or ".dylib" files) end up in
> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native/lib.

Thanks for that. Tracing through these makefile macros is far too 
painful. I wish there were some way to see what they looked like once 
expanded.

>     so the above patch should not be needed.
>
>
> Without the patch the following sequence of commands fails:
> sh configure --enable-debug
> make images
> make build-test-hotspot-jtreg-native
> cd hotspot/test
> make TESTDIRS=runtime/SameObject
> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
> PRODUCT_HOME=$JAVA_HOME jtreg_tests
>
> TEST RESULT: Failed. Execution failed: `main' threw exception:
> java.lang.UnsatisfiedLinkError: no SameObject in java.library.path
>
> and java.library.path is defined
> by: -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native

What I see in a JPRT build is simply:

(cd /scratch/hotspot/make/test && make  -r -R -I /scratch/make/common 
SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk 
MAKE_LOG_FLAGS="" LOG_LEVEL=debug -f JtregNative.gmk \
     test-image-hotspot-jtreg-native)

>
> On the other hand, with the patch the test runs fine. Looking at
> SameObject.jtr I can
> see: -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib,
> i.e., "/lib" is appended to the path and the test pass.
>
> So I wonder, are these tests run by JPRT? And if they are, then what I
> am doing wrong?

Yes they are run (or some subset thereof). The -nativepath that gets 
passed to jtreg does not include a lib component.

I'm afraid I don't know what is going wrong.

David
-----

> BTW. This paths above are taken from runs on my mac. The problem also
> occurs on my Linux desktop.
>
> Carsten
>
>     David
>     -----
>
>
>
>
>            # Expect JPRT to set JPRT_ARCHIVE_BUNDLE (path to zip bundle
>         for results)
>
>         Carsten
>
>         On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi.lam at oracle.com
>         <mailto:ioi.lam at oracle.com>> wrote:
>
>             Your patch seems to have been stripped by the mailer. Is it
>             possible to
>             just include it as plain text in the e-mail?
>
>             Thanks
>             - Ioi
>
>
>             On 11/30/15 1:34 PM, Carsten Varming wrote:
>
>                 Hi everyone,
>
>                 I was recently trying to run some tests that use native
>                 code, e.g.,
>                 hotspot/runtime/SameObject/SameObject.java and found
>                 that I had to apply
>                 the attached diff to get the tests to work.
>
>                 I am doing something wrong or is this a trivial bug?
>
>                 Carsten
>
>
>
>


From erik.joelsson at oracle.com  Thu Dec  3 10:08:54 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 3 Dec 2015 11:08:54 +0100
Subject: Running native code test
In-Reply-To: <565FEBF4.7070506@oracle.com>
References: <CAP_pwnW8S_yuFQgbbuP3S9AMo9c6uag7u9ZN1RsEtwH9k=uvQg@mail.gmail.com>
	<565CCAE4.2080905@oracle.com>
	<CAP_pwnXBerMzSG8aH6cU=AQ4wR7oSqN-CSgcgyZXMeE6YtQLqQ@mail.gmail.com>
	<565D4BA5.2030704@oracle.com>
	<CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>
	<565FEBF4.7070506@oracle.com>
Message-ID: <566014B6.1020100@oracle.com>



On 2015-12-03 08:15, David Holmes wrote:
>
> Thanks for that. Tracing through these makefile macros is far too 
> painful. I wish there were some way to see what they looked like once 
> expanded.
>
In the debug log, you get the calls to each macro listed, which can help 
to see how it was actually called. This can of course be trashed by 
concurrency. Running with make 4.0 or later and enabling 
--with-output-sync helps with that part.

Finally, if you really want to investigate a particular macro call, you 
can set DEBUG_foo=true, where foo is the first parameter in the macro, 
for example BUILD_LIBJAVA. That will print the whole expanded contents 
of the macro call before being eval:ed.

/Erik


From dmitry.samersoff at oracle.com  Thu Dec  3 13:53:44 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 3 Dec 2015 16:53:44 +0300
Subject: RFR(XS): JDK-8114853 variable tracking size limit exceeded in
	vmStructs.cpp
In-Reply-To: <564DB97A.5020505@oracle.com>
References: <564DB97A.5020505@oracle.com>
Message-ID: <56604968.5090703@oracle.com>

Everybody,

I'd followed common opinion and turn off tracking of variable assignment
for vmStructs file only.

Updated webrev is here:

http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.02/

-Dmitry

On 2015-11-19 14:58, Dmitry Samersoff wrote:
> Everybody,
> 
> Please review:
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.01/
> 
> Story:
> 
> VTA fails on huge VMStructs::init() so this method is being compiled twice.
> 
> VTA[1] allows compiler to emit DWARF-3 debugging information for local
> variable ever if this variable is optimized out at the cost of
> compilation time and compiler memory consumption.
> 
> So I decided to turn it off for entire hotspot build to reduce memory
> footprint/increase compilation speed.
> 
> 1. https://gcc.gnu.org/wiki/Var_Tracking_Assignments
> 
> -Dmitry
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From yasuenag at gmail.com  Thu Dec  3 14:14:22 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 3 Dec 2015 23:14:22 +0900
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <565FE685.4020601@oracle.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
	<565FE685.4020601@oracle.com>
Message-ID: <56604E3E.80303@gmail.com>

Hi David,

> Can you reinstate the comment:
>
>   581   # This must be done after the toolchain is setup, since we're looking at objcopy.
>
> as this constraint still exists.

I will reinstate it.


> It would be nice if the external and zipped cases could somehow be shared so that we don't have to duplicate everything just to alter the value of a single variable.

I guess that it is difficult.
For example, ZIP_DEBUGINFO_FILES is used by many makefiles in hotspot, ENABLE_DEBUG_SYMBOLS
is used in jdk.
Variables which are used in this patch are used in many makefiles.
So we have to work for big refactoring if we do that.

Thus, I want to use them to make simple.


>   634   # --enable-zip-debug-info is deprecated.
>   635   # Please use --with-debug-symbols=zipped .
>   636   BASIC_DEPRECATED_ARG_ENABLE(zip-debug-info, zip_debug_info)
>
> I would have hoped that the deprecation macro enabled you to inform the user what the replacement is as per the comments! This seems unsatisfactory. :(

Currently, we cannot pass any message to BASIC_DEPRECATED_ARG_ENABLE (and BASIC_DEPRECATED_ARG_WITH).
Thus we have to change them if we want to inform to user.

It is out of scope of this enhancement.
Should I file it as another issue?


> I'm assuming there is no change to the default behaviour if none of these options are specified.

Yes. Default behavior is zipped.


Thanks,

Yasumasa


On 2015/12/03 15:51, David Holmes wrote:
> On 1/12/2015 12:34 AM, Yasumasa Suenaga wrote:
>> Hi Magnus,
>>
>> I've uploaded new webrev:
>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.05/
>
> common/autoconf/jdk-options.m4
>
> Can you reinstate the comment:
>
>   581   # This must be done after the toolchain is setup, since we're looking at objcopy.
>
> as this constraint still exists.
>
> It would be nice if the external and zipped cases could somehow be shared so that we don't have to duplicate everything just to alter the value of a single variable.
>
>   634   # --enable-zip-debug-info is deprecated.
>   635   # Please use --with-debug-symbols=zipped .
>   636   BASIC_DEPRECATED_ARG_ENABLE(zip-debug-info, zip_debug_info)
>
> I would have hoped that the deprecation macro enabled you to inform the user what the replacement is as per the comments! This seems unsatisfactory. :(
>
> I'm assuming there is no change to the default behaviour if none of these options are specified. I'm unclear whether we will need to coordinate this change with any internal processes that might explicitly be using the deprecated options - I think Magnus should have a better idea about that.
>
> Thanks,
> David
> -----
>
>>> If we do implement this flag, it should work as expected. If you
>>> believe this is too hard to get right, I'm alright with fixing this as
>>> a separate bug.
>>
>> Okay, I removed --enable-java-debug-symbols in this webrev.
>> I will file to JBS and try to create patch for it after this issue.
>>
>>
>>> That is, have you tried building with the four different values of
>>> --with-native-debug-symbols and verified that the result is indeed as
>>> you specified?
>>
>> Of course, I've checked all pattern of --with-native-debug-symbols.
>> I ran readelf -S for libjvm, libnio, libsaproc, and java command.
>> I checked debug section (.debug_info, and more) in ELF binaries.
>>
>>
>>> Just by my quick glance I can already spot what I believe is a
>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>> reasonably be no_strip.
>>
>> I've fixed in this webrev.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/11/30 21:26, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2015-11-26 15:19, Yasumasa Suenaga wrote:
>>>> I uploaded a new webrev:
>>>>   http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/
>>>>
>>>> I implemented --with-native-debug-symbols and
>>>> --enable-java-debug-symbols in it.
>>>> And I deprecated --enable-debug-symbols and --enable-zip-debug-info .
>>>
>>> Hi Yasumasa,
>>>
>>> I apologize I have not been able to spend more time on this. I still
>>> only had time to take a short glimpse, but I found a few issues anyway.
>>>
>>> First, the new -enable-java-debug-symbols is problematic. If you build
>>> with "--enable-debug --disable-java-debug-symbols", then this implies
>>> that you would get a build without java debug symbols. However, this
>>> will not happen, since changing debug level wil enable java debug
>>> symbols, but the new java-debug-symbols flag will not manage to
>>> disable this.
>>>
>>> If we do implement this flag, it should work as expected. If you
>>> believe this is too hard to get right, I'm alright with fixing this as
>>> a separate bug.
>>>
>>> Second, all the flags we use to manage this internally makes me
>>> nervous. :) Are you sure you're getting them right? That is, have you
>>> tried building with the four different values of
>>> --with-native-debug-symbols and verified that the result is indeed as
>>> you specified? You'd need to check both libjvm.so and at least a jdk
>>> library, like libjava.so or so, since they use different build system
>>> and flags.
>>>
>>> Just by my quick glance I can already spot what I believe is a
>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>> reasonably be no_strip. (I'd be surprised if strip was run if I
>>> compiled without debug symbols).
>>>
>>> Other than that, I believe this patch is starting to get ready.
>>>
>>> /Magnus
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2015/11/25 23:52, Yasumasa Suenaga wrote:
>>>>> Hi Magnus,
>>>>>
>>>>>> --with-java-debug-symbols=none,all
>>>>>> (or "none,internal" for consistency).
>>>>>
>>>>> Can I change this option to --enable-java-debug-symbols ?
>>>>> This value set to none or all. So I think that we should use
>>>>> AC_ARG_ENABLE for it.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2015/11/25 23:35, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-21 14:12, Yasumasa Suenaga wrote:
>>>>>>>> My point with current proposal is that either it doesn't touch
>>>>>>>> the zipping because we already have an option for that; or it
>>>>>>>> should deprecate the existing option (now Erik has pointed out
>>>>>>>> that capability).
>>>>>>>
>>>>>>> I'm using BASIC_DEPRECATED_ARG_ENABLE for debug-symbols and
>>>>>>> zip-debug-info in new webrev:
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.03/
>>>>>>>
>>>>>>> I had thought this new option as a wrapper for existing options.
>>>>>>> However, if current options should be deprecated, I will follow it.
>>>>>>
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> Sorry for the delay in my response.
>>>>>>
>>>>>> I had to go back and re-read the old discussions and my personal
>>>>>> notes about this. It turned out that some of the complications that
>>>>>> existed then is not relevant from Oracle's point of view anymore
>>>>>> (more specifically, stripping to several distinct levels). With
>>>>>> that complication gone, the basic case boils down to the three ways
>>>>>> of doing this:
>>>>>> 1) Compile without debug information ("none")
>>>>>> 2) Compile with debug information and keep it ("internal")
>>>>>> 3) Compile with debug information, copy it to an external file, and
>>>>>> strip the binary ("external")
>>>>>>
>>>>>> So far, so good. I agree with David Holmes that the zipping
>>>>>> complicates things somewhat. The problem here is two-fold: Firstly,
>>>>>> I believe that the "external" choice will be relevant to nobody (as
>>>>>> in, neither the community nor Oracle), and secondly, there have
>>>>>> been discussions of handling the external debuginfo differently
>>>>>> (namely, to move all debug info, unzipped, into a separate image,
>>>>>> and zip them all at once). It's a bit unfortunate if we create an
>>>>>> interface to configure that cannot grow properly with future changes.
>>>>>>
>>>>>> On the other hand, it does seem convenient to express the end
>>>>>> result for the Oracle build as "zipped" (or possibly
>>>>>> "external-zipped", to emphasize  the connection to "external"?).
>>>>>>
>>>>>> So I'm not sure what to think myself. But if David agrees that
>>>>>> adding "zipped" (or "external-zipped") to the new argument, and
>>>>>> deprecating the old, then I agree with it as well. :-)
>>>>>>
>>>>>> The second discussion here is the connection between java and
>>>>>> native debug symbols.
>>>>>>
>>>>>> Fact: We do not currently have a story for setting java debug
>>>>>> symbols. That's bad, and a regression as pointed out.
>>>>>> Fact: That does not mean it has to be fixed in this patch.
>>>>>>
>>>>>> I do think that java and native debug symbols are different things
>>>>>> and should be treated differently. But I also think we should have
>>>>>> configure arguments that show their similarity. So, I propose that
>>>>>> we have a
>>>>>> --with-native-debug-symbols=none,internal,external,zipped
>>>>>> as you propose, and then also a
>>>>>> --with-java-debug-symbols=none,all
>>>>>> (or "none,internal" for consistency).
>>>>>>
>>>>>> I think it would be nice if that flag could be implemented in the
>>>>>> same patch, but since it is a different thing I understand if you
>>>>>> want to leave it out. There is some added complication here, since
>>>>>> we already set -g for java compilation depending on debug level,
>>>>>> and the native debug symbol patch is obviously tricky as it is.
>>>>>>
>>>>>> /Magnus
>>>


From erik.joelsson at oracle.com  Thu Dec  3 15:27:41 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 3 Dec 2015 16:27:41 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
Message-ID: <56605F6D.3030103@oracle.com>

Hello,

This patch adds support for a new Oracle internal tool that will help us 
manage build configurations. I doubt it could be of any use to outside 
users, except perhaps to give a bit of insight into what versions of 
certain dependencies we use internally, as those will be specified in 
the jab-profiles.js configuration file.

In addition to the JAB configuration files added here, I've also added a 
new configure option --with-default-make-target with which you can 
change the default make target for a configuration. A bug is fixed in 
the configure wrapper script where it's currently not propagating the 
return value of configure. Finally a new make command line variable is 
added, CONF_NAME, which works like CONF, except it only matches exact 
configuration names.

Bug: https://bugs.openjdk.java.net/browse/JDK-8136782
Webrev: http://cr.openjdk.java.net/~erikj/8136782/webrev.top.01/

/Erik


From mikael.gerdin at oracle.com  Thu Dec  3 15:39:27 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 3 Dec 2015 16:39:27 +0100
Subject: RFR(XS): JDK-8114853 variable tracking size limit exceeded in
	vmStructs.cpp
In-Reply-To: <56604968.5090703@oracle.com>
References: <564DB97A.5020505@oracle.com> <56604968.5090703@oracle.com>
Message-ID: <5660622F.8050808@oracle.com>

Hi Dmitry,

On 2015-12-03 14:53, Dmitry Samersoff wrote:
> Everybody,
>
> I'd followed common opinion and turn off tracking of variable assignment
> for vmStructs file only.
>
> Updated webrev is here:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.02/

Looks good to me.
/Mikael

>
> -Dmitry
>
> On 2015-11-19 14:58, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.01/
>>
>> Story:
>>
>> VTA fails on huge VMStructs::init() so this method is being compiled twice.
>>
>> VTA[1] allows compiler to emit DWARF-3 debugging information for local
>> variable ever if this variable is optimized out at the cost of
>> compilation time and compiler memory consumption.
>>
>> So I decided to turn it off for entire hotspot build to reduce memory
>> footprint/increase compilation speed.
>>
>> 1. https://gcc.gnu.org/wiki/Var_Tracking_Assignments
>>
>> -Dmitry
>>
>
>



From thomas.schatzl at oracle.com  Thu Dec  3 15:48:38 2015
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 03 Dec 2015 16:48:38 +0100
Subject: RFR(XS): JDK-8114853 variable tracking size limit exceeded in
	vmStructs.cpp
In-Reply-To: <56604968.5090703@oracle.com>
References: <564DB97A.5020505@oracle.com> <56604968.5090703@oracle.com>
Message-ID: <1449157718.2385.40.camel@oracle.com>

Hi,

On Thu, 2015-12-03 at 16:53 +0300, Dmitry Samersoff wrote:
> Everybody,
> 
> I'd followed common opinion and turn off tracking of variable assignment
> for vmStructs file only.
> 
> Updated webrev is here:
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8114853/webrev.02/

  looks good. Thanks.

Thomas



From varming at gmail.com  Thu Dec  3 17:13:16 2015
From: varming at gmail.com (Carsten Varming)
Date: Thu, 3 Dec 2015 12:13:16 -0500
Subject: Running native code test
In-Reply-To: <565FEBF4.7070506@oracle.com>
References: <CAP_pwnW8S_yuFQgbbuP3S9AMo9c6uag7u9ZN1RsEtwH9k=uvQg@mail.gmail.com>
	<565CCAE4.2080905@oracle.com>
	<CAP_pwnXBerMzSG8aH6cU=AQ4wR7oSqN-CSgcgyZXMeE6YtQLqQ@mail.gmail.com>
	<565D4BA5.2030704@oracle.com>
	<CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>
	<565FEBF4.7070506@oracle.com>
Message-ID: <CAP_pwnVgiFW5aSZGhkD4F8NVw_L7wgsOTXgtB7nY8adnYD3DXw@mail.gmail.com>

Dear David,

I think I finally understand what is going on now. :)

The command "make build-test-hotspot-jtreg-native" populates
$(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ with ".so" files using
sub-directories of $(OUTPUTDIR)/support/test/hotspot/jtreg/native/support/
as scratch space for each test.

The command "make test-image-hotspot-jtreg-native" (which I didn't run in
my sequence of commands above) copies all files
in $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/
to $(OUTPUTDIR)/images/test/hotspot/jtreg/native/ . Notice the lacking
"/lib" in the target.

Jtreg is passed the parameter
"-nativepath:$(TESTNATIVE_DIR)/hotspot/jtreg/native". Jtreg then use the
native path to set both system properties: test.nativepath and
java.library.path.

This leaves a lot to be desired. Jtreg expects all library files and
executables to be in the same directory (there are no executables in the
hotspot tests, but the jdk contains one). There is separation between
libraries and executables everywhere except
in $(OUTPUTDIR)/images/test/{hotspot,jdk}/jtreg/native/ because jtreg and
jdk/test/native_sanity/simplenativelauncher/ProgramTest.java expect
executables to be in the same directory as libraries. I have never seen
that before. Notice that this makes the step copying the executables into
the images sub-directory mandatory.

The right thing seems to be to fix jtreg to maintain separation. Something
as simple as setting java.library.path to test.nativepath + "/lib" and
force a standard layout with bin and lib sub-directories would be an
improvement. Perhaps even extend jtreg it to allow separation between
libraries and executables from different tests (test A should not have
access to libraries from test B).

I will drop this issue now that I have a way to execute tests containing
native code, but it would be nice if someone working on jtreg would make it
possible keep executables separate from libraries.

Carsten

On Thu, Dec 3, 2015 at 2:15 AM, David Holmes <david.holmes at oracle.com>
wrote:

> cc'ing build-dev
>
> On 2/12/2015 1:28 AM, Carsten Varming wrote:
>
>> Dear David,
>>
>> See inline.
>>
>> On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Carsten,
>>
>>     On 1/12/2015 8:21 AM, Carsten Varming wrote:
>>
>>         Dear Ioi,
>>
>>         Absolutely,
>>
>>         diff -r 7606b8556225 test/Makefile
>>         --- a/test/Makefile     Thu Nov 26 13:13:03 2015 +0100
>>         +++ b/test/Makefile     Mon Nov 30 17:20:30 2015 -0500
>>         @@ -156,7 +156,7 @@
>>              TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
>>            endif
>>            ifdef TESTNATIVE_DIR
>>         -  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>         "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>>         +  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>         "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
>>            endif
>>
>>
>>     In hotspot/make/test/JtregNative.gmk we have:
>>
>>     BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
>>     $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native
>>
>>
>> The SetupTestFilesCompilation macro adds the subdirectory "lib" to the
>> path such that the ".so" files (or ".dylib" files) end up in
>> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native/lib.
>>
>
> Thanks for that. Tracing through these makefile macros is far too painful.
> I wish there were some way to see what they looked like once expanded.
>
>     so the above patch should not be needed.
>>
>>
>> Without the patch the following sequence of commands fails:
>> sh configure --enable-debug
>> make images
>> make build-test-hotspot-jtreg-native
>> cd hotspot/test
>> make TESTDIRS=runtime/SameObject
>>
>> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
>> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
>> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
>> PRODUCT_HOME=$JAVA_HOME jtreg_tests
>>
>> TEST RESULT: Failed. Execution failed: `main' threw exception:
>> java.lang.UnsatisfiedLinkError: no SameObject in java.library.path
>>
>> and java.library.path is defined
>> by:
>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native
>>
>
> What I see in a JPRT build is simply:
>
> (cd /scratch/hotspot/make/test && make  -r -R -I /scratch/make/common
> SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk
> MAKE_LOG_FLAGS="" LOG_LEVEL=debug -f JtregNative.gmk \
>     test-image-hotspot-jtreg-native)
>
>
>> On the other hand, with the patch the test runs fine. Looking at
>> SameObject.jtr I can
>> see:
>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib,
>> i.e., "/lib" is appended to the path and the test pass.
>>
>> So I wonder, are these tests run by JPRT? And if they are, then what I
>> am doing wrong?
>>
>
> Yes they are run (or some subset thereof). The -nativepath that gets
> passed to jtreg does not include a lib component.
>
> I'm afraid I don't know what is going wrong.
>
> David
> -----
>
> BTW. This paths above are taken from runs on my mac. The problem also
>> occurs on my Linux desktop.
>>
>> Carsten
>>
>>     David
>>     -----
>>
>>
>>
>>
>>            # Expect JPRT to set JPRT_ARCHIVE_BUNDLE (path to zip bundle
>>         for results)
>>
>>         Carsten
>>
>>         On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi.lam at oracle.com
>>         <mailto:ioi.lam at oracle.com>> wrote:
>>
>>             Your patch seems to have been stripped by the mailer. Is it
>>             possible to
>>             just include it as plain text in the e-mail?
>>
>>             Thanks
>>             - Ioi
>>
>>
>>             On 11/30/15 1:34 PM, Carsten Varming wrote:
>>
>>                 Hi everyone,
>>
>>                 I was recently trying to run some tests that use native
>>                 code, e.g.,
>>                 hotspot/runtime/SameObject/SameObject.java and found
>>                 that I had to apply
>>                 the attached diff to get the tests to work.
>>
>>                 I am doing something wrong or is this a trivial bug?
>>
>>                 Carsten
>>
>>
>>
>>
>>


From jonathan.gibbons at oracle.com  Thu Dec  3 17:42:43 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 03 Dec 2015 09:42:43 -0800
Subject: Running native code test
In-Reply-To: <CAP_pwnVgiFW5aSZGhkD4F8NVw_L7wgsOTXgtB7nY8adnYD3DXw@mail.gmail.com>
References: <CAP_pwnW8S_yuFQgbbuP3S9AMo9c6uag7u9ZN1RsEtwH9k=uvQg@mail.gmail.com>	<565CCAE4.2080905@oracle.com>	<CAP_pwnXBerMzSG8aH6cU=AQ4wR7oSqN-CSgcgyZXMeE6YtQLqQ@mail.gmail.com>	<565D4BA5.2030704@oracle.com>	<CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>	<565FEBF4.7070506@oracle.com>
	<CAP_pwnVgiFW5aSZGhkD4F8NVw_L7wgsOTXgtB7nY8adnYD3DXw@mail.gmail.com>
Message-ID: <56607F13.7010200@oracle.com>

Carsten,

I'll file a RFE for jtreg for you.

-- Jon


On 12/03/2015 09:13 AM, Carsten Varming wrote:
> Dear David,
>
> I think I finally understand what is going on now. :)
>
> The command "make build-test-hotspot-jtreg-native" populates
> $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ with ".so" files using
> sub-directories of $(OUTPUTDIR)/support/test/hotspot/jtreg/native/support/
> as scratch space for each test.
>
> The command "make test-image-hotspot-jtreg-native" (which I didn't run in
> my sequence of commands above) copies all files
> in $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/
> to $(OUTPUTDIR)/images/test/hotspot/jtreg/native/ . Notice the lacking
> "/lib" in the target.
>
> Jtreg is passed the parameter
> "-nativepath:$(TESTNATIVE_DIR)/hotspot/jtreg/native". Jtreg then use the
> native path to set both system properties: test.nativepath and
> java.library.path.
>
> This leaves a lot to be desired. Jtreg expects all library files and
> executables to be in the same directory (there are no executables in the
> hotspot tests, but the jdk contains one). There is separation between
> libraries and executables everywhere except
> in $(OUTPUTDIR)/images/test/{hotspot,jdk}/jtreg/native/ because jtreg and
> jdk/test/native_sanity/simplenativelauncher/ProgramTest.java expect
> executables to be in the same directory as libraries. I have never seen
> that before. Notice that this makes the step copying the executables into
> the images sub-directory mandatory.
>
> The right thing seems to be to fix jtreg to maintain separation. Something
> as simple as setting java.library.path to test.nativepath + "/lib" and
> force a standard layout with bin and lib sub-directories would be an
> improvement. Perhaps even extend jtreg it to allow separation between
> libraries and executables from different tests (test A should not have
> access to libraries from test B).
>
> I will drop this issue now that I have a way to execute tests containing
> native code, but it would be nice if someone working on jtreg would make it
> possible keep executables separate from libraries.
>
> Carsten
>
> On Thu, Dec 3, 2015 at 2:15 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> cc'ing build-dev
>>
>> On 2/12/2015 1:28 AM, Carsten Varming wrote:
>>
>>> Dear David,
>>>
>>> See inline.
>>>
>>> On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>      Hi Carsten,
>>>
>>>      On 1/12/2015 8:21 AM, Carsten Varming wrote:
>>>
>>>          Dear Ioi,
>>>
>>>          Absolutely,
>>>
>>>          diff -r 7606b8556225 test/Makefile
>>>          --- a/test/Makefile     Thu Nov 26 13:13:03 2015 +0100
>>>          +++ b/test/Makefile     Mon Nov 30 17:20:30 2015 -0500
>>>          @@ -156,7 +156,7 @@
>>>               TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
>>>             endif
>>>             ifdef TESTNATIVE_DIR
>>>          -  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>>          "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>>>          +  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>>          "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
>>>             endif
>>>
>>>
>>>      In hotspot/make/test/JtregNative.gmk we have:
>>>
>>>      BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
>>>      $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native
>>>
>>>
>>> The SetupTestFilesCompilation macro adds the subdirectory "lib" to the
>>> path such that the ".so" files (or ".dylib" files) end up in
>>> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native/lib.
>>>
>> Thanks for that. Tracing through these makefile macros is far too painful.
>> I wish there were some way to see what they looked like once expanded.
>>
>>      so the above patch should not be needed.
>>>
>>> Without the patch the following sequence of commands fails:
>>> sh configure --enable-debug
>>> make images
>>> make build-test-hotspot-jtreg-native
>>> cd hotspot/test
>>> make TESTDIRS=runtime/SameObject
>>>
>>> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
>>> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
>>> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
>>> PRODUCT_HOME=$JAVA_HOME jtreg_tests
>>>
>>> TEST RESULT: Failed. Execution failed: `main' threw exception:
>>> java.lang.UnsatisfiedLinkError: no SameObject in java.library.path
>>>
>>> and java.library.path is defined
>>> by:
>>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native
>>>
>> What I see in a JPRT build is simply:
>>
>> (cd /scratch/hotspot/make/test && make  -r -R -I /scratch/make/common
>> SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk
>> MAKE_LOG_FLAGS="" LOG_LEVEL=debug -f JtregNative.gmk \
>>      test-image-hotspot-jtreg-native)
>>
>>
>>> On the other hand, with the patch the test runs fine. Looking at
>>> SameObject.jtr I can
>>> see:
>>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib,
>>> i.e., "/lib" is appended to the path and the test pass.
>>>
>>> So I wonder, are these tests run by JPRT? And if they are, then what I
>>> am doing wrong?
>>>
>> Yes they are run (or some subset thereof). The -nativepath that gets
>> passed to jtreg does not include a lib component.
>>
>> I'm afraid I don't know what is going wrong.
>>
>> David
>> -----
>>
>> BTW. This paths above are taken from runs on my mac. The problem also
>>> occurs on my Linux desktop.
>>>
>>> Carsten
>>>
>>>      David
>>>      -----
>>>
>>>
>>>
>>>
>>>             # Expect JPRT to set JPRT_ARCHIVE_BUNDLE (path to zip bundle
>>>          for results)
>>>
>>>          Carsten
>>>
>>>          On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi.lam at oracle.com
>>>          <mailto:ioi.lam at oracle.com>> wrote:
>>>
>>>              Your patch seems to have been stripped by the mailer. Is it
>>>              possible to
>>>              just include it as plain text in the e-mail?
>>>
>>>              Thanks
>>>              - Ioi
>>>
>>>
>>>              On 11/30/15 1:34 PM, Carsten Varming wrote:
>>>
>>>                  Hi everyone,
>>>
>>>                  I was recently trying to run some tests that use native
>>>                  code, e.g.,
>>>                  hotspot/runtime/SameObject/SameObject.java and found
>>>                  that I had to apply
>>>                  the attached diff to get the tests to work.
>>>
>>>                  I am doing something wrong or is this a trivial bug?
>>>
>>>                  Carsten
>>>
>>>
>>>
>>>
>>>



From asmundak at google.com  Thu Dec  3 18:29:26 2015
From: asmundak at google.com (Alexander Smundak)
Date: Thu, 3 Dec 2015 10:29:26 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <565FE186.7090508@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
Message-ID: <CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>

On Wed, Dec 2, 2015 at 10:30 PM, David Holmes <david.holmes at oracle.com> wrote:
> agent code:
>
> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and
> -Dppc64le, such that you don't need to check for either being defined ??
You mean, add -Dppc64 to the compilation flags explicitly if the value
of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'?

Sasha


From magnus.ihse.bursie at oracle.com  Thu Dec  3 21:01:26 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2015 22:01:26 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <56605F6D.3030103@oracle.com>
References: <56605F6D.3030103@oracle.com>
Message-ID: <5660ADA6.70604@oracle.com>

On 2015-12-03 16:27, Erik Joelsson wrote:
> Hello,
>
> This patch adds support for a new Oracle internal tool that will help 
> us manage build configurations. I doubt it could be of any use to 
> outside users, except perhaps to give a bit of insight into what 
> versions of certain dependencies we use internally, as those will be 
> specified in the jab-profiles.js configuration file.
>
> In addition to the JAB configuration files added here, I've also added 
> a new configure option --with-default-make-target with which you can 
> change the default make target for a configuration. A bug is fixed in 
> the configure wrapper script where it's currently not propagating the 
> return value of configure. Finally a new make command line variable is 
> added, CONF_NAME, which works like CONF, except it only matches exact 
> configuration names.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8136782
> Webrev: http://cr.openjdk.java.net/~erikj/8136782/webrev.top.01/
Hi Erik,

Nice to see progress on this new feature. :)

I have a bunch of comments this time.

In basics.m4:

The indentation looks weird, but maybe that's just an artifact of webrev?

I'm a bit curious why this fix was needed. I thought one of the idea 
with BASIC_FIXUP_PATH was to guarantee that we pointed to an existing 
directory?

If you needed to check something else than directories, maybe a 
different function should be used, like BASIC_FIXUP_EXECUTABLE.

Does --with-default-make-target really belong in build-performance? I'm 
not sure really where it belongs, though. It's more closely related to 
the stuff in source-dirs.m4, but the name of that file makes it too 
narrow. Maybe rename it to sources.m4 and put it there?

In InitSupport.gmk:
Maybe you should check so not both CONF and CONF_NAME is used as well?

Also make/Help.gmk should be updated with CONF_NAME, I think.

 > # Create a SPEC definition. This will contain the path to one or more 
spec.gmk files.
 > SPECS := $$(addsuffix /spec.gmk, $$(addprefix $$(build_dir)/, 
$$(matching_confs)))

Actually, no. It will contain only one. In fact, maybe you should add a 
sanity  check that  matching_confs contains exactly one configuration 
(unless it's empty).  And, given that, the SPECS assignment can be 
simplified to just simple string concatenation.

In jab.sh:

  25 # This script installs the jdk build wrapper tool into it's own local
   26 # repository and puts wrapper scripts into this bin directory.

"installs the jab tool" perhaps sounds better?

  35     if [ -f "~/.jab" ]; then
   36         source ~/.jab

Is this a local configuration file? Why not .config/jab/jab.conf 
instead? I'd like to keep my home dir clutter free, if possible.

   97     ${getcmd} ${jab_url} > "${installed_jab_script}.gz"
   98     rm -f "${installed_jab_script}"
   99     gunzip "${installed_jab_script}.gz"

Maybe rm -f the  "${installed_jab_script}.gz" first as well, just to be 
on the safe side? Also, since network connectivity is the most likely 
cause of failure here, maybe explicitely test that 
"${installed_jab_script}.gz" arrived and is non-zero, and otherwise 
print a clear error message stating the URL that we tried to access and 
say that it failed. And/or check the exit code from wget/curl?

Also, when installing jab, maybe you could be slightly more verbose? 
Like, "Downloading jab.sh.gz" and "Extracting jab.sh.gz", just to let 
the user know something is happening. And while jab.sh.gz might be 
likely to be small, on a slow line it might still be a noticable delay.

    99     gunzip "${installed_jab_script}.gz"

Maybe we should verify that gunzip is available?

Do we need to run setup_url() even if not installing?

I'm also not sure about the "Install url changed" thingy. If I've once 
downloaded jab using JAB_SERVER=foo jab.sh, then I should be able to 
leave JAB_SERVER=foo out on future invocations, methinks. But this logic 
looks like it's going to trip that up. I'm not sure for what reason.

Finally, shell scripts with functions can be bit a hard to read. Maybe 
you could add some kind of delimiter after the install_jab() function 
and before the main body of the file?

Since the script is storing stuff in .jab, maybe you should add .jab to 
.hgignore?

In jab-profiles.js:

   45  * The parameter 'input' is an object that optionally contains the
   46  * some data.

"the some"  --> "some".

*   output_basedir; "build",

Perhaps colon?

// List of free from labels describing aspects of this profile
  115  *       labels: <Array of strings>

"free form". But why not "tags" instead of "labels"? I'd say that in 
modern usage, "tag" means just "free form label".

  132  *       // List of configure args to add when using this dependency,
  133  *       // defaults to input.get("<dependency-name", "install_path")

Seems a "--with-<dependency-name>=" got lost there, somehow?

  135  *       // Name of environment variable to set when using this 
dependency
  136  *       environment_name: <string>
  137  *       // Value of environment variable to set when using this 
dependency
  138  *       environment_value: <string>
  139  *       // Value to add to the PATH variable when using this 
dependency
  140  *       environment_path: <string>

This is set for "jab make" only, right? Maybe clarify that.

  144  *       // For certain dependencies where a legacy distribution 
mechanism is
  145  *       // already i place, the "javare" server layout is also 
supported

  "in place". Also, missing period.

  150  *       // buildnumber (optional), files and checksumfile is 
possible for

  "build number", "checksum file"

   *       // aritfacts following the standard layout.

"artifacts"

   *       // For other files, use checksumpath and paths instead

"checksum path"

   62  * input.build_unix_os
   63  * input.build_unix_cpu
   66  * input.build_unix_platform

What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)

/Magnus



From staffan.larsen at oracle.com  Fri Dec  4 07:20:18 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 4 Dec 2015 08:20:18 +0100
Subject: Running native code test
In-Reply-To: <CAP_pwnVgiFW5aSZGhkD4F8NVw_L7wgsOTXgtB7nY8adnYD3DXw@mail.gmail.com>
References: <CAP_pwnW8S_yuFQgbbuP3S9AMo9c6uag7u9ZN1RsEtwH9k=uvQg@mail.gmail.com>
	<565CCAE4.2080905@oracle.com>
	<CAP_pwnXBerMzSG8aH6cU=AQ4wR7oSqN-CSgcgyZXMeE6YtQLqQ@mail.gmail.com>
	<565D4BA5.2030704@oracle.com>
	<CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>
	<565FEBF4.7070506@oracle.com>
	<CAP_pwnVgiFW5aSZGhkD4F8NVw_L7wgsOTXgtB7nY8adnYD3DXw@mail.gmail.com>
Message-ID: <C3BB4C1F-8CF5-413E-A22C-B408BDB182AE@oracle.com>

Why is it a problem having executables and libraries in the same directory? It was a design choice we made to make things simpler.

/Staffan

> On 3 dec. 2015, at 18:13, Carsten Varming <varming at gmail.com> wrote:
> 
> Dear David,
> 
> I think I finally understand what is going on now. :)
> 
> The command "make build-test-hotspot-jtreg-native" populates
> $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ with ".so" files using
> sub-directories of $(OUTPUTDIR)/support/test/hotspot/jtreg/native/support/
> as scratch space for each test.
> 
> The command "make test-image-hotspot-jtreg-native" (which I didn't run in
> my sequence of commands above) copies all files
> in $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/
> to $(OUTPUTDIR)/images/test/hotspot/jtreg/native/ . Notice the lacking
> "/lib" in the target.
> 
> Jtreg is passed the parameter
> "-nativepath:$(TESTNATIVE_DIR)/hotspot/jtreg/native". Jtreg then use the
> native path to set both system properties: test.nativepath and
> java.library.path.
> 
> This leaves a lot to be desired. Jtreg expects all library files and
> executables to be in the same directory (there are no executables in the
> hotspot tests, but the jdk contains one). There is separation between
> libraries and executables everywhere except
> in $(OUTPUTDIR)/images/test/{hotspot,jdk}/jtreg/native/ because jtreg and
> jdk/test/native_sanity/simplenativelauncher/ProgramTest.java expect
> executables to be in the same directory as libraries. I have never seen
> that before. Notice that this makes the step copying the executables into
> the images sub-directory mandatory.
> 
> The right thing seems to be to fix jtreg to maintain separation. Something
> as simple as setting java.library.path to test.nativepath + "/lib" and
> force a standard layout with bin and lib sub-directories would be an
> improvement. Perhaps even extend jtreg it to allow separation between
> libraries and executables from different tests (test A should not have
> access to libraries from test B).
> 
> I will drop this issue now that I have a way to execute tests containing
> native code, but it would be nice if someone working on jtreg would make it
> possible keep executables separate from libraries.
> 
> Carsten
> 
> On Thu, Dec 3, 2015 at 2:15 AM, David Holmes <david.holmes at oracle.com>
> wrote:
> 
>> cc'ing build-dev
>> 
>> On 2/12/2015 1:28 AM, Carsten Varming wrote:
>> 
>>> Dear David,
>>> 
>>> See inline.
>>> 
>>> On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>> 
>>>    Hi Carsten,
>>> 
>>>    On 1/12/2015 8:21 AM, Carsten Varming wrote:
>>> 
>>>        Dear Ioi,
>>> 
>>>        Absolutely,
>>> 
>>>        diff -r 7606b8556225 test/Makefile
>>>        --- a/test/Makefile     Thu Nov 26 13:13:03 2015 +0100
>>>        +++ b/test/Makefile     Mon Nov 30 17:20:30 2015 -0500
>>>        @@ -156,7 +156,7 @@
>>>             TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
>>>           endif
>>>           ifdef TESTNATIVE_DIR
>>>        -  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>>        "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>>>        +  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>>        "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
>>>           endif
>>> 
>>> 
>>>    In hotspot/make/test/JtregNative.gmk we have:
>>> 
>>>    BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
>>>    $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native
>>> 
>>> 
>>> The SetupTestFilesCompilation macro adds the subdirectory "lib" to the
>>> path such that the ".so" files (or ".dylib" files) end up in
>>> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native/lib.
>>> 
>> 
>> Thanks for that. Tracing through these makefile macros is far too painful.
>> I wish there were some way to see what they looked like once expanded.
>> 
>>    so the above patch should not be needed.
>>> 
>>> 
>>> Without the patch the following sequence of commands fails:
>>> sh configure --enable-debug
>>> make images
>>> make build-test-hotspot-jtreg-native
>>> cd hotspot/test
>>> make TESTDIRS=runtime/SameObject
>>> 
>>> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
>>> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
>>> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
>>> PRODUCT_HOME=$JAVA_HOME jtreg_tests
>>> 
>>> TEST RESULT: Failed. Execution failed: `main' threw exception:
>>> java.lang.UnsatisfiedLinkError: no SameObject in java.library.path
>>> 
>>> and java.library.path is defined
>>> by:
>>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native
>>> 
>> 
>> What I see in a JPRT build is simply:
>> 
>> (cd /scratch/hotspot/make/test && make  -r -R -I /scratch/make/common
>> SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk
>> MAKE_LOG_FLAGS="" LOG_LEVEL=debug -f JtregNative.gmk \
>>    test-image-hotspot-jtreg-native)
>> 
>> 
>>> On the other hand, with the patch the test runs fine. Looking at
>>> SameObject.jtr I can
>>> see:
>>> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib,
>>> i.e., "/lib" is appended to the path and the test pass.
>>> 
>>> So I wonder, are these tests run by JPRT? And if they are, then what I
>>> am doing wrong?
>>> 
>> 
>> Yes they are run (or some subset thereof). The -nativepath that gets
>> passed to jtreg does not include a lib component.
>> 
>> I'm afraid I don't know what is going wrong.
>> 
>> David
>> -----
>> 
>> BTW. This paths above are taken from runs on my mac. The problem also
>>> occurs on my Linux desktop.
>>> 
>>> Carsten
>>> 
>>>    David
>>>    -----
>>> 
>>> 
>>> 
>>> 
>>>           # Expect JPRT to set JPRT_ARCHIVE_BUNDLE (path to zip bundle
>>>        for results)
>>> 
>>>        Carsten
>>> 
>>>        On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi.lam at oracle.com
>>>        <mailto:ioi.lam at oracle.com>> wrote:
>>> 
>>>            Your patch seems to have been stripped by the mailer. Is it
>>>            possible to
>>>            just include it as plain text in the e-mail?
>>> 
>>>            Thanks
>>>            - Ioi
>>> 
>>> 
>>>            On 11/30/15 1:34 PM, Carsten Varming wrote:
>>> 
>>>                Hi everyone,
>>> 
>>>                I was recently trying to run some tests that use native
>>>                code, e.g.,
>>>                hotspot/runtime/SameObject/SameObject.java and found
>>>                that I had to apply
>>>                the attached diff to get the tests to work.
>>> 
>>>                I am doing something wrong or is this a trivial bug?
>>> 
>>>                Carsten
>>> 
>>> 
>>> 
>>> 
>>> 



From david.holmes at oracle.com  Fri Dec  4 07:59:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 4 Dec 2015 17:59:43 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
Message-ID: <566147EF.4000109@oracle.com>

On 4/12/2015 4:29 AM, Alexander Smundak wrote:
> On Wed, Dec 2, 2015 at 10:30 PM, David Holmes <david.holmes at oracle.com> wrote:
>> agent code:
>>
>> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and
>> -Dppc64le, such that you don't need to check for either being defined ??
> You mean, add -Dppc64 to the compilation flags explicitly if the value
> of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'?

Yes. Is that feasible?

Thanks,
David

> Sasha
>


From erik.joelsson at oracle.com  Fri Dec  4 09:57:07 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 4 Dec 2015 10:57:07 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <5660ADA6.70604@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
Message-ID: <56616373.4010005@oracle.com>

New webrev:

On 2015-12-03 22:01, Magnus Ihse Bursie wrote:
> On 2015-12-03 16:27, Erik Joelsson wrote:
>> Hello,
>>
>> This patch adds support for a new Oracle internal tool that will help 
>> us manage build configurations. I doubt it could be of any use to 
>> outside users, except perhaps to give a bit of insight into what 
>> versions of certain dependencies we use internally, as those will be 
>> specified in the jab-profiles.js configuration file.
>>
>> In addition to the JAB configuration files added here, I've also 
>> added a new configure option --with-default-make-target with which 
>> you can change the default make target for a configuration. A bug is 
>> fixed in the configure wrapper script where it's currently not 
>> propagating the return value of configure. Finally a new make command 
>> line variable is added, CONF_NAME, which works like CONF, except it 
>> only matches exact configuration names.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136782
>> Webrev: http://cr.openjdk.java.net/~erikj/8136782/webrev.top.01/
> Hi Erik,
>
> Nice to see progress on this new feature. :)
>
> I have a bunch of comments this time.
>
Good!
> In basics.m4:
>
> The indentation looks weird, but maybe that's just an artifact of webrev?
Fixed
>
> I'm a bit curious why this fix was needed. I thought one of the idea 
> with BASIC_FIXUP_PATH was to guarantee that we pointed to an existing 
> directory?
>
The documentation only says path, which I interpret as either a file or dir.
> If you needed to check something else than directories, maybe a 
> different function should be used, like BASIC_FIXUP_EXECUTABLE.
>
I needed to (in closed) fix a file that wasn't executable. 
BASIC_FIXUP_EXECUTABLE doesn't handle that. IMO, the change to support 
files as well as dirs is better than having to implement a complete new 
set of macros.
> Does --with-default-make-target really belong in build-performance? 
> I'm not sure really where it belongs, though. It's more closely 
> related to the stuff in source-dirs.m4, but the name of that file 
> makes it too narrow. Maybe rename it to sources.m4 and put it there?
>
I reacted to this too when I sorted through the changes I had made in 
the sandbox, but there was no really good fit. Perhaps basics.m4 is 
best? Moved it there
> In InitSupport.gmk:
> Maybe you should check so not both CONF and CONF_NAME is used as well?
>
> Also make/Help.gmk should be updated with CONF_NAME, I think.
>
Fixed
> > # Create a SPEC definition. This will contain the path to one or 
> more spec.gmk files.
> > SPECS := $$(addsuffix /spec.gmk, $$(addprefix $$(build_dir)/, 
> $$(matching_confs)))
>
Fixed
> Actually, no. It will contain only one. In fact, maybe you should add 
> a sanity  check that  matching_confs contains exactly one 
> configuration (unless it's empty).  And, given that, the SPECS 
> assignment can be simplified to just simple string concatenation.
>
Right, fixed.
> In jab.sh:
>
>  25 # This script installs the jdk build wrapper tool into it's own local
>   26 # repository and puts wrapper scripts into this bin directory.
>
> "installs the jab tool" perhaps sounds better?
>
Fixed the comment
>  35 if [ -f "~/.jab" ]; then
>   36         source ~/.jab
>
> Is this a local configuration file? Why not .config/jab/jab.conf 
> instead? I'd like to keep my home dir clutter free, if possible.
>
Sure, didn't know of any other standard, but .config seems to be pretty 
popular in my home dir.
> 97     ${getcmd} ${jab_url} > "${installed_jab_script}.gz"
>   98     rm -f "${installed_jab_script}"
>   99     gunzip "${installed_jab_script}.gz"
>
> Maybe rm -f the  "${installed_jab_script}.gz" first as well, just to 
> be on the safe side? Also, since network connectivity is the most 
> likely cause of failure here, maybe explicitely test that 
> "${installed_jab_script}.gz" arrived and is non-zero, and otherwise 
> print a clear error message stating the URL that we tried to access 
> and say that it failed. And/or check the exit code from wget/curl?
>
Added test for -s.
> Also, when installing jab, maybe you could be slightly more verbose? 
> Like, "Downloading jab.sh.gz" and "Extracting jab.sh.gz", just to let 
> the user know something is happening. And while jab.sh.gz might be 
> likely to be small, on a slow line it might still be a noticable delay.
In my experience, it's so small the delay is almost not noticeable, even 
when downloading from west coast US to Stockholm, but I can add some 
echos. Note that these will not look like other JAB output since the 
logging framework is not yet available before JAB has even started.
>
>    99     gunzip "${installed_jab_script}.gz"
>
> Maybe we should verify that gunzip is available?
>
Added.
> Do we need to run setup_url() even if not installing?
>
> I'm also not sure about the "Install url changed" thingy. If I've once 
> downloaded jab using JAB_SERVER=foo jab.sh, then I should be able to 
> leave JAB_SERVER=foo out on future invocations, methinks. But this 
> logic looks like it's going to trip that up. I'm not sure for what 
> reason.
>
I did this intentionally. The reason is that stale downloads should not 
affect usage of the tool. The idea with JAB is to always use the latest 
version unless specifically told not to. The setup_url is needed to 
verify that the correct version of JAB is installed. Note that the url 
can change for a number of reasons, not just the base url part. Imagine 
someone changing this script to update the jab_revision, you would want 
that to be reflected next time the script is executed.

Note that in the normal case, where you supply JAB_SERVER, that part of 
the URL is not saved in the data file, so leaving it out next time will 
not trigger a new download.
> Finally, shell scripts with functions can be bit a hard to read. Maybe 
> you could add some kind of delimiter after the install_jab() function 
> and before the main body of the file?
>
Done
> Since the script is storing stuff in .jab, maybe you should add .jab 
> to .hgignore?
>
Forgot to bring that change over, added.
> In jab-profiles.js:
>
>   45  * The parameter 'input' is an object that optionally contains the
>   46  * some data.
>
> "the some"  --> "some".
>
> *   output_basedir; "build",
>
> Perhaps colon?
>
Fixed
> // List of free from labels describing aspects of this profile
>  115  *       labels: <Array of strings>
>
> "free form". But why not "tags" instead of "labels"? I'd say that in 
> modern usage, "tag" means just "free form label".
>
A discussion with Stefan, who is building the tool consuming this 
particular attribute, he preferred labels.
>  132 *       // List of configure args to add when using this dependency,
>  133  *       // defaults to input.get("<dependency-name", 
> "install_path")
>
> Seems a "--with-<dependency-name>=" got lost there, somehow?
>
Fixed
>  135 *       // Name of environment variable to set when using this 
> dependency
>  136  *       environment_name: <string>
>  137  *       // Value of environment variable to set when using this 
> dependency
>  138  *       environment_value: <string>
>  139  *       // Value to add to the PATH variable when using this 
> dependency
>  140  *       environment_path: <string>
>
> This is set for "jab make" only, right? Maybe clarify that.
>
Clarified
>  144 *       // For certain dependencies where a legacy distribution 
> mechanism is
>  145  *       // already i place, the "javare" server layout is also 
> supported
>
>  "in place". Also, missing period.
>
>  150  *       // buildnumber (optional), files and checksumfile is 
> possible for
>
>  "build number", "checksum file"
>
>   *       // aritfacts following the standard layout.
>
> "artifacts"
>
>   *       // For other files, use checksumpath and paths instead
>
> "checksum path"
>
>   62  * input.build_unix_os
>   63  * input.build_unix_cpu
>   66  * input.build_unix_platform
>
> What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
>
Clarified

/Erik
> /Magnus
>



From erik.joelsson at oracle.com  Fri Dec  4 09:58:52 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 4 Dec 2015 10:58:52 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <56616373.4010005@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com>
Message-ID: <566163DC.9090101@oracle.com>

Forgot the link
http://cr.openjdk.java.net/~erikj/8136782/webrev.top.02/

On 2015-12-04 10:57, Erik Joelsson wrote:
> New webrev:
>
> On 2015-12-03 22:01, Magnus Ihse Bursie wrote:
>> On 2015-12-03 16:27, Erik Joelsson wrote:
>>> Hello,
>>>
>>> This patch adds support for a new Oracle internal tool that will 
>>> help us manage build configurations. I doubt it could be of any use 
>>> to outside users, except perhaps to give a bit of insight into what 
>>> versions of certain dependencies we use internally, as those will be 
>>> specified in the jab-profiles.js configuration file.
>>>
>>> In addition to the JAB configuration files added here, I've also 
>>> added a new configure option --with-default-make-target with which 
>>> you can change the default make target for a configuration. A bug is 
>>> fixed in the configure wrapper script where it's currently not 
>>> propagating the return value of configure. Finally a new make 
>>> command line variable is added, CONF_NAME, which works like CONF, 
>>> except it only matches exact configuration names.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136782
>>> Webrev: http://cr.openjdk.java.net/~erikj/8136782/webrev.top.01/
>> Hi Erik,
>>
>> Nice to see progress on this new feature. :)
>>
>> I have a bunch of comments this time.
>>
> Good!
>> In basics.m4:
>>
>> The indentation looks weird, but maybe that's just an artifact of 
>> webrev?
> Fixed
>>
>> I'm a bit curious why this fix was needed. I thought one of the idea 
>> with BASIC_FIXUP_PATH was to guarantee that we pointed to an existing 
>> directory?
>>
> The documentation only says path, which I interpret as either a file 
> or dir.
>> If you needed to check something else than directories, maybe a 
>> different function should be used, like BASIC_FIXUP_EXECUTABLE.
>>
> I needed to (in closed) fix a file that wasn't executable. 
> BASIC_FIXUP_EXECUTABLE doesn't handle that. IMO, the change to support 
> files as well as dirs is better than having to implement a complete 
> new set of macros.
>> Does --with-default-make-target really belong in build-performance? 
>> I'm not sure really where it belongs, though. It's more closely 
>> related to the stuff in source-dirs.m4, but the name of that file 
>> makes it too narrow. Maybe rename it to sources.m4 and put it there?
>>
> I reacted to this too when I sorted through the changes I had made in 
> the sandbox, but there was no really good fit. Perhaps basics.m4 is 
> best? Moved it there
>> In InitSupport.gmk:
>> Maybe you should check so not both CONF and CONF_NAME is used as well?
>>
>> Also make/Help.gmk should be updated with CONF_NAME, I think.
>>
> Fixed
>> > # Create a SPEC definition. This will contain the path to one or 
>> more spec.gmk files.
>> > SPECS := $$(addsuffix /spec.gmk, $$(addprefix $$(build_dir)/, 
>> $$(matching_confs)))
>>
> Fixed
>> Actually, no. It will contain only one. In fact, maybe you should add 
>> a sanity  check that  matching_confs contains exactly one 
>> configuration (unless it's empty).  And, given that, the SPECS 
>> assignment can be simplified to just simple string concatenation.
>>
> Right, fixed.
>> In jab.sh:
>>
>>  25 # This script installs the jdk build wrapper tool into it's own 
>> local
>>   26 # repository and puts wrapper scripts into this bin directory.
>>
>> "installs the jab tool" perhaps sounds better?
>>
> Fixed the comment
>>  35 if [ -f "~/.jab" ]; then
>>   36         source ~/.jab
>>
>> Is this a local configuration file? Why not .config/jab/jab.conf 
>> instead? I'd like to keep my home dir clutter free, if possible.
>>
> Sure, didn't know of any other standard, but .config seems to be 
> pretty popular in my home dir.
>> 97     ${getcmd} ${jab_url} > "${installed_jab_script}.gz"
>>   98     rm -f "${installed_jab_script}"
>>   99     gunzip "${installed_jab_script}.gz"
>>
>> Maybe rm -f the  "${installed_jab_script}.gz" first as well, just to 
>> be on the safe side? Also, since network connectivity is the most 
>> likely cause of failure here, maybe explicitely test that 
>> "${installed_jab_script}.gz" arrived and is non-zero, and otherwise 
>> print a clear error message stating the URL that we tried to access 
>> and say that it failed. And/or check the exit code from wget/curl?
>>
> Added test for -s.
>> Also, when installing jab, maybe you could be slightly more verbose? 
>> Like, "Downloading jab.sh.gz" and "Extracting jab.sh.gz", just to let 
>> the user know something is happening. And while jab.sh.gz might be 
>> likely to be small, on a slow line it might still be a noticable delay.
> In my experience, it's so small the delay is almost not noticeable, 
> even when downloading from west coast US to Stockholm, but I can add 
> some echos. Note that these will not look like other JAB output since 
> the logging framework is not yet available before JAB has even started.
>>
>>    99     gunzip "${installed_jab_script}.gz"
>>
>> Maybe we should verify that gunzip is available?
>>
> Added.
>> Do we need to run setup_url() even if not installing?
>>
>> I'm also not sure about the "Install url changed" thingy. If I've 
>> once downloaded jab using JAB_SERVER=foo jab.sh, then I should be 
>> able to leave JAB_SERVER=foo out on future invocations, methinks. But 
>> this logic looks like it's going to trip that up. I'm not sure for 
>> what reason.
>>
> I did this intentionally. The reason is that stale downloads should 
> not affect usage of the tool. The idea with JAB is to always use the 
> latest version unless specifically told not to. The setup_url is 
> needed to verify that the correct version of JAB is installed. Note 
> that the url can change for a number of reasons, not just the base url 
> part. Imagine someone changing this script to update the jab_revision, 
> you would want that to be reflected next time the script is executed.
>
> Note that in the normal case, where you supply JAB_SERVER, that part 
> of the URL is not saved in the data file, so leaving it out next time 
> will not trigger a new download.
>> Finally, shell scripts with functions can be bit a hard to read. 
>> Maybe you could add some kind of delimiter after the install_jab() 
>> function and before the main body of the file?
>>
> Done
>> Since the script is storing stuff in .jab, maybe you should add .jab 
>> to .hgignore?
>>
> Forgot to bring that change over, added.
>> In jab-profiles.js:
>>
>>   45  * The parameter 'input' is an object that optionally contains the
>>   46  * some data.
>>
>> "the some"  --> "some".
>>
>> *   output_basedir; "build",
>>
>> Perhaps colon?
>>
> Fixed
>> // List of free from labels describing aspects of this profile
>>  115  *       labels: <Array of strings>
>>
>> "free form". But why not "tags" instead of "labels"? I'd say that in 
>> modern usage, "tag" means just "free form label".
>>
> A discussion with Stefan, who is building the tool consuming this 
> particular attribute, he preferred labels.
>>  132 *       // List of configure args to add when using this 
>> dependency,
>>  133  *       // defaults to input.get("<dependency-name", 
>> "install_path")
>>
>> Seems a "--with-<dependency-name>=" got lost there, somehow?
>>
> Fixed
>>  135 *       // Name of environment variable to set when using this 
>> dependency
>>  136  *       environment_name: <string>
>>  137  *       // Value of environment variable to set when using this 
>> dependency
>>  138  *       environment_value: <string>
>>  139  *       // Value to add to the PATH variable when using this 
>> dependency
>>  140  *       environment_path: <string>
>>
>> This is set for "jab make" only, right? Maybe clarify that.
>>
> Clarified
>>  144 *       // For certain dependencies where a legacy distribution 
>> mechanism is
>>  145  *       // already i place, the "javare" server layout is also 
>> supported
>>
>>  "in place". Also, missing period.
>>
>>  150  *       // buildnumber (optional), files and checksumfile is 
>> possible for
>>
>>  "build number", "checksum file"
>>
>>   *       // aritfacts following the standard layout.
>>
>> "artifacts"
>>
>>   *       // For other files, use checksumpath and paths instead
>>
>> "checksum path"
>>
>>   62  * input.build_unix_os
>>   63  * input.build_unix_cpu
>>   66  * input.build_unix_platform
>>
>> What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
>>
> Clarified
>
> /Erik
>> /Magnus
>>
>



From magnus.ihse.bursie at oracle.com  Fri Dec  4 11:33:02 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2015 12:33:02 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <56616373.4010005@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com>
Message-ID: <1821DB2C-B796-4A1A-8F56-FBD3095384F3@oracle.com>

Just a quick reply, I haven't looked at the new webrev yet.

4 dec. 2015 kl. 10:57 skrev Erik Joelsson <erik.joelsson at oracle.com>:

>> I'm a bit curious why this fix was needed. I thought one of the idea with BASIC_FIXUP_PATH was to guarantee that we pointed to an existing directory?
> The documentation only says path, which I interpret as either a file or dir.

Hm. I think the intention was to verify an existing directory. I agree that the name and documentation does not properly reflect this. Can you please verify other users of this function, if they are all indeed looking for directories? I'm just worried that this change will break the other uses, where it's supposed that a proper, existing directory is returned. Can't you break out common functionality and split this into two, a BASIC_FIXUP_DIR for the current functionality, and a looser version that just verifies a path, be it a file or not?

/Magnus

From magnus.ihse.bursie at oracle.com  Fri Dec  4 11:50:30 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2015 12:50:30 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <566163DC.9090101@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com> <566163DC.9090101@oracle.com>
Message-ID: <491F5FF3-727E-440E-B938-66EB40551FF1@oracle.com>

Comments inline. 

> 4 dec. 2015 kl. 10:58 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Forgot the link
> http://cr.openjdk.java.net/~erikj/8136782/webrev.top.02/
> 
>> On 2015-12-04 10:57, Erik Joelsson wrote:
>> New webrev:
>> 
>>>> On 2015-12-03 22:01, Magnus Ihse Bursie wrote:
>>>> On 2015-12-03 16:27, Erik Joelsson wrote:
>>>> Hello,
>>>> 
>>>> This patch adds support for a new Oracle internal tool that will help us manage build configurations. I doubt it could be of any use to outside users, except perhaps to give a bit of insight into what versions of certain dependencies we use internally, as those will be specified in the jab-profiles.js configuration file.
>>>> 
>>>> In addition to the JAB configuration files added here, I've also added a new configure option --with-default-make-target with which you can change the default make target for a configuration. A bug is fixed in the configure wrapper script where it's currently not propagating the return value of configure. Finally a new make command line variable is added, CONF_NAME, which works like CONF, except it only matches exact configuration names.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136782
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8136782/webrev.top.01/
>>> Hi Erik,
>>> 
>>> Nice to see progress on this new feature. :)
>>> 
>>> I have a bunch of comments this time.
>> Good!
>>> In basics.m4:
>>> 
>>> The indentation looks weird, but maybe that's just an artifact of webrev?
>> Fixed
>>> 
>>> I'm a bit curious why this fix was needed. I thought one of the idea with BASIC_FIXUP_PATH was to guarantee that we pointed to an existing directory?
>> The documentation only says path, which I interpret as either a file or dir.
>>> If you needed to check something else than directories, maybe a different function should be used, like BASIC_FIXUP_EXECUTABLE.
>> I needed to (in closed) fix a file that wasn't executable. BASIC_FIXUP_EXECUTABLE doesn't handle that. IMO, the change to support files as well as dirs is better than having to implement a complete new set of macros.
>>> Does --with-default-make-target really belong in build-performance? I'm not sure really where it belongs, though. It's more closely related to the stuff in source-dirs.m4, but the name of that file makes it too narrow. Maybe rename it to sources.m4 and put it there?
>> I reacted to this too when I sorted through the changes I had made in the sandbox, but there was no really good fit. Perhaps basics.m4 is best? Moved it there

Looks ok. 

>>> In InitSupport.gmk:
>>> Maybe you should check so not both CONF and CONF_NAME is used as well?
>>> 
>>> Also make/Help.gmk should be updated with CONF_NAME, I think.
>> Fixed
>>>> # Create a SPEC definition. This will contain the path to one or more spec.gmk files.
>>>> SPECS := $$(addsuffix /spec.gmk, $$(addprefix $$(build_dir)/, $$(matching_confs)))
>> Fixed
>>> Actually, no. It will contain only one. In fact, maybe you should add a sanity  check that  matching_confs contains exactly one configuration (unless it's empty).  And, given that, the SPECS assignment can be simplified to just simple string concatenation.
>> Right, fixed.
>>> In jab.sh:
>>> 
>>> 25 # This script installs the jdk build wrapper tool into it's own local
>>> 26 # repository and puts wrapper scripts into this bin directory.
>>> 
>>> "installs the jab tool" perhaps sounds better?
>> Fixed the comment
>>> 35 if [ -f "~/.jab" ]; then
>>> 36         source ~/.jab
>>> 
>>> Is this a local configuration file? Why not .config/jab/jab.conf instead? I'd like to keep my home dir clutter free, if possible.
>> Sure, didn't know of any other standard, but .config seems to be pretty popular in my home dir.
>>> 97     ${getcmd} ${jab_url} > "${installed_jab_script}.gz"
>>> 98     rm -f "${installed_jab_script}"
>>> 99     gunzip "${installed_jab_script}.gz"
>>> 
>>> Maybe rm -f the  "${installed_jab_script}.gz" first as well, just to be on the safe side? Also, since network connectivity is the most likely cause of failure here, maybe explicitely test that "${installed_jab_script}.gz" arrived and is non-zero, and otherwise print a clear error message stating the URL that we tried to access and say that it failed. And/or check the exit code from wget/curl?
>> Added test for -s.
>>> Also, when installing jab, maybe you could be slightly more verbose? Like, "Downloading jab.sh.gz" and "Extracting jab.sh.gz", just to let the user know something is happening. And while jab.sh.gz might be likely to be small, on a slow line it might still be a noticable delay.
>> In my experience, it's so small the delay is almost not noticeable, even when downloading from west coast US to Stockholm, but I can add some echos. Note that these will not look like other JAB output since the logging framework is not yet available before JAB has even started.
>>> 
>>>  99     gunzip "${installed_jab_script}.gz"
>>> 
>>> Maybe we should verify that gunzip is available?
>> Added.
>>> Do we need to run setup_url() even if not installing?
>>> 
>>> I'm also not sure about the "Install url changed" thingy. If I've once downloaded jab using JAB_SERVER=foo jab.sh, then I should be able to leave JAB_SERVER=foo out on future invocations, methinks. But this logic looks like it's going to trip that up. I'm not sure for what reason.
>> I did this intentionally. The reason is that stale downloads should not affect usage of the tool. The idea with JAB is to always use the latest version unless specifically told not to. The setup_url is needed to verify that the correct version of JAB is installed. Note that the url can change for a number of reasons, not just the base url part. Imagine someone changing this script to update the jab_revision, you would want that to be reflected next time the script is executed.
>> 
>> Note that in the normal case, where you supply JAB_SERVER, that part of the URL is not saved in the data file, so leaving it out next time will not trigger a new download.

I see. I'm fine with this. Just one note, if you had jab_url=$jab_server/$data_string, maybe this should be more obvious. And it's a nice bit of DRY. 

>>> Finally, shell scripts with functions can be bit a hard to read. Maybe you could add some kind of delimiter after the install_jab() function and before the main body of the file?
>> Done
>>> Since the script is storing stuff in .jab, maybe you should add .jab to .hgignore?
>> Forgot to bring that change over, added.
>>> In jab-profiles.js:
>>> 
>>> 45  * The parameter 'input' is an object that optionally contains the
>>> 46  * some data.
>>> 
>>> "the some"  --> "some".
>>> 
>>> *   output_basedir; "build",
>>> 
>>> Perhaps colon?
>> Fixed
>>> // List of free from labels describing aspects of this profile
>>> 115  *       labels: <Array of strings>
>>> 
>>> "free form". But why not "tags" instead of "labels"? I'd say that in modern usage, "tag" means just "free form label".
>> A discussion with Stefan, who is building the tool consuming this particular attribute, he preferred labels.

Hm. I think he's mistaken. :) But what the heck, who am I to say. :)

>>> 132 *       // List of configure args to add when using this dependency,
>>> 133  *       // defaults to input.get("<dependency-name", "install_path")
>>> 
>>> Seems a "--with-<dependency-name>=" got lost there, somehow?
>> Fixed
>>> 135 *       // Name of environment variable to set when using this dependency
>>> 136  *       environment_name: <string>
>>> 137  *       // Value of environment variable to set when using this dependency
>>> 138  *       environment_value: <string>
>>> 139  *       // Value to add to the PATH variable when using this dependency
>>> 140  *       environment_path: <string>
>>> 
>>> This is set for "jab make" only, right? Maybe clarify that.
>> Clarified
>>> 144 *       // For certain dependencies where a legacy distribution mechanism is
>>> 145  *       // already i place, the "javare" server layout is also supported
>>> 
>>> "in place". Also, missing period.
>>> 
>>> 150  *       // buildnumber (optional), files and checksumfile is possible for
>>> 
>>> "build number", "checksum file"
>>> 
>>> *       // aritfacts following the standard layout.
>>> 
>>> "artifacts"
>>> 
>>> *       // For other files, use checksumpath and paths instead
>>> 
>>> "checksum path"
>>> 
>>> 62  * input.build_unix_os
>>> 63  * input.build_unix_cpu
>>> 66  * input.build_unix_platform
>>> 
>>> What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
>> Clarified

I still think this is not so good. What does build_unix_os contain? "Windows" or "Cygwin"? Is it used only on Windows? And why "unix"? Is the whole reason for this to be able to separate 32 and 64 bit cygwin?

In the build system, we have a notion of "os env", which is the same as "os" in most cases, but isn"cygwin" or "msys" on Windows. Maybe we should use the same terminology here, if we describe the same thing. 

Except for the things I noted, your fixes look good. 

/Magnus

>> 
>> /Erik
>>> /Magnus
> 


From erik.joelsson at oracle.com  Fri Dec  4 13:37:09 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 4 Dec 2015 14:37:09 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <1821DB2C-B796-4A1A-8F56-FBD3095384F3@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com>
	<1821DB2C-B796-4A1A-8F56-FBD3095384F3@oracle.com>
Message-ID: <56619705.1070006@oracle.com>



On 2015-12-04 12:33, Magnus Ihse Bursie wrote:
> Just a quick reply, I haven't looked at the new webrev yet.
>
> 4 dec. 2015 kl. 10:57 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>
>>> I'm a bit curious why this fix was needed. I thought one of the idea with BASIC_FIXUP_PATH was to guarantee that we pointed to an existing directory?
>> The documentation only says path, which I interpret as either a file or dir.
> Hm. I think the intention was to verify an existing directory. I agree that the name and documentation does not properly reflect this. Can you please verify other users of this function, if they are all indeed looking for directories? I'm just worried that this change will break the other uses, where it's supposed that a proper, existing directory is returned. Can't you break out common functionality and split this into two, a BASIC_FIXUP_DIR for the current functionality, and a looser version that just verifies a path, be it a file or not?
I really don't see how it could break anything. If you look a bit 
further up, there is already a test that checks if the input "path" is 
either a file or a dir, and if not prints an error. All I'm changing is 
so the rewrite works both in both the file and dir case.

/Erik


From erik.joelsson at oracle.com  Fri Dec  4 13:42:17 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 4 Dec 2015 14:42:17 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <491F5FF3-727E-440E-B938-66EB40551FF1@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com> <566163DC.9090101@oracle.com>
	<491F5FF3-727E-440E-B938-66EB40551FF1@oracle.com>
Message-ID: <56619839.5000701@oracle.com>



On 2015-12-04 12:50, Magnus Ihse Bursie wrote:
> Comments inline.
>
> I see. I'm fine with this. Just one note, if you had 
> jab_url=$jab_server/$data_string, maybe this should be more obvious. 
> And it's a nice bit of DRY. 
Sure, seems reasonable.
>>>
>>>> 144 *       // For certain dependencies where a legacy distribution mechanism is
>>>> 145  *       // already i place, the "javare" server layout is also supported
>>>>
>>>> "in place". Also, missing period.
>>>>
>>>> 150  *       // buildnumber (optional), files and checksumfile is possible for
>>>>
>>>> "build number", "checksum file"
>>>>
>>>> *       // aritfacts following the standard layout.
>>>>
>>>> "artifacts"
>>>>
>>>> *       // For other files, use checksumpath and paths instead
>>>>
>>>> "checksum path"
>>>>
>>>> 62  * input.build_unix_os
>>>> 63  * input.build_unix_cpu
>>>> 66  * input.build_unix_platform
>>>>
>>>> What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
>>> Clarified
> I still think this is not so good. What does build_unix_os contain? "Windows" or "Cygwin"? Is it used only on Windows? And why "unix"? Is the whole reason for this to be able to separate 32 and 64 bit cygwin?
Yes, and it would apply the same if we were to use msys. On a 64bit 
windows, you can run either a 32bit or 64bit unix emulation layer. I 
thought unix_emulation_layer was a bit long so shortened it to unix. I 
agree the name is not good.
> In the build system, we have a notion of "os env", which is the same as "os" in most cases, but isn"cygwin" or "msys" on Windows. Maybe we should use the same terminology here, if we describe the same thing.
os_env only describes msys or cygwin, not the bitness. I need both to be 
able to pick the correct executables.

/Erik
> Except for the things I noted, your fixes look good.
>
> /Magnus
>



From varming at gmail.com  Fri Dec  4 15:43:31 2015
From: varming at gmail.com (Carsten Varming)
Date: Fri, 4 Dec 2015 10:43:31 -0500
Subject: Running native code test
In-Reply-To: <C3BB4C1F-8CF5-413E-A22C-B408BDB182AE@oracle.com>
References: <CAP_pwnW8S_yuFQgbbuP3S9AMo9c6uag7u9ZN1RsEtwH9k=uvQg@mail.gmail.com>
	<565CCAE4.2080905@oracle.com>
	<CAP_pwnXBerMzSG8aH6cU=AQ4wR7oSqN-CSgcgyZXMeE6YtQLqQ@mail.gmail.com>
	<565D4BA5.2030704@oracle.com>
	<CAP_pwnUmr5h3MnOsn-BRwfpFFsb_w9RudKzVdQgBTN7RNBwk8Q@mail.gmail.com>
	<565FEBF4.7070506@oracle.com>
	<CAP_pwnVgiFW5aSZGhkD4F8NVw_L7wgsOTXgtB7nY8adnYD3DXw@mail.gmail.com>
	<C3BB4C1F-8CF5-413E-A22C-B408BDB182AE@oracle.com>
Message-ID: <CAP_pwnXEPHz4geUV6mj_3RYWt4x-KLqS_7rPW6x4CV2ODBS7fA@mail.gmail.com>

Dear Steffan,

On Fri, Dec 4, 2015 at 2:20 AM, Staffan Larsen <staffan.larsen at oracle.com>
wrote:

> Why is it a problem having executables and libraries in the same
> directory? It was a design choice we made to make things simpler.


It is a consistency problem. There would be no problem if this was the
common case, but it is a special case and anyone looking at this end up
paying for the special case. IMHO there is no need for this special case.

Carsten



>
> /Staffan
>
> > On 3 dec. 2015, at 18:13, Carsten Varming <varming at gmail.com> wrote:
> >
> > Dear David,
> >
> > I think I finally understand what is going on now. :)
> >
> > The command "make build-test-hotspot-jtreg-native" populates
> > $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ with ".so" files
> using
> > sub-directories of
> $(OUTPUTDIR)/support/test/hotspot/jtreg/native/support/
> > as scratch space for each test.
> >
> > The command "make test-image-hotspot-jtreg-native" (which I didn't run in
> > my sequence of commands above) copies all files
> > in $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/
> > to $(OUTPUTDIR)/images/test/hotspot/jtreg/native/ . Notice the lacking
> > "/lib" in the target.
> >
> > Jtreg is passed the parameter
> > "-nativepath:$(TESTNATIVE_DIR)/hotspot/jtreg/native". Jtreg then use the
> > native path to set both system properties: test.nativepath and
> > java.library.path.
> >
> > This leaves a lot to be desired. Jtreg expects all library files and
> > executables to be in the same directory (there are no executables in the
> > hotspot tests, but the jdk contains one). There is separation between
> > libraries and executables everywhere except
> > in $(OUTPUTDIR)/images/test/{hotspot,jdk}/jtreg/native/ because jtreg and
> > jdk/test/native_sanity/simplenativelauncher/ProgramTest.java expect
> > executables to be in the same directory as libraries. I have never seen
> > that before. Notice that this makes the step copying the executables into
> > the images sub-directory mandatory.
> >
> > The right thing seems to be to fix jtreg to maintain separation.
> Something
> > as simple as setting java.library.path to test.nativepath + "/lib" and
> > force a standard layout with bin and lib sub-directories would be an
> > improvement. Perhaps even extend jtreg it to allow separation between
> > libraries and executables from different tests (test A should not have
> > access to libraries from test B).
> >
> > I will drop this issue now that I have a way to execute tests containing
> > native code, but it would be nice if someone working on jtreg would make
> it
> > possible keep executables separate from libraries.
> >
> > Carsten
> >
> > On Thu, Dec 3, 2015 at 2:15 AM, David Holmes <david.holmes at oracle.com>
> > wrote:
> >
> >> cc'ing build-dev
> >>
> >> On 2/12/2015 1:28 AM, Carsten Varming wrote:
> >>
> >>> Dear David,
> >>>
> >>> See inline.
> >>>
> >>> On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.holmes at oracle.com
> >>> <mailto:david.holmes at oracle.com>> wrote:
> >>>
> >>>    Hi Carsten,
> >>>
> >>>    On 1/12/2015 8:21 AM, Carsten Varming wrote:
> >>>
> >>>        Dear Ioi,
> >>>
> >>>        Absolutely,
> >>>
> >>>        diff -r 7606b8556225 test/Makefile
> >>>        --- a/test/Makefile     Thu Nov 26 13:13:03 2015 +0100
> >>>        +++ b/test/Makefile     Mon Nov 30 17:20:30 2015 -0500
> >>>        @@ -156,7 +156,7 @@
> >>>             TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
> >>>           endif
> >>>           ifdef TESTNATIVE_DIR
> >>>        -  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
> >>>        "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
> >>>        +  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
> >>>        "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
> >>>           endif
> >>>
> >>>
> >>>    In hotspot/make/test/JtregNative.gmk we have:
> >>>
> >>>    BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
> >>>    $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native
> >>>
> >>>
> >>> The SetupTestFilesCompilation macro adds the subdirectory "lib" to the
> >>> path such that the ".so" files (or ".dylib" files) end up in
> >>> $(BUILD_OUTPUT)/support/test/hotspot/jtreg/native/lib.
> >>>
> >>
> >> Thanks for that. Tracing through these makefile macros is far too
> painful.
> >> I wish there were some way to see what they looked like once expanded.
> >>
> >>    so the above patch should not be needed.
> >>>
> >>>
> >>> Without the patch the following sequence of commands fails:
> >>> sh configure --enable-debug
> >>> make images
> >>> make build-test-hotspot-jtreg-native
> >>> cd hotspot/test
> >>> make TESTDIRS=runtime/SameObject
> >>>
> >>>
> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
> >>> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
> >>> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
> >>> PRODUCT_HOME=$JAVA_HOME jtreg_tests
> >>>
> >>> TEST RESULT: Failed. Execution failed: `main' threw exception:
> >>> java.lang.UnsatisfiedLinkError: no SameObject in java.library.path
> >>>
> >>> and java.library.path is defined
> >>> by:
> >>>
> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native
> >>>
> >>
> >> What I see in a JPRT build is simply:
> >>
> >> (cd /scratch/hotspot/make/test && make  -r -R -I /scratch/make/common
> >> SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk
> >> MAKE_LOG_FLAGS="" LOG_LEVEL=debug -f JtregNative.gmk \
> >>    test-image-hotspot-jtreg-native)
> >>
> >>
> >>> On the other hand, with the patch the test runs fine. Looking at
> >>> SameObject.jtr I can
> >>> see:
> >>>
> -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x86_64-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib,
> >>> i.e., "/lib" is appended to the path and the test pass.
> >>>
> >>> So I wonder, are these tests run by JPRT? And if they are, then what I
> >>> am doing wrong?
> >>>
> >>
> >> Yes they are run (or some subset thereof). The -nativepath that gets
> >> passed to jtreg does not include a lib component.
> >>
> >> I'm afraid I don't know what is going wrong.
> >>
> >> David
> >> -----
> >>
> >> BTW. This paths above are taken from runs on my mac. The problem also
> >>> occurs on my Linux desktop.
> >>>
> >>> Carsten
> >>>
> >>>    David
> >>>    -----
> >>>
> >>>
> >>>
> >>>
> >>>           # Expect JPRT to set JPRT_ARCHIVE_BUNDLE (path to zip bundle
> >>>        for results)
> >>>
> >>>        Carsten
> >>>
> >>>        On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi.lam at oracle.com
> >>>        <mailto:ioi.lam at oracle.com>> wrote:
> >>>
> >>>            Your patch seems to have been stripped by the mailer. Is it
> >>>            possible to
> >>>            just include it as plain text in the e-mail?
> >>>
> >>>            Thanks
> >>>            - Ioi
> >>>
> >>>
> >>>            On 11/30/15 1:34 PM, Carsten Varming wrote:
> >>>
> >>>                Hi everyone,
> >>>
> >>>                I was recently trying to run some tests that use native
> >>>                code, e.g.,
> >>>                hotspot/runtime/SameObject/SameObject.java and found
> >>>                that I had to apply
> >>>                the attached diff to get the tests to work.
> >>>
> >>>                I am doing something wrong or is this a trivial bug?
> >>>
> >>>                Carsten
> >>>
> >>>
> >>>
> >>>
> >>>
>
>


From erik.joelsson at oracle.com  Fri Dec  4 17:14:43 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 4 Dec 2015 18:14:43 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <56619839.5000701@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com> <566163DC.9090101@oracle.com>
	<491F5FF3-727E-440E-B938-66EB40551FF1@oracle.com>
	<56619839.5000701@oracle.com>
Message-ID: <5661CA03.7070403@oracle.com>



On 2015-12-04 14:42, Erik Joelsson wrote:
>
>
> On 2015-12-04 12:50, Magnus Ihse Bursie wrote:
>
>>>>
>>>>> 144 *       // For certain dependencies where a legacy 
>>>>> distribution mechanism is
>>>>> 145  *       // already i place, the "javare" server layout is 
>>>>> also supported
>>>>>
>>>>> "in place". Also, missing period.
>>>>>
>>>>> 150  *       // buildnumber (optional), files and checksumfile is 
>>>>> possible for
>>>>>
>>>>> "build number", "checksum file"
>>>>>
>>>>> *       // aritfacts following the standard layout.
>>>>>
>>>>> "artifacts"
>>>>>
>>>>> *       // For other files, use checksumpath and paths instead
>>>>>
>>>>> "checksum path"
>>>>>
>>>>> 62  * input.build_unix_os
>>>>> 63  * input.build_unix_cpu
>>>>> 66  * input.build_unix_platform
>>>>>
>>>>> What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
>>>> Clarified
>> I still think this is not so good. What does build_unix_os contain? 
>> "Windows" or "Cygwin"? Is it used only on Windows? And why "unix"? Is 
>> the whole reason for this to be able to separate 32 and 64 bit cygwin?
> Yes, and it would apply the same if we were to use msys. On a 64bit 
> windows, you can run either a 32bit or 64bit unix emulation layer. I 
> thought unix_emulation_layer was a bit long so shortened it to unix. I 
> agree the name is not good.
>> In the build system, we have a notion of "os env", which is the same 
>> as "os" in most cases, but isn"cygwin" or "msys" on Windows. Maybe we 
>> should use the same terminology here, if we describe the same thing.
> os_env only describes msys or cygwin, not the bitness. I need both to 
> be able to pick the correct executables.
>
Ok, I give in, here is a new version using "osenv" instead of "unix". I 
could not figure out a better combination of variable names than this.

http://cr.openjdk.java.net/~erikj/8136782/webrev.top.03/

/Erik


From asmundak at google.com  Fri Dec  4 17:55:18 2015
From: asmundak at google.com (Alexander Smundak)
Date: Fri, 4 Dec 2015 09:55:18 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <566147EF.4000109@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
Message-ID: <CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>

I am not convinced that increasing the complexity of the already quite
intricate build
machinery to avoid three additional checks in the source file is the
right trade-off.

Sasha

On Thu, Dec 3, 2015 at 11:59 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 4/12/2015 4:29 AM, Alexander Smundak wrote:
>>
>> On Wed, Dec 2, 2015 at 10:30 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> agent code:
>>>
>>> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and
>>> -Dppc64le, such that you don't need to check for either being defined ??
>>
>> You mean, add -Dppc64 to the compilation flags explicitly if the value
>> of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'?
>
>
> Yes. Is that feasible?
>
> Thanks,
> David
>
>> Sasha
>>
>


From chris.plummer at oracle.com  Fri Dec  4 21:00:21 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Fri, 4 Dec 2015 13:00:21 -0800
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
Message-ID: <5661FEE5.2040108@oracle.com>

Hello,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8144677
http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/

Tested with JPRT with:
   ? "-testset hotspot"
   ? "-testset svc"
   ? "-testset chris" from the example custom testset provided in the CR.
   ? no testset specified

BTW, if anyone knows of an "include" mechanism for jprt.properties, 
please let me know. Although that won't change the need for the above 
changes, it would make it possible to put custom testsets in a file 
rather than having to paste them in your ~/.jprt.properties file.

thanks,

Chris




From david.holmes at oracle.com  Sun Dec  6 23:52:42 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Dec 2015 09:52:42 +1000
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <5661FEE5.2040108@oracle.com>
References: <5661FEE5.2040108@oracle.com>
Message-ID: <5664CA4A.1090704@oracle.com>

Hi Chris,

On 5/12/2015 7:00 AM, Chris Plummer wrote:
> Hello,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8144677
> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>
> Tested with JPRT with:
>    ? "-testset hotspot"
>    ? "-testset svc"
>    ? "-testset chris" from the example custom testset provided in the CR.
>    ? no testset specified

Looks good!

> BTW, if anyone knows of an "include" mechanism for jprt.properties,

Properties files do not have an include mechanism. See:

http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader-

Thanks,
David

> please let me know. Although that won't change the need for the above
> changes, it would make it possible to put custom testsets in a file
> rather than having to paste them in your ~/.jprt.properties file.
>
> thanks,
>
> Chris
>
>


From david.holmes at oracle.com  Mon Dec  7 01:08:09 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Dec 2015 11:08:09 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
Message-ID: <5664DBF9.7010708@oracle.com>

On 5/12/2015 3:55 AM, Alexander Smundak wrote:
> I am not convinced that increasing the complexity of the already quite
> intricate build
> machinery to avoid three additional checks in the source file is the
> right trade-off.

Does that mean you looked at how to achieve this?

I think there is a more general issue that a ppc64le build is-a ppc64 
build, so the latter should always be defined.

David
-----

> Sasha
>
> On Thu, Dec 3, 2015 at 11:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 4/12/2015 4:29 AM, Alexander Smundak wrote:
>>>
>>> On Wed, Dec 2, 2015 at 10:30 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> agent code:
>>>>
>>>> I'm still unclear why you can't, or shouldn't, pass through -Dppc64 and
>>>> -Dppc64le, such that you don't need to check for either being defined ??
>>>
>>> You mean, add -Dppc64 to the compilation flags explicitly if the value
>>> of the OPENJDK_TARGET_CPU_LEGACY is 'ppc64le'?
>>
>>
>> Yes. Is that feasible?
>>
>> Thanks,
>> David
>>
>>> Sasha
>>>
>>


From erik.joelsson at oracle.com  Mon Dec  7 08:33:08 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 7 Dec 2015 09:33:08 +0100
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <5661FEE5.2040108@oracle.com>
References: <5661FEE5.2040108@oracle.com>
Message-ID: <56654444.9050505@oracle.com>



On 2015-12-04 22:00, Chris Plummer wrote:
> Hello,
>
> Please review the following:
>
> https://bugs.openjdk.java.net/browse/JDK-8144677
> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>
> Tested with JPRT with:
>   ? "-testset hotspot"
>   ? "-testset svc"
>   ? "-testset chris" from the example custom testset provided in the CR.
>   ? no testset specified
>
> BTW, if anyone knows of an "include" mechanism for jprt.properties, 
> please let me know. Although that won't change the need for the above 
> changes, it would make it possible to put custom testsets in a file 
> rather than having to paste them in your ~/.jprt.properties file.
>
JPRT properties files are pretty special, but to my knowledge, there is 
no include mechanism. I don't think it would be hard to implement though.

/Erik



From david.holmes at oracle.com  Mon Dec  7 11:18:51 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Dec 2015 21:18:51 +1000
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <56654444.9050505@oracle.com>
References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com>
Message-ID: <56656B1B.2020107@oracle.com>

On 7/12/2015 6:33 PM, Erik Joelsson wrote:
>
>
> On 2015-12-04 22:00, Chris Plummer wrote:
>> Hello,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8144677
>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>>
>> Tested with JPRT with:
>>   ? "-testset hotspot"
>>   ? "-testset svc"
>>   ? "-testset chris" from the example custom testset provided in the CR.
>>   ? no testset specified
>>
>> BTW, if anyone knows of an "include" mechanism for jprt.properties,
>> please let me know. Although that won't change the need for the above
>> changes, it would make it possible to put custom testsets in a file
>> rather than having to paste them in your ~/.jprt.properties file.
>>
> JPRT properties files are pretty special, but to my knowledge, there is
> no include mechanism. I don't think it would be hard to implement though.

They aren't really special they just use Properties.loadFromStream (or 
something like that). To do an include mechanism you'd have to implement 
all the reading and parsing logic yourself.

David


> /Erik
>


From erik.joelsson at oracle.com  Mon Dec  7 11:39:25 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 7 Dec 2015 12:39:25 +0100
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <56656B1B.2020107@oracle.com>
References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com>
	<56656B1B.2020107@oracle.com>
Message-ID: <56656FED.5050105@oracle.com>



On 2015-12-07 12:18, David Holmes wrote:
> On 7/12/2015 6:33 PM, Erik Joelsson wrote:
>>
>>
>> On 2015-12-04 22:00, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8144677
>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>>>
>>> Tested with JPRT with:
>>>   ? "-testset hotspot"
>>>   ? "-testset svc"
>>>   ? "-testset chris" from the example custom testset provided in the 
>>> CR.
>>>   ? no testset specified
>>>
>>> BTW, if anyone knows of an "include" mechanism for jprt.properties,
>>> please let me know. Although that won't change the need for the above
>>> changes, it would make it possible to put custom testsets in a file
>>> rather than having to paste them in your ~/.jprt.properties file.
>>>
>> JPRT properties files are pretty special, but to my knowledge, there is
>> no include mechanism. I don't think it would be hard to implement 
>> though.
>
> They aren't really special they just use Properties.loadFromStream (or 
> something like that). To do an include mechanism you'd have to 
> implement all the reading and parsing logic yourself.
>
They are special in that there are a lot of constructs not normal to 
properties, like ${foo} expansion, weird conditionals and expanding 
variants {foo|bar}. None of these are order dependent however, meaning, 
it doesn't matter which order you put the properties in. The evaluation 
of all those things happens when a property is read, not when it is 
parsed. So the only reasonable implementation of include, at least as I 
see it, would be to read a file like now, check a special "include-file" 
property for new values and if so, read that file too.

/Erik
> David
>
>
>> /Erik
>>



From chris.plummer at oracle.com  Mon Dec  7 22:27:35 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 7 Dec 2015 14:27:35 -0800
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <5664CA4A.1090704@oracle.com>
References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com>
Message-ID: <566607D7.40909@oracle.com>

Thanks David!

Can I get a second reviewer please?

thanks,

Chris

On 12/6/15 3:52 PM, David Holmes wrote:
> Hi Chris,
>
> On 5/12/2015 7:00 AM, Chris Plummer wrote:
>> Hello,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8144677
>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>>
>> Tested with JPRT with:
>>    ? "-testset hotspot"
>>    ? "-testset svc"
>>    ? "-testset chris" from the example custom testset provided in the 
>> CR.
>>    ? no testset specified
>
> Looks good!
>
>> BTW, if anyone knows of an "include" mechanism for jprt.properties,
>
> Properties files do not have an include mechanism. See:
>
> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- 
>
>
> Thanks,
> David
>
>> please let me know. Although that won't change the need for the above
>> changes, it would make it possible to put custom testsets in a file
>> rather than having to paste them in your ~/.jprt.properties file.
>>
>> thanks,
>>
>> Chris
>>
>>




From mikael.vidstedt at oracle.com  Mon Dec  7 23:22:24 2015
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 7 Dec 2015 15:22:24 -0800
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <566607D7.40909@oracle.com>
References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com>
	<566607D7.40909@oracle.com>
Message-ID: <566614B0.8020809@oracle.com>


Thumbs up!

Cheers,
Mikael

On 2015-12-07 14:27, Chris Plummer wrote:
> Thanks David!
>
> Can I get a second reviewer please?
>
> thanks,
>
> Chris
>
> On 12/6/15 3:52 PM, David Holmes wrote:
>> Hi Chris,
>>
>> On 5/12/2015 7:00 AM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8144677
>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>>>
>>> Tested with JPRT with:
>>>    ? "-testset hotspot"
>>>    ? "-testset svc"
>>>    ? "-testset chris" from the example custom testset provided in 
>>> the CR.
>>>    ? no testset specified
>>
>> Looks good!
>>
>>> BTW, if anyone knows of an "include" mechanism for jprt.properties,
>>
>> Properties files do not have an include mechanism. See:
>>
>> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- 
>>
>>
>> Thanks,
>> David
>>
>>> please let me know. Although that won't change the need for the above
>>> changes, it would make it possible to put custom testsets in a file
>>> rather than having to paste them in your ~/.jprt.properties file.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>>
>
>



From chris.plummer at oracle.com  Tue Dec  8 01:06:34 2015
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 7 Dec 2015 17:06:34 -0800
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <566614B0.8020809@oracle.com>
References: <5661FEE5.2040108@oracle.com> <5664CA4A.1090704@oracle.com>
	<566607D7.40909@oracle.com> <566614B0.8020809@oracle.com>
Message-ID: <56662D1A.7060205@oracle.com>

Thanks Mikael!

Chris

On 12/7/15 3:22 PM, Mikael Vidstedt wrote:
>
> Thumbs up!
>
> Cheers,
> Mikael
>
> On 2015-12-07 14:27, Chris Plummer wrote:
>> Thanks David!
>>
>> Can I get a second reviewer please?
>>
>> thanks,
>>
>> Chris
>>
>> On 12/6/15 3:52 PM, David Holmes wrote:
>>> Hi Chris,
>>>
>>> On 5/12/2015 7:00 AM, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> Please review the following:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8144677
>>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>>>>
>>>> Tested with JPRT with:
>>>>    ? "-testset hotspot"
>>>>    ? "-testset svc"
>>>>    ? "-testset chris" from the example custom testset provided in 
>>>> the CR.
>>>>    ? no testset specified
>>>
>>> Looks good!
>>>
>>>> BTW, if anyone knows of an "include" mechanism for jprt.properties,
>>>
>>> Properties files do not have an include mechanism. See:
>>>
>>> http://docs.oracle.com/javase/8/docs/api/java/util/Properties.html#load-java.io.Reader- 
>>>
>>>
>>> Thanks,
>>> David
>>>
>>>> please let me know. Although that won't change the need for the above
>>>> changes, it would make it possible to put custom testsets in a file
>>>> rather than having to paste them in your ~/.jprt.properties file.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>>
>>
>>
>




From asmundak at google.com  Tue Dec  8 03:44:55 2015
From: asmundak at google.com (Alexander Smundak)
Date: Mon, 7 Dec 2015 19:44:55 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <5664DBF9.7010708@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
Message-ID: <CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>

It is achievable by adding a small ppc-specific check to the
common/autoconf/platform.m4:

@@ -282,6 +282,8 @@
   elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
"x$OPENJDK_TARGET_CPU" = xx86_64; then
     # On all platforms except MacOSX replace x86_64 with amd64.
     OPENJDK_TARGET_CPU_LEGACY="amd64"
+  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
+    OPENJDK_TARGET_CPU_LEGACY="ppc64"
   fi
   AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)

However, there is a code in make/Images.gmk using  OPENJDK_TARGET_CPU_LEGACY
  $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
so that the 'release' file in the image directory will now have
JAVA_VERSION="9"
JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
OS_NAME="Linux"
OS_VERSION="2.6"
OS_ARCH="ppc64"
        ^^^^^^^^
SOURCE=..,

instead of "ppc64le".

If someone can tell me which other variable I should use to achieve
that without changing the contents of the 'release' file on other
platforms, I'll be grateful.


From david.holmes at oracle.com  Tue Dec  8 03:49:02 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Dec 2015 13:49:02 +1000
Subject: [RFR] (XS) 8144677: jprt.properties should allow creating a user
	specified testset with custom build flavors and build targets
In-Reply-To: <56656FED.5050105@oracle.com>
References: <5661FEE5.2040108@oracle.com> <56654444.9050505@oracle.com>
	<56656B1B.2020107@oracle.com> <56656FED.5050105@oracle.com>
Message-ID: <5666532E.1050205@oracle.com>


On 7/12/2015 9:39 PM, Erik Joelsson wrote:
>
>
> On 2015-12-07 12:18, David Holmes wrote:
>> On 7/12/2015 6:33 PM, Erik Joelsson wrote:
>>>
>>>
>>> On 2015-12-04 22:00, Chris Plummer wrote:
>>>> Hello,
>>>>
>>>> Please review the following:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8144677
>>>> http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/
>>>>
>>>> Tested with JPRT with:
>>>>   ? "-testset hotspot"
>>>>   ? "-testset svc"
>>>>   ? "-testset chris" from the example custom testset provided in the
>>>> CR.
>>>>   ? no testset specified
>>>>
>>>> BTW, if anyone knows of an "include" mechanism for jprt.properties,
>>>> please let me know. Although that won't change the need for the above
>>>> changes, it would make it possible to put custom testsets in a file
>>>> rather than having to paste them in your ~/.jprt.properties file.
>>>>
>>> JPRT properties files are pretty special, but to my knowledge, there is
>>> no include mechanism. I don't think it would be hard to implement
>>> though.
>>
>> They aren't really special they just use Properties.loadFromStream (or
>> something like that). To do an include mechanism you'd have to
>> implement all the reading and parsing logic yourself.
>>
> They are special in that there are a lot of constructs not normal to
> properties, like ${foo} expansion, weird conditionals and expanding
> variants {foo|bar}.

Yes but that is what JPRT does after loading the properties. It then 
post processes them to do expansion etc.

> None of these are order dependent however, meaning,
> it doesn't matter which order you put the properties in. The evaluation
> of all those things happens when a property is read, not when it is
> parsed. So the only reasonable implementation of include, at least as I
> see it, would be to read a file like now, check a special "include-file"
> property for new values and if so, read that file too.

Yeah I guess that would work. Though there are some ordering issues as 
properties read from later files can override values read from earlier 
ones. In essence this would be a way to add another properties file to 
the set of files read (jprt distribution, repo, user). But if you want 
to do that its easier to just add a command-line arg to specify the 
additional file.

Anyway this is going somewhat OT for Chris's change. If someone thinks 
allowing an additional custom properties file is useful then can file a RFE.

Cheers,
David

> /Erik
>> David
>>
>>
>>> /Erik
>>>
>


From david.holmes at oracle.com  Tue Dec  8 04:46:42 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Dec 2015 14:46:42 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
Message-ID: <566660B2.4030100@oracle.com>

On 8/12/2015 1:44 PM, Alexander Smundak wrote:
> It is achievable by adding a small ppc-specific check to the
> common/autoconf/platform.m4:
>
> @@ -282,6 +282,8 @@
>     elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>       # On all platforms except MacOSX replace x86_64 with amd64.
>       OPENJDK_TARGET_CPU_LEGACY="amd64"
> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>     fi
>     AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>
> However, there is a code in make/Images.gmk using  OPENJDK_TARGET_CPU_LEGACY
>    $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
> so that the 'release' file in the image directory will now have
> JAVA_VERSION="9"
> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
> OS_NAME="Linux"
> OS_VERSION="2.6"
> OS_ARCH="ppc64"
>          ^^^^^^^^
> SOURCE=..,
>
> instead of "ppc64le".
>
> If someone can tell me which other variable I should use to achieve
> that without changing the contents of the 'release' file on other
> platforms, I'll be grateful.

Okay never mind - and thanks for looking into this. I see now this is 
set via:

./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK 
-DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"

so there is no way to add a second value without introducing some 
additional variable. At the hotspot level it could be handled 
differently if we had a platform_ppc64le file, as it could just be added 
to the SYSDEFS.

Thanks,
David


From erik.joelsson at oracle.com  Tue Dec  8 10:31:57 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 8 Dec 2015 11:31:57 +0100
Subject: RFR: JDK-8144857: Intermittent build error building
	jdk/src/demo/solaris/jni/Poller/Poller.c
Message-ID: <5666B19D.8090005@oracle.com>

Hello,

Please review this small fix for a misspelled dependency causing a race 
when building on Solaris.

Bug: https://bugs.openjdk.java.net/browse/JDK-8144857
Patch:
diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
--- a/make/CompileDemos.gmk
+++ b/make/CompileDemos.gmk
@@ -459,7 +459,7 @@
    # We can only compile native code after java has been compiled (since we
    # depend on generated .h files)
    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
-      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
+      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)

    # Copy to image
    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \


/Erik


From david.holmes at oracle.com  Tue Dec  8 10:46:52 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Dec 2015 20:46:52 +1000
Subject: RFR: JDK-8144857: Intermittent build error building
	jdk/src/demo/solaris/jni/Poller/Poller.c
In-Reply-To: <5666B19D.8090005@oracle.com>
References: <5666B19D.8090005@oracle.com>
Message-ID: <5666B51C.4020805@oracle.com>

Looks good!

Thanks,
David

On 8/12/2015 8:31 PM, Erik Joelsson wrote:
> Hello,
>
> Please review this small fix for a misspelled dependency causing a race
> when building on Solaris.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144857
> Patch:
> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
> --- a/make/CompileDemos.gmk
> +++ b/make/CompileDemos.gmk
> @@ -459,7 +459,7 @@
>     # We can only compile native code after java has been compiled
> (since we
>     # depend on generated .h files)
>     $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
> +      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
>
>     # Copy to image
>     $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>
>
> /Erik


From magnus.ihse.bursie at oracle.com  Tue Dec  8 14:52:15 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2015 15:52:15 +0100
Subject: RFR: JDK-8136782: Introduce a build/configure wrapper
In-Reply-To: <5661CA03.7070403@oracle.com>
References: <56605F6D.3030103@oracle.com> <5660ADA6.70604@oracle.com>
	<56616373.4010005@oracle.com> <566163DC.9090101@oracle.com>
	<491F5FF3-727E-440E-B938-66EB40551FF1@oracle.com>
	<56619839.5000701@oracle.com> <5661CA03.7070403@oracle.com>
Message-ID: <5666EE9F.6030906@oracle.com>

On 2015-12-04 18:14, Erik Joelsson wrote:
>
>
> On 2015-12-04 14:42, Erik Joelsson wrote:
>>
>>
>> On 2015-12-04 12:50, Magnus Ihse Bursie wrote:
>>
>>>>>
>>>>>> 144 *       // For certain dependencies where a legacy 
>>>>>> distribution mechanism is
>>>>>> 145  *       // already i place, the "javare" server layout is 
>>>>>> also supported
>>>>>>
>>>>>> "in place". Also, missing period.
>>>>>>
>>>>>> 150  *       // buildnumber (optional), files and checksumfile is 
>>>>>> possible for
>>>>>>
>>>>>> "build number", "checksum file"
>>>>>>
>>>>>> *       // aritfacts following the standard layout.
>>>>>>
>>>>>> "artifacts"
>>>>>>
>>>>>> *       // For other files, use checksumpath and paths instead
>>>>>>
>>>>>> "checksum path"
>>>>>>
>>>>>> 62  * input.build_unix_os
>>>>>> 63  * input.build_unix_cpu
>>>>>> 66  * input.build_unix_platform
>>>>>>
>>>>>> What is build_unix_cpu, etc? Sounds fully incomprehensible to me. :)
>>>>> Clarified
>>> I still think this is not so good. What does build_unix_os contain? 
>>> "Windows" or "Cygwin"? Is it used only on Windows? And why "unix"? 
>>> Is the whole reason for this to be able to separate 32 and 64 bit 
>>> cygwin?
>> Yes, and it would apply the same if we were to use msys. On a 64bit 
>> windows, you can run either a 32bit or 64bit unix emulation layer. I 
>> thought unix_emulation_layer was a bit long so shortened it to unix. 
>> I agree the name is not good.
>>> In the build system, we have a notion of "os env", which is the same 
>>> as "os" in most cases, but isn"cygwin" or "msys" on Windows. Maybe 
>>> we should use the same terminology here, if we describe the same thing.
>> os_env only describes msys or cygwin, not the bitness. I need both to 
>> be able to pick the correct executables.
>>
> Ok, I give in, here is a new version using "osenv" instead of "unix". 
> I could not figure out a better combination of variable names than this.
>
> http://cr.openjdk.java.net/~erikj/8136782/webrev.top.03/

Thanks. :)

Looks good to me now.

/Magnus
>
> /Erik



From asmundak at google.com  Tue Dec  8 17:44:18 2015
From: asmundak at google.com (Alexander Smundak)
Date: Tue, 8 Dec 2015 09:44:18 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <566660B2.4030100@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
Message-ID: <CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>

Thank you for the review.
If everyone involved is satisfied with the patch, I need a sponsor.

Sasha

On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>
>> It is achievable by adding a small ppc-specific check to the
>> common/autoconf/platform.m4:
>>
>> @@ -282,6 +282,8 @@
>>     elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>       # On all platforms except MacOSX replace x86_64 with amd64.
>>       OPENJDK_TARGET_CPU_LEGACY="amd64"
>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>     fi
>>     AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>
>> However, there is a code in make/Images.gmk using
>> OPENJDK_TARGET_CPU_LEGACY
>>    $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
>> so that the 'release' file in the image directory will now have
>> JAVA_VERSION="9"
>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>> OS_NAME="Linux"
>> OS_VERSION="2.6"
>> OS_ARCH="ppc64"
>>          ^^^^^^^^
>> SOURCE=..,
>>
>> instead of "ppc64le".
>>
>> If someone can tell me which other variable I should use to achieve
>> that without changing the contents of the 'release' file on other
>> platforms, I'll be grateful.
>
>
> Okay never mind - and thanks for looking into this. I see now this is set
> via:
>
> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>
> so there is no way to add a second value without introducing some additional
> variable. At the hotspot level it could be handled differently if we had a
> platform_ppc64le file, as it could just be added to the SYSDEFS.
>
> Thanks,
> David


From yasuenag at gmail.com  Wed Dec  9 00:31:19 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 9 Dec 2015 09:31:19 +0900
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <565FE685.4020601@oracle.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
	<565FE685.4020601@oracle.com>
Message-ID: <56677657.1000107@gmail.com>

Hi,

I've uploaded a new webrev:
   http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.06/


> Can you reinstate the comment:
>
>   581   # This must be done after the toolchain is setup, since we're looking at objcopy.
>
> as this constraint still exists.

I've fixed.

> I would have hoped that the deprecation macro enabled you to inform the user what the replacement is as per the comments! This seems unsatisfactory. :(

I added one more argument to BASIC_DEPRECATED_ARG_ENABLE to show message.
However, I'm not certain this change should be filed another issue or not.


Thanks,

Yasumasa


On 2015/12/03 15:51, David Holmes wrote:
> On 1/12/2015 12:34 AM, Yasumasa Suenaga wrote:
>> Hi Magnus,
>>
>> I've uploaded new webrev:
>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.05/
>
> common/autoconf/jdk-options.m4
>
> Can you reinstate the comment:
>
>   581   # This must be done after the toolchain is setup, since we're looking at objcopy.
>
> as this constraint still exists.
>
> It would be nice if the external and zipped cases could somehow be shared so that we don't have to duplicate everything just to alter the value of a single variable.
>
>   634   # --enable-zip-debug-info is deprecated.
>   635   # Please use --with-debug-symbols=zipped .
>   636   BASIC_DEPRECATED_ARG_ENABLE(zip-debug-info, zip_debug_info)
>
> I would have hoped that the deprecation macro enabled you to inform the user what the replacement is as per the comments! This seems unsatisfactory. :(
>
> I'm assuming there is no change to the default behaviour if none of these options are specified. I'm unclear whether we will need to coordinate this change with any internal processes that might explicitly be using the deprecated options - I think Magnus should have a better idea about that.
>
> Thanks,
> David
> -----
>
>>> If we do implement this flag, it should work as expected. If you
>>> believe this is too hard to get right, I'm alright with fixing this as
>>> a separate bug.
>>
>> Okay, I removed --enable-java-debug-symbols in this webrev.
>> I will file to JBS and try to create patch for it after this issue.
>>
>>
>>> That is, have you tried building with the four different values of
>>> --with-native-debug-symbols and verified that the result is indeed as
>>> you specified?
>>
>> Of course, I've checked all pattern of --with-native-debug-symbols.
>> I ran readelf -S for libjvm, libnio, libsaproc, and java command.
>> I checked debug section (.debug_info, and more) in ELF binaries.
>>
>>
>>> Just by my quick glance I can already spot what I believe is a
>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>> reasonably be no_strip.
>>
>> I've fixed in this webrev.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/11/30 21:26, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2015-11-26 15:19, Yasumasa Suenaga wrote:
>>>> I uploaded a new webrev:
>>>>   http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/
>>>>
>>>> I implemented --with-native-debug-symbols and
>>>> --enable-java-debug-symbols in it.
>>>> And I deprecated --enable-debug-symbols and --enable-zip-debug-info .
>>>
>>> Hi Yasumasa,
>>>
>>> I apologize I have not been able to spend more time on this. I still
>>> only had time to take a short glimpse, but I found a few issues anyway.
>>>
>>> First, the new -enable-java-debug-symbols is problematic. If you build
>>> with "--enable-debug --disable-java-debug-symbols", then this implies
>>> that you would get a build without java debug symbols. However, this
>>> will not happen, since changing debug level wil enable java debug
>>> symbols, but the new java-debug-symbols flag will not manage to
>>> disable this.
>>>
>>> If we do implement this flag, it should work as expected. If you
>>> believe this is too hard to get right, I'm alright with fixing this as
>>> a separate bug.
>>>
>>> Second, all the flags we use to manage this internally makes me
>>> nervous. :) Are you sure you're getting them right? That is, have you
>>> tried building with the four different values of
>>> --with-native-debug-symbols and verified that the result is indeed as
>>> you specified? You'd need to check both libjvm.so and at least a jdk
>>> library, like libjava.so or so, since they use different build system
>>> and flags.
>>>
>>> Just by my quick glance I can already spot what I believe is a
>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>> reasonably be no_strip. (I'd be surprised if strip was run if I
>>> compiled without debug symbols).
>>>
>>> Other than that, I believe this patch is starting to get ready.
>>>
>>> /Magnus
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2015/11/25 23:52, Yasumasa Suenaga wrote:
>>>>> Hi Magnus,
>>>>>
>>>>>> --with-java-debug-symbols=none,all
>>>>>> (or "none,internal" for consistency).
>>>>>
>>>>> Can I change this option to --enable-java-debug-symbols ?
>>>>> This value set to none or all. So I think that we should use
>>>>> AC_ARG_ENABLE for it.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2015/11/25 23:35, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-21 14:12, Yasumasa Suenaga wrote:
>>>>>>>> My point with current proposal is that either it doesn't touch
>>>>>>>> the zipping because we already have an option for that; or it
>>>>>>>> should deprecate the existing option (now Erik has pointed out
>>>>>>>> that capability).
>>>>>>>
>>>>>>> I'm using BASIC_DEPRECATED_ARG_ENABLE for debug-symbols and
>>>>>>> zip-debug-info in new webrev:
>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.03/
>>>>>>>
>>>>>>> I had thought this new option as a wrapper for existing options.
>>>>>>> However, if current options should be deprecated, I will follow it.
>>>>>>
>>>>>> Hi Yasumasa,
>>>>>>
>>>>>> Sorry for the delay in my response.
>>>>>>
>>>>>> I had to go back and re-read the old discussions and my personal
>>>>>> notes about this. It turned out that some of the complications that
>>>>>> existed then is not relevant from Oracle's point of view anymore
>>>>>> (more specifically, stripping to several distinct levels). With
>>>>>> that complication gone, the basic case boils down to the three ways
>>>>>> of doing this:
>>>>>> 1) Compile without debug information ("none")
>>>>>> 2) Compile with debug information and keep it ("internal")
>>>>>> 3) Compile with debug information, copy it to an external file, and
>>>>>> strip the binary ("external")
>>>>>>
>>>>>> So far, so good. I agree with David Holmes that the zipping
>>>>>> complicates things somewhat. The problem here is two-fold: Firstly,
>>>>>> I believe that the "external" choice will be relevant to nobody (as
>>>>>> in, neither the community nor Oracle), and secondly, there have
>>>>>> been discussions of handling the external debuginfo differently
>>>>>> (namely, to move all debug info, unzipped, into a separate image,
>>>>>> and zip them all at once). It's a bit unfortunate if we create an
>>>>>> interface to configure that cannot grow properly with future changes.
>>>>>>
>>>>>> On the other hand, it does seem convenient to express the end
>>>>>> result for the Oracle build as "zipped" (or possibly
>>>>>> "external-zipped", to emphasize  the connection to "external"?).
>>>>>>
>>>>>> So I'm not sure what to think myself. But if David agrees that
>>>>>> adding "zipped" (or "external-zipped") to the new argument, and
>>>>>> deprecating the old, then I agree with it as well. :-)
>>>>>>
>>>>>> The second discussion here is the connection between java and
>>>>>> native debug symbols.
>>>>>>
>>>>>> Fact: We do not currently have a story for setting java debug
>>>>>> symbols. That's bad, and a regression as pointed out.
>>>>>> Fact: That does not mean it has to be fixed in this patch.
>>>>>>
>>>>>> I do think that java and native debug symbols are different things
>>>>>> and should be treated differently. But I also think we should have
>>>>>> configure arguments that show their similarity. So, I propose that
>>>>>> we have a
>>>>>> --with-native-debug-symbols=none,internal,external,zipped
>>>>>> as you propose, and then also a
>>>>>> --with-java-debug-symbols=none,all
>>>>>> (or "none,internal" for consistency).
>>>>>>
>>>>>> I think it would be nice if that flag could be implemented in the
>>>>>> same patch, but since it is a different thing I understand if you
>>>>>> want to leave it out. There is some added complication here, since
>>>>>> we already set -g for java compilation depending on debug level,
>>>>>> and the native debug symbol patch is obviously tricky as it is.
>>>>>>
>>>>>> /Magnus
>>>


From david.holmes at oracle.com  Wed Dec  9 03:10:23 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Dec 2015 13:10:23 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
Message-ID: <56679B9F.8030105@oracle.com>

I can sponsor for you Sasha. Just email me the changeset, or a link thereto.

Thanks,
David

On 9/12/2015 3:44 AM, Alexander Smundak wrote:
> Thank you for the review.
> If everyone involved is satisfied with the patch, I need a sponsor.
>
> Sasha
>
> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>>
>>> It is achievable by adding a small ppc-specific check to the
>>> common/autoconf/platform.m4:
>>>
>>> @@ -282,6 +282,8 @@
>>>      elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>>        # On all platforms except MacOSX replace x86_64 with amd64.
>>>        OPENJDK_TARGET_CPU_LEGACY="amd64"
>>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>>      fi
>>>      AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>>
>>> However, there is a code in make/Images.gmk using
>>> OPENJDK_TARGET_CPU_LEGACY
>>>     $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
>>> so that the 'release' file in the image directory will now have
>>> JAVA_VERSION="9"
>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>>> OS_NAME="Linux"
>>> OS_VERSION="2.6"
>>> OS_ARCH="ppc64"
>>>           ^^^^^^^^
>>> SOURCE=..,
>>>
>>> instead of "ppc64le".
>>>
>>> If someone can tell me which other variable I should use to achieve
>>> that without changing the contents of the 'release' file on other
>>> platforms, I'll be grateful.
>>
>>
>> Okay never mind - and thanks for looking into this. I see now this is set
>> via:
>>
>> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>>
>> so there is no way to add a second value without introducing some additional
>> variable. At the hotspot level it could be handled differently if we had a
>> platform_ppc64le file, as it could just be added to the SYSDEFS.
>>
>> Thanks,
>> David


From david.holmes at oracle.com  Wed Dec  9 04:12:39 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Dec 2015 14:12:39 +1000
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <56677657.1000107@gmail.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
	<565FE685.4020601@oracle.com> <56677657.1000107@gmail.com>
Message-ID: <5667AA37.6020409@oracle.com>

Hi,

On 9/12/2015 10:31 AM, Yasumasa Suenaga wrote:
> Hi,
>
> I've uploaded a new webrev:
>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.06/
>
>
>> Can you reinstate the comment:
>>
>>   581   # This must be done after the toolchain is setup, since we're
>> looking at objcopy.
>>
>> as this constraint still exists.
>
> I've fixed.
>
>> I would have hoped that the deprecation macro enabled you to inform
>> the user what the replacement is as per the comments! This seems
>> unsatisfactory. :(
>
> I added one more argument to BASIC_DEPRECATED_ARG_ENABLE to show message.
> However, I'm not certain this change should be filed another issue or not.

This seems good to me - and small enough to not warrant another issue.

But ultimately it is up to the build folk.

I have no further comments.

Thanks,
David

>
> Thanks,
>
> Yasumasa
>
>
> On 2015/12/03 15:51, David Holmes wrote:
>> On 1/12/2015 12:34 AM, Yasumasa Suenaga wrote:
>>> Hi Magnus,
>>>
>>> I've uploaded new webrev:
>>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.05/
>>
>> common/autoconf/jdk-options.m4
>>
>> Can you reinstate the comment:
>>
>>   581   # This must be done after the toolchain is setup, since we're
>> looking at objcopy.
>>
>> as this constraint still exists.
>>
>> It would be nice if the external and zipped cases could somehow be
>> shared so that we don't have to duplicate everything just to alter the
>> value of a single variable.
>>
>>   634   # --enable-zip-debug-info is deprecated.
>>   635   # Please use --with-debug-symbols=zipped .
>>   636   BASIC_DEPRECATED_ARG_ENABLE(zip-debug-info, zip_debug_info)
>>
>> I would have hoped that the deprecation macro enabled you to inform
>> the user what the replacement is as per the comments! This seems
>> unsatisfactory. :(
>>
>> I'm assuming there is no change to the default behaviour if none of
>> these options are specified. I'm unclear whether we will need to
>> coordinate this change with any internal processes that might
>> explicitly be using the deprecated options - I think Magnus should
>> have a better idea about that.
>>
>> Thanks,
>> David
>> -----
>>
>>>> If we do implement this flag, it should work as expected. If you
>>>> believe this is too hard to get right, I'm alright with fixing this as
>>>> a separate bug.
>>>
>>> Okay, I removed --enable-java-debug-symbols in this webrev.
>>> I will file to JBS and try to create patch for it after this issue.
>>>
>>>
>>>> That is, have you tried building with the four different values of
>>>> --with-native-debug-symbols and verified that the result is indeed as
>>>> you specified?
>>>
>>> Of course, I've checked all pattern of --with-native-debug-symbols.
>>> I ran readelf -S for libjvm, libnio, libsaproc, and java command.
>>> I checked debug section (.debug_info, and more) in ELF binaries.
>>>
>>>
>>>> Just by my quick glance I can already spot what I believe is a
>>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>>> reasonably be no_strip.
>>>
>>> I've fixed in this webrev.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2015/11/30 21:26, Magnus Ihse Bursie wrote:
>>>>
>>>>
>>>> On 2015-11-26 15:19, Yasumasa Suenaga wrote:
>>>>> I uploaded a new webrev:
>>>>>   http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/
>>>>>
>>>>> I implemented --with-native-debug-symbols and
>>>>> --enable-java-debug-symbols in it.
>>>>> And I deprecated --enable-debug-symbols and --enable-zip-debug-info .
>>>>
>>>> Hi Yasumasa,
>>>>
>>>> I apologize I have not been able to spend more time on this. I still
>>>> only had time to take a short glimpse, but I found a few issues anyway.
>>>>
>>>> First, the new -enable-java-debug-symbols is problematic. If you build
>>>> with "--enable-debug --disable-java-debug-symbols", then this implies
>>>> that you would get a build without java debug symbols. However, this
>>>> will not happen, since changing debug level wil enable java debug
>>>> symbols, but the new java-debug-symbols flag will not manage to
>>>> disable this.
>>>>
>>>> If we do implement this flag, it should work as expected. If you
>>>> believe this is too hard to get right, I'm alright with fixing this as
>>>> a separate bug.
>>>>
>>>> Second, all the flags we use to manage this internally makes me
>>>> nervous. :) Are you sure you're getting them right? That is, have you
>>>> tried building with the four different values of
>>>> --with-native-debug-symbols and verified that the result is indeed as
>>>> you specified? You'd need to check both libjvm.so and at least a jdk
>>>> library, like libjava.so or so, since they use different build system
>>>> and flags.
>>>>
>>>> Just by my quick glance I can already spot what I believe is a
>>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>>> reasonably be no_strip. (I'd be surprised if strip was run if I
>>>> compiled without debug symbols).
>>>>
>>>> Other than that, I believe this patch is starting to get ready.
>>>>
>>>> /Magnus
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2015/11/25 23:52, Yasumasa Suenaga wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>>> --with-java-debug-symbols=none,all
>>>>>>> (or "none,internal" for consistency).
>>>>>>
>>>>>> Can I change this option to --enable-java-debug-symbols ?
>>>>>> This value set to none or all. So I think that we should use
>>>>>> AC_ARG_ENABLE for it.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>> On 2015/11/25 23:35, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-11-21 14:12, Yasumasa Suenaga wrote:
>>>>>>>>> My point with current proposal is that either it doesn't touch
>>>>>>>>> the zipping because we already have an option for that; or it
>>>>>>>>> should deprecate the existing option (now Erik has pointed out
>>>>>>>>> that capability).
>>>>>>>>
>>>>>>>> I'm using BASIC_DEPRECATED_ARG_ENABLE for debug-symbols and
>>>>>>>> zip-debug-info in new webrev:
>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.03/
>>>>>>>>
>>>>>>>> I had thought this new option as a wrapper for existing options.
>>>>>>>> However, if current options should be deprecated, I will follow it.
>>>>>>>
>>>>>>> Hi Yasumasa,
>>>>>>>
>>>>>>> Sorry for the delay in my response.
>>>>>>>
>>>>>>> I had to go back and re-read the old discussions and my personal
>>>>>>> notes about this. It turned out that some of the complications that
>>>>>>> existed then is not relevant from Oracle's point of view anymore
>>>>>>> (more specifically, stripping to several distinct levels). With
>>>>>>> that complication gone, the basic case boils down to the three ways
>>>>>>> of doing this:
>>>>>>> 1) Compile without debug information ("none")
>>>>>>> 2) Compile with debug information and keep it ("internal")
>>>>>>> 3) Compile with debug information, copy it to an external file, and
>>>>>>> strip the binary ("external")
>>>>>>>
>>>>>>> So far, so good. I agree with David Holmes that the zipping
>>>>>>> complicates things somewhat. The problem here is two-fold: Firstly,
>>>>>>> I believe that the "external" choice will be relevant to nobody (as
>>>>>>> in, neither the community nor Oracle), and secondly, there have
>>>>>>> been discussions of handling the external debuginfo differently
>>>>>>> (namely, to move all debug info, unzipped, into a separate image,
>>>>>>> and zip them all at once). It's a bit unfortunate if we create an
>>>>>>> interface to configure that cannot grow properly with future
>>>>>>> changes.
>>>>>>>
>>>>>>> On the other hand, it does seem convenient to express the end
>>>>>>> result for the Oracle build as "zipped" (or possibly
>>>>>>> "external-zipped", to emphasize  the connection to "external"?).
>>>>>>>
>>>>>>> So I'm not sure what to think myself. But if David agrees that
>>>>>>> adding "zipped" (or "external-zipped") to the new argument, and
>>>>>>> deprecating the old, then I agree with it as well. :-)
>>>>>>>
>>>>>>> The second discussion here is the connection between java and
>>>>>>> native debug symbols.
>>>>>>>
>>>>>>> Fact: We do not currently have a story for setting java debug
>>>>>>> symbols. That's bad, and a regression as pointed out.
>>>>>>> Fact: That does not mean it has to be fixed in this patch.
>>>>>>>
>>>>>>> I do think that java and native debug symbols are different things
>>>>>>> and should be treated differently. But I also think we should have
>>>>>>> configure arguments that show their similarity. So, I propose that
>>>>>>> we have a
>>>>>>> --with-native-debug-symbols=none,internal,external,zipped
>>>>>>> as you propose, and then also a
>>>>>>> --with-java-debug-symbols=none,all
>>>>>>> (or "none,internal" for consistency).
>>>>>>>
>>>>>>> I think it would be nice if that flag could be implemented in the
>>>>>>> same patch, but since it is a different thing I understand if you
>>>>>>> want to leave it out. There is some added complication here, since
>>>>>>> we already set -g for java compilation depending on debug level,
>>>>>>> and the native debug symbol patch is obviously tricky as it is.
>>>>>>>
>>>>>>> /Magnus
>>>>


From david.holmes at oracle.com  Wed Dec  9 11:30:17 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Dec 2015 21:30:17 +1000
Subject: [JDK 9] hs-rt forest fails to build?
In-Reply-To: <1449660403.3543.33.camel@redhat.com>
References: <1449656620.3543.3.camel@redhat.com> <56680F33.1040807@oracle.com>
	<1449660403.3543.33.camel@redhat.com>
Message-ID: <566810C9.2090003@oracle.com>

On 9/12/2015 9:26 PM, Severin Gehwolf wrote:
> Hi David,
>
> On Wed, 2015-12-09 at 21:23 +1000, David Holmes wrote:
>> On 9/12/2015 8:23 PM, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to build
>>> for
>>> me with:
>>>
>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/Loggin
>>> gProviderImpl.java:33: error: cannot find symbol
>>> import java.lang.System.LoggerFinder;
>>>                          ^
>>>     symbol:   class LoggerFinder
>>>     location: class System
>>
>> What boot JDK are you using?
>
> JDK 8 from stock Fedora 23:
> $ rpm -q java-1.8.0-openjdk
> java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64

Should be okay. Strange error ... cc'ing build folk :)

David

> Thanks,
> Severin
>
>> David
>> -----
>>
>>
>>> $ hg paths
>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/
>>>
>>> Do I need to use a different tree these days? What am I missing?
>>>
>>> Thanks,
>>> Severin
>>>
>


From sgehwolf at redhat.com  Wed Dec  9 12:33:42 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 09 Dec 2015 13:33:42 +0100
Subject: [JDK 9] hs-rt forest fails to build?
In-Reply-To: <1449659738.3543.28.camel@redhat.com>
References: <1449656620.3543.3.camel@redhat.com>
	<5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com>
Message-ID: <1449664422.3543.37.camel@redhat.com>

Hi,

On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote:
> Hi Mikael,
> 
> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote:
> > Hi Severin,
> > 
> > On 2015-12-09 11:23, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for
> > > me with:
> > > 
> > > jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol
> > > import java.lang.System.LoggerFinder;
> > > ????????????????????????^
> > > ???symbol:???class LoggerFinder
> > > ???location: class System
> > 
> > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src/java.base/share/classes/java/lang/System.java#l1377
> > the LoggerFinder inner class appears to exist on the hg server at least.
> 
> I have it in the local copy too, yet I get:
> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch' failed
> make/Main.gmk:150: recipe for target 'java.logging-java' failed
> 
> With the above root-cause. I'll try with a fresh clone...

Same failure with fresh clone :( Here is how I configure and invoke
make:
bash configure \
?--with-boot-jdk="$JDK_TO_BUILD_WITH" \
?--with-debug-level="release" \
?--disable-zip-debug-info \
?--enable-unlimited-crypto \
?--with-stdc++lib=dynamic \
?--disable-warnings-as-errors \
?--with-num-cores=8

make \
?DEBUG_BINARIES=true \
?JAVAC_FLAGS=-g \
?STRIP_POLICY=no_strip \
?STRIP="" \
?DISABLE_INTREE_EC=true \
?ALT_OBJCOPY=none \
?LOG=debug \
?images

Thanks,
Severin

> > > 
> > > $ hg paths
> > > default = http://hg.openjdk.java.net/jdk9/hs-rt/
> > > 
> > > Do I need to use a different tree these days? What am I missing?
> > 
> > No, it should work.
> > Are you sure you've updated all the sub-trees?
> > 
> > http://hg.openjdk.java.net/code-tools/trees/
> > Is a helpful hg extension to keep track of things.
> > 
> > I've noticed that sometimes "bash get_source.sh" does not correctly "hg?
> > update" the entire forest.
> 
> I should have an updated tree, though I usually use:
> $ hg pull -u
> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do pushd $i; hg pull -u; popd; done
> 
> I've checked just now and all repos seem to have updated correctly. The
> CI builder for Zero seems to agree[1]. Note: The above build failure is
> for a regular server JVM. Not sure what's wrong. I keep looking,
> thanks!
> 
> Cheers,
> Severin
> 
> [1]?http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/191/console
> 
> > /Mikael
> > 
> > > 
> > > Thanks,
> > > Severin
> > > 
> > 
> 



From erik.joelsson at oracle.com  Wed Dec  9 16:35:30 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 9 Dec 2015 17:35:30 +0100
Subject: [JDK 9] hs-rt forest fails to build?
In-Reply-To: <1449664422.3543.37.camel@redhat.com>
References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com>
	<1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com>
Message-ID: <56685852.80705@oracle.com>

I'm not able to reproduce with either OracleJDK 8 or 8u66.

/Erik

On 2015-12-09 13:33, Severin Gehwolf wrote:
> Hi,
>
> On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote:
>> Hi Mikael,
>>
>> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote:
>>> Hi Severin,
>>>
>>> On 2015-12-09 11:23, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to build for
>>>> me with:
>>>>
>>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java:33: error: cannot find symbol
>>>> import java.lang.System.LoggerFinder;
>>>>                          ^
>>>>     symbol:   class LoggerFinder
>>>>     location: class System
>>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src/java.base/share/classes/java/lang/System.java#l1377
>>> the LoggerFinder inner class appears to exist on the hg server at least.
>> I have it in the local copy too, yet I get:
>> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch' failed
>> make/Main.gmk:150: recipe for target 'java.logging-java' failed
>>
>> With the above root-cause. I'll try with a fresh clone...
> Same failure with fresh clone :( Here is how I configure and invoke
> make:
> bash configure \
>   --with-boot-jdk="$JDK_TO_BUILD_WITH" \
>   --with-debug-level="release" \
>   --disable-zip-debug-info \
>   --enable-unlimited-crypto \
>   --with-stdc++lib=dynamic \
>   --disable-warnings-as-errors \
>   --with-num-cores=8
>
> make \
>   DEBUG_BINARIES=true \
>   JAVAC_FLAGS=-g \
>   STRIP_POLICY=no_strip \
>   STRIP="" \
>   DISABLE_INTREE_EC=true \
>   ALT_OBJCOPY=none \
>   LOG=debug \
>   images
>
> Thanks,
> Severin
>
>>>> $ hg paths
>>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/
>>>>
>>>> Do I need to use a different tree these days? What am I missing?
>>> No, it should work.
>>> Are you sure you've updated all the sub-trees?
>>>
>>> http://hg.openjdk.java.net/code-tools/trees/
>>> Is a helpful hg extension to keep track of things.
>>>
>>> I've noticed that sometimes "bash get_source.sh" does not correctly "hg
>>> update" the entire forest.
>> I should have an updated tree, though I usually use:
>> $ hg pull -u
>> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do pushd $i; hg pull -u; popd; done
>>
>> I've checked just now and all repos seem to have updated correctly. The
>> CI builder for Zero seems to agree[1]. Note: The above build failure is
>> for a regular server JVM. Not sure what's wrong. I keep looking,
>> thanks!
>>
>> Cheers,
>> Severin
>>
>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/191/console
>>
>>> /Mikael
>>>
>>>> Thanks,
>>>> Severin
>>>>



From sgehwolf at redhat.com  Wed Dec  9 17:53:05 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 09 Dec 2015 18:53:05 +0100
Subject: [JDK 9] hs-rt forest fails to build?
In-Reply-To: <56685852.80705@oracle.com>
References: <1449656620.3543.3.camel@redhat.com>
	<5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com>
Message-ID: <1449683585.3543.88.camel@redhat.com>

Hi Erik,

On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote:
> I'm not able to reproduce with either OracleJDK 8 or 8u66.

The simplified reproducer is (extracted from build.log):
( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch

I'm also attaching the failing command invocation as a file (Putting
this into a file and re-executing it reproduces the problem for me. Of
course, your paths may differ :)

Cheers,
Severin

> /Erik
> 
> On 2015-12-09 13:33, Severin Gehwolf wrote:
> > Hi,
> > 
> > On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote:
> > > Hi Mikael,
> > > 
> > > On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote:
> > > > Hi Severin,
> > > > 
> > > > On 2015-12-09 11:23, Severin Gehwolf wrote:
> > > > > Hi,
> > > > > 
> > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to
> > > > > build for
> > > > > me with:
> > > > > 
> > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/
> > > > > LoggingProviderImpl.java:33: error: cannot find symbol
> > > > > import java.lang.System.LoggerFinder;
> > > > > ?????????????????????????^
> > > > > ????symbol:???class LoggerFinder
> > > > > ????location: class System
> > > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src
> > > > /java.base/share/classes/java/lang/System.java#l1377
> > > > the LoggerFinder inner class appears to exist on the hg server
> > > > at least.
> > > I have it in the local copy too, yet I get:
> > > CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-
> > > x86_64-normal-server-
> > > release/jdk/modules/java.logging/_the.java.logging_batch' failed
> > > make/Main.gmk:150: recipe for target 'java.logging-java' failed
> > > 
> > > With the above root-cause. I'll try with a fresh clone...
> > Same failure with fresh clone :( Here is how I configure and invoke
> > make:
> > bash configure \
> > ? --with-boot-jdk="$JDK_TO_BUILD_WITH" \
> > ? --with-debug-level="release" \
> > ? --disable-zip-debug-info \
> > ? --enable-unlimited-crypto \
> > ? --with-stdc++lib=dynamic \
> > ? --disable-warnings-as-errors \
> > ? --with-num-cores=8
> > 
> > make \
> > ? DEBUG_BINARIES=true \
> > ? JAVAC_FLAGS=-g \
> > ? STRIP_POLICY=no_strip \
> > ? STRIP="" \
> > ? DISABLE_INTREE_EC=true \
> > ? ALT_OBJCOPY=none \
> > ? LOG=debug \
> > ? images
> > 
> > Thanks,
> > Severin
> > 
> > > > > $ hg paths
> > > > > default = http://hg.openjdk.java.net/jdk9/hs-rt/
> > > > > 
> > > > > Do I need to use a different tree these days? What am I
> > > > > missing?
> > > > No, it should work.
> > > > Are you sure you've updated all the sub-trees?
> > > > 
> > > > http://hg.openjdk.java.net/code-tools/trees/
> > > > Is a helpful hg extension to keep track of things.
> > > > 
> > > > I've noticed that sometimes "bash get_source.sh" does not
> > > > correctly "hg
> > > > update" the entire forest.
> > > I should have an updated tree, though I usually use:
> > > $ hg pull -u
> > > $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do
> > > pushd $i; hg pull -u; popd; done
> > > 
> > > I've checked just now and all repos seem to have updated
> > > correctly. The
> > > CI builder for Zero seems to agree[1]. Note: The above build
> > > failure is
> > > for a regular server JVM. Not sure what's wrong. I keep looking,
> > > thanks!
> > > 
> > > Cheers,
> > > Severin
> > > 
> > > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/
> > > 191/console
> > > 
> > > > /Mikael
> > > > 
> > > > > Thanks,
> > > > > Severin
> > > > > 
> 
-------------- next part --------------
( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh  /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f  /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv  /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch

From asmundak at google.com  Wed Dec  9 18:16:30 2015
From: asmundak at google.com (Alexander Smundak)
Date: Wed, 9 Dec 2015 10:16:30 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <56679B9F.8030105@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
Message-ID: <CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>

I am confused -- is there anything you want me to change in the existing set:

http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03

Sasha

On Tue, Dec 8, 2015 at 7:10 PM, David Holmes <david.holmes at oracle.com> wrote:
> I can sponsor for you Sasha. Just email me the changeset, or a link thereto.
>
> Thanks,
> David
>
>
> On 9/12/2015 3:44 AM, Alexander Smundak wrote:
>>
>> Thank you for the review.
>> If everyone involved is satisfied with the patch, I need a sponsor.
>>
>> Sasha
>>
>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>>>
>>>>
>>>> It is achievable by adding a small ppc-specific check to the
>>>> common/autoconf/platform.m4:
>>>>
>>>> @@ -282,6 +282,8 @@
>>>>      elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>>>        # On all platforms except MacOSX replace x86_64 with amd64.
>>>>        OPENJDK_TARGET_CPU_LEGACY="amd64"
>>>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>>>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>>>      fi
>>>>      AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>>>
>>>> However, there is a code in make/Images.gmk using
>>>> OPENJDK_TARGET_CPU_LEGACY
>>>>     $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
>>>> so that the 'release' file in the image directory will now have
>>>> JAVA_VERSION="9"
>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>>>> OS_NAME="Linux"
>>>> OS_VERSION="2.6"
>>>> OS_ARCH="ppc64"
>>>>           ^^^^^^^^
>>>> SOURCE=..,
>>>>
>>>> instead of "ppc64le".
>>>>
>>>> If someone can tell me which other variable I should use to achieve
>>>> that without changing the contents of the 'release' file on other
>>>> platforms, I'll be grateful.
>>>
>>>
>>>
>>> Okay never mind - and thanks for looking into this. I see now this is set
>>> via:
>>>
>>> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>>>
>>> so there is no way to add a second value without introducing some
>>> additional
>>> variable. At the hotspot level it could be handled differently if we had
>>> a
>>> platform_ppc64le file, as it could just be added to the SYSDEFS.
>>>
>>> Thanks,
>>> David


From david.holmes at oracle.com  Thu Dec 10 04:59:58 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Dec 2015 14:59:58 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
Message-ID: <566906CE.2050101@oracle.com>

On 10/12/2015 4:16 AM, Alexander Smundak wrote:
> I am confused -- is there anything you want me to change in the existing set:
>
> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03

Yes they need to be created using the correct, jcheck[1] compliant, 
commit messages:

http://openjdk.java.net/guide/producingChangeset.html

Mainly Reviewers seem to be missing - but I'm also not sure other 
details are jcheck compliant.

Thanks,
David

[1] http://openjdk.java.net/projects/code-tools/jcheck/

> Sasha
>
> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes <david.holmes at oracle.com> wrote:
>> I can sponsor for you Sasha. Just email me the changeset, or a link thereto.
>>
>> Thanks,
>> David
>>
>>
>> On 9/12/2015 3:44 AM, Alexander Smundak wrote:
>>>
>>> Thank you for the review.
>>> If everyone involved is satisfied with the patch, I need a sponsor.
>>>
>>> Sasha
>>>
>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>>>>
>>>>>
>>>>> It is achievable by adding a small ppc-specific check to the
>>>>> common/autoconf/platform.m4:
>>>>>
>>>>> @@ -282,6 +282,8 @@
>>>>>       elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>>>>         # On all platforms except MacOSX replace x86_64 with amd64.
>>>>>         OPENJDK_TARGET_CPU_LEGACY="amd64"
>>>>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>>>>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>>>>       fi
>>>>>       AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>>>>
>>>>> However, there is a code in make/Images.gmk using
>>>>> OPENJDK_TARGET_CPU_LEGACY
>>>>>      $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
>>>>> so that the 'release' file in the image directory will now have
>>>>> JAVA_VERSION="9"
>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>>>>> OS_NAME="Linux"
>>>>> OS_VERSION="2.6"
>>>>> OS_ARCH="ppc64"
>>>>>            ^^^^^^^^
>>>>> SOURCE=..,
>>>>>
>>>>> instead of "ppc64le".
>>>>>
>>>>> If someone can tell me which other variable I should use to achieve
>>>>> that without changing the contents of the 'release' file on other
>>>>> platforms, I'll be grateful.
>>>>
>>>>
>>>>
>>>> Okay never mind - and thanks for looking into this. I see now this is set
>>>> via:
>>>>
>>>> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>>>>
>>>> so there is no way to add a second value without introducing some
>>>> additional
>>>> variable. At the hotspot level it could be handled differently if we had
>>>> a
>>>> platform_ppc64le file, as it could just be added to the SYSDEFS.
>>>>
>>>> Thanks,
>>>> David


From erik.joelsson at oracle.com  Thu Dec 10 13:39:02 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 10 Dec 2015 14:39:02 +0100
Subject: RFR: JDK-8145106: Still intermittent build error building
	jdk/src/demo/solaris/jni/Poller/Poller.c
In-Reply-To: <5666B51C.4020805@oracle.com>
References: <5666B19D.8090005@oracle.com> <5666B51C.4020805@oracle.com>
Message-ID: <56698076.9030404@oracle.com>

Unfortunately, this fix failed. Depending on 
$(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS) doesn't guarantee that the 
header file is there in all cases. There is a separate copy step of 
headers inside SetupJavaCompilation. The simple solution to this is to 
just depend on $(BUILD_DEMO_JAVA_Poller) instead. Not ideal for 
efficiency, but in this small case it hardly matters.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145106
Patch:
diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
--- a/make/CompileDemos.gmk
+++ b/make/CompileDemos.gmk
@@ -459,7 +459,7 @@
    # We can only compile native code after java has been compiled (since we
    # depend on generated .h files)
    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
-      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
+      $(BUILD_DEMO_JAVA_Poller)

    # Copy to image
    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \

/Erik

On 2015-12-08 11:46, David Holmes wrote:
> Looks good!
>
> Thanks,
> David
>
> On 8/12/2015 8:31 PM, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this small fix for a misspelled dependency causing a race
>> when building on Solaris.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144857
>> Patch:
>> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
>> --- a/make/CompileDemos.gmk
>> +++ b/make/CompileDemos.gmk
>> @@ -459,7 +459,7 @@
>>     # We can only compile native code after java has been compiled
>> (since we
>>     # depend on generated .h files)
>>     $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
>> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
>> +      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
>>
>>     # Copy to image
>>     $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>>
>>
>> /Erik



From erik.joelsson at oracle.com  Thu Dec 10 13:43:11 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 10 Dec 2015 14:43:11 +0100
Subject: RFR: JDK-8145106: Still intermittent build error building
	jdk/src/demo/solaris/jni/Poller/Poller.c
In-Reply-To: <56698076.9030404@oracle.com>
References: <5666B19D.8090005@oracle.com> <5666B51C.4020805@oracle.com>
	<56698076.9030404@oracle.com>
Message-ID: <5669816F.2090107@oracle.com>

I accidentally posted diff against the wrong parent. Here is the correct 
diff:

diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
--- a/make/CompileDemos.gmk
+++ b/make/CompileDemos.gmk
@@ -459,7 +459,7 @@
    # We can only compile native code after java has been compiled (since we
    # depend on generated .h files)
    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
-      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
+      $(BUILD_DEMO_JAVA_Poller)

    # Copy to image
    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \

/Erik

On 2015-12-10 14:39, Erik Joelsson wrote:
> Unfortunately, this fix failed. Depending on 
> $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS) doesn't guarantee that the 
> header file is there in all cases. There is a separate copy step of 
> headers inside SetupJavaCompilation. The simple solution to this is to 
> just depend on $(BUILD_DEMO_JAVA_Poller) instead. Not ideal for 
> efficiency, but in this small case it hardly matters.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145106
> Patch:
> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
> --- a/make/CompileDemos.gmk
> +++ b/make/CompileDemos.gmk
> @@ -459,7 +459,7 @@
>    # We can only compile native code after java has been compiled 
> (since we
>    # depend on generated .h files)
>    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
> +      $(BUILD_DEMO_JAVA_Poller)
>
>    # Copy to image
>    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>
> /Erik
>
> On 2015-12-08 11:46, David Holmes wrote:
>> Looks good!
>>
>> Thanks,
>> David
>>
>> On 8/12/2015 8:31 PM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this small fix for a misspelled dependency causing a race
>>> when building on Solaris.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144857
>>> Patch:
>>> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
>>> --- a/make/CompileDemos.gmk
>>> +++ b/make/CompileDemos.gmk
>>> @@ -459,7 +459,7 @@
>>>     # We can only compile native code after java has been compiled
>>> (since we
>>>     # depend on generated .h files)
>>>     $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
>>> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
>>> +      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
>>>
>>>     # Copy to image
>>>     $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>>>
>>>
>>> /Erik
>



From erik.joelsson at oracle.com  Thu Dec 10 14:49:42 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 10 Dec 2015 15:49:42 +0100
Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works
In-Reply-To: <1449683585.3543.88.camel@redhat.com>
References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com>
	<1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com>
	<56685852.80705@oracle.com> <1449683585.3543.88.camel@redhat.com>
Message-ID: <56699106.2000709@oracle.com>

I looked closer at your actual command lines and managed to reproduce. 
The problem is JAVAC_FLAGS=-g. We have unfortunately used that name for 
a local variable in make/CompileJavaModules.gmk. Fix is pretty simple, 
just rename that local variable. In the longer term, we need to be able 
to enable -g for javac with a configure argument instead.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145115
Patch:
diff -r a151b3ec17a1 make/CompileJavaModules.gmk
--- a/make/CompileJavaModules.gmk
+++ b/make/CompileJavaModules.gmk
@@ -556,7 +556,7 @@
    ifneq ($(BUILD_CRYPTO), true)
    CLASSPATH += $(JDK_OUTPUTDIR)/modules/$(MODULE)
    endif
-JAVAC_FLAGS := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \
+JAVAC_FLAGS_BOOTCLASSPATH := -bootclasspath $(EMPTY_DIR) -extdirs 
$(EMPTY_DIR) \
      -endorseddirs $(EMPTY_DIR) $($(MODULE)_ADD_JAVAC_FLAGS)

  $(eval $(call SetupJavaCompilation, $(MODULE), \
@@ -566,7 +566,7 @@
      BIN := $(if $($(MODULE)_BIN), $($(MODULE)_BIN), 
$(JDK_OUTPUTDIR)/modules/$(MODULE)), \
      HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$(MODULE), \
      CLASSPATH := $(CLASSPATH), \
-    ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS) \
+    ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) 
$(JAVAC_FLAGS_BOOTCLASSPATH) \
  ))
  TARGETS += $($(MODULE)) $($(MODULE)_COPY_EXTRA)

/Erik

On 2015-12-09 18:53, Severin Gehwolf wrote:
> Hi Erik,
>
> On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote:
>> I'm not able to reproduce with either OracleJDK 8 or 8u66.
> The simplified reproducer is (extracted from build.log):
> ( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh  /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f  /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv  /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch
>
> I'm also attaching the failing command invocation as a file (Putting
> this into a file and re-executing it reproduces the problem for me. Of
> course, your paths may differ :)
>
> Cheers,
> Severin
>
>> /Erik
>>
>> On 2015-12-09 13:33, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote:
>>>> Hi Mikael,
>>>>
>>>> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote:
>>>>> Hi Severin,
>>>>>
>>>>> On 2015-12-09 11:23, Severin Gehwolf wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to
>>>>>> build for
>>>>>> me with:
>>>>>>
>>>>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/
>>>>>> LoggingProviderImpl.java:33: error: cannot find symbol
>>>>>> import java.lang.System.LoggerFinder;
>>>>>>                           ^
>>>>>>      symbol:   class LoggerFinder
>>>>>>      location: class System
>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src
>>>>> /java.base/share/classes/java/lang/System.java#l1377
>>>>> the LoggerFinder inner class appears to exist on the hg server
>>>>> at least.
>>>> I have it in the local copy too, yet I get:
>>>> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-
>>>> x86_64-normal-server-
>>>> release/jdk/modules/java.logging/_the.java.logging_batch' failed
>>>> make/Main.gmk:150: recipe for target 'java.logging-java' failed
>>>>
>>>> With the above root-cause. I'll try with a fresh clone...
>>> Same failure with fresh clone :( Here is how I configure and invoke
>>> make:
>>> bash configure \
>>>    --with-boot-jdk="$JDK_TO_BUILD_WITH" \
>>>    --with-debug-level="release" \
>>>    --disable-zip-debug-info \
>>>    --enable-unlimited-crypto \
>>>    --with-stdc++lib=dynamic \
>>>    --disable-warnings-as-errors \
>>>    --with-num-cores=8
>>>
>>> make \
>>>    DEBUG_BINARIES=true \
>>>    JAVAC_FLAGS=-g \
>>>    STRIP_POLICY=no_strip \
>>>    STRIP="" \
>>>    DISABLE_INTREE_EC=true \
>>>    ALT_OBJCOPY=none \
>>>    LOG=debug \
>>>    images
>>>
>>> Thanks,
>>> Severin
>>>
>>>>>> $ hg paths
>>>>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/
>>>>>>
>>>>>> Do I need to use a different tree these days? What am I
>>>>>> missing?
>>>>> No, it should work.
>>>>> Are you sure you've updated all the sub-trees?
>>>>>
>>>>> http://hg.openjdk.java.net/code-tools/trees/
>>>>> Is a helpful hg extension to keep track of things.
>>>>>
>>>>> I've noticed that sometimes "bash get_source.sh" does not
>>>>> correctly "hg
>>>>> update" the entire forest.
>>>> I should have an updated tree, though I usually use:
>>>> $ hg pull -u
>>>> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do
>>>> pushd $i; hg pull -u; popd; done
>>>>
>>>> I've checked just now and all repos seem to have updated
>>>> correctly. The
>>>> CI builder for Zero seems to agree[1]. Note: The above build
>>>> failure is
>>>> for a regular server JVM. Not sure what's wrong. I keep looking,
>>>> thanks!
>>>>
>>>> Cheers,
>>>> Severin
>>>>
>>>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/
>>>> 191/console
>>>>
>>>>> /Mikael
>>>>>
>>>>>> Thanks,
>>>>>> Severin
>>>>>>




From sgehwolf at redhat.com  Thu Dec 10 15:02:25 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 10 Dec 2015 16:02:25 +0100
Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works
In-Reply-To: <56699106.2000709@oracle.com>
References: <1449656620.3543.3.camel@redhat.com>
	<5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com>
	<1449683585.3543.88.camel@redhat.com> <56699106.2000709@oracle.com>
Message-ID: <1449759745.3577.22.camel@redhat.com>

On Thu, 2015-12-10 at 15:49 +0100, Erik Joelsson wrote:
> I looked closer at your actual command lines and managed to reproduce.?
> The problem is JAVAC_FLAGS=-g. We have unfortunately used that name for?
> a local variable in make/CompileJavaModules.gmk. Fix is pretty simple,?
> just rename that local variable.

OK thanks.

> In the longer term, we need to be able?
> to enable -g for javac with a configure argument instead.

Yes, pretty please :) This is a long standing issue (not just java
class debug info, but debug info in general). See
JDK-8036003 with review thread:
http://mail.openjdk.java.net/pipermail/build-dev/2015-December/016155.html

Once JDK-8036003 is fixed we'd need something similar for Java classes
and we can get rid of invoking make with build internal variables.

Thanks,
Severin

> Bug: https://bugs.openjdk.java.net/browse/JDK-8145115
> Patch:
> diff -r a151b3ec17a1 make/CompileJavaModules.gmk
> --- a/make/CompileJavaModules.gmk
> +++ b/make/CompileJavaModules.gmk
> @@ -556,7 +556,7 @@
> ????ifneq ($(BUILD_CRYPTO), true)
> ????CLASSPATH += $(JDK_OUTPUTDIR)/modules/$(MODULE)
> ????endif
> -JAVAC_FLAGS := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \
> +JAVAC_FLAGS_BOOTCLASSPATH := -bootclasspath $(EMPTY_DIR) -extdirs?
> $(EMPTY_DIR) \
> ??????-endorseddirs $(EMPTY_DIR) $($(MODULE)_ADD_JAVAC_FLAGS)
> 
> ? $(eval $(call SetupJavaCompilation, $(MODULE), \
> @@ -566,7 +566,7 @@
> ??????BIN := $(if $($(MODULE)_BIN), $($(MODULE)_BIN),?
> $(JDK_OUTPUTDIR)/modules/$(MODULE)), \
> ??????HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$(MODULE), \
> ??????CLASSPATH := $(CLASSPATH), \
> -????ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS) \
> +????ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS)?
> $(JAVAC_FLAGS_BOOTCLASSPATH) \
> ? ))
> ? TARGETS += $($(MODULE)) $($(MODULE)_COPY_EXTRA)
> 
> /Erik
> 
> On 2015-12-09 18:53, Severin Gehwolf wrote:
> > Hi Erik,
> > 
> > On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote:
> > > I'm not able to reproduce with either OracleJDK 8 or 8u66.
> > The simplified reproducer is (extracted from build.log):
> > ( (/usr/bin/bash /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M -Xmx512M "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" -cp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar com.sun.tools.sjavac.Main --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true -Xlint:all -Werror -g -Xdoclint:all/protected,-reference '-Xdoclint/package:java.*,javax.*' -g -cp "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" -implicit:none -d /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging -h /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp && /usr/bin/rm -f??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) || (exitcode=$? && /usr/bin/mv??/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log && exit $exitcode) ) && /usr/bin/mv /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch
> > 
> > I'm also attaching the failing command invocation as a file (Putting
> > this into a file and re-executing it reproduces the problem for me. Of
> > course, your paths may differ :)
> > 
> > Cheers,
> > Severin
> > 
> > > /Erik
> > > 
> > > On 2015-12-09 13:33, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote:
> > > > > Hi Mikael,
> > > > > 
> > > > > On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote:
> > > > > > Hi Severin,
> > > > > > 
> > > > > > On 2015-12-09 11:23, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm trying to build an OpenJDK 9, hs-rt tree which fails to
> > > > > > > build for
> > > > > > > me with:
> > > > > > > 
> > > > > > > jdk/src/java.logging/share/classes/sun/util/logging/internal/
> > > > > > > LoggingProviderImpl.java:33: error: cannot find symbol
> > > > > > > import java.lang.System.LoggerFinder;
> > > > > > > ??????????????????????????^
> > > > > > > ?????symbol:???class LoggerFinder
> > > > > > > ?????location: class System
> > > > > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src
> > > > > > /java.base/share/classes/java/lang/System.java#l1377
> > > > > > the LoggerFinder inner class appears to exist on the hg server
> > > > > > at least.
> > > > > I have it in the local copy too, yet I get:
> > > > > CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-
> > > > > x86_64-normal-server-
> > > > > release/jdk/modules/java.logging/_the.java.logging_batch' failed
> > > > > make/Main.gmk:150: recipe for target 'java.logging-java' failed
> > > > > 
> > > > > With the above root-cause. I'll try with a fresh clone...
> > > > Same failure with fresh clone :( Here is how I configure and invoke
> > > > make:
> > > > bash configure \
> > > > ???--with-boot-jdk="$JDK_TO_BUILD_WITH" \
> > > > ???--with-debug-level="release" \
> > > > ???--disable-zip-debug-info \
> > > > ???--enable-unlimited-crypto \
> > > > ???--with-stdc++lib=dynamic \
> > > > ???--disable-warnings-as-errors \
> > > > ???--with-num-cores=8
> > > > 
> > > > make \
> > > > ???DEBUG_BINARIES=true \
> > > > ???JAVAC_FLAGS=-g \
> > > > ???STRIP_POLICY=no_strip \
> > > > ???STRIP="" \
> > > > ???DISABLE_INTREE_EC=true \
> > > > ???ALT_OBJCOPY=none \
> > > > ???LOG=debug \
> > > > ???images
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > > > $ hg paths
> > > > > > > default = http://hg.openjdk.java.net/jdk9/hs-rt/
> > > > > > > 
> > > > > > > Do I need to use a different tree these days? What am I
> > > > > > > missing?
> > > > > > No, it should work.
> > > > > > Are you sure you've updated all the sub-trees?
> > > > > > 
> > > > > > http://hg.openjdk.java.net/code-tools/trees/
> > > > > > Is a helpful hg extension to keep track of things.
> > > > > > 
> > > > > > I've noticed that sometimes "bash get_source.sh" does not
> > > > > > correctly "hg
> > > > > > update" the entire forest.
> > > > > I should have an updated tree, though I usually use:
> > > > > $ hg pull -u
> > > > > $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do
> > > > > pushd $i; hg pull -u; popd; done
> > > > > 
> > > > > I've checked just now and all repos seem to have updated
> > > > > correctly. The
> > > > > CI builder for Zero seems to agree[1]. Note: The above build
> > > > > failure is
> > > > > for a regular server JVM. Not sure what's wrong. I keep looking,
> > > > > thanks!
> > > > > 
> > > > > Cheers,
> > > > > Severin
> > > > > 
> > > > > [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/
> > > > > 191/console
> > > > > 
> > > > > > /Mikael
> > > > > > 
> > > > > > > Thanks,
> > > > > > > Severin
> > > > > > > 
> 
> 



From tim.bell at oracle.com  Thu Dec 10 16:35:29 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 10 Dec 2015 08:35:29 -0800
Subject: RFR: JDK-8145106: Still intermittent build error building
	jdk/src/demo/solaris/jni/Poller/Poller.c
In-Reply-To: <5669816F.2090107@oracle.com>
References: <5666B19D.8090005@oracle.com>
	<5666B51C.4020805@oracle.com>	<56698076.9030404@oracle.com>
	<5669816F.2090107@oracle.com>
Message-ID: <5669A9D1.1070104@oracle.com>

Erik:

> I accidentally posted diff against the wrong parent. Here is the 
> correct diff:
>
> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
> --- a/make/CompileDemos.gmk
> +++ b/make/CompileDemos.gmk
> @@ -459,7 +459,7 @@
>    # We can only compile native code after java has been compiled 
> (since we
>    # depend on generated .h files)
>    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
> -      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
> +      $(BUILD_DEMO_JAVA_Poller)
>
>    # Copy to image
>    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \

Looks good.

/Tim


>
> On 2015-12-10 14:39, Erik Joelsson wrote:
>> Unfortunately, this fix failed. Depending on 
>> $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS) doesn't guarantee that the 
>> header file is there in all cases. There is a separate copy step of 
>> headers inside SetupJavaCompilation. The simple solution to this is 
>> to just depend on $(BUILD_DEMO_JAVA_Poller) instead. Not ideal for 
>> efficiency, but in this small case it hardly matters.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145106
>> Patch:
>> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
>> --- a/make/CompileDemos.gmk
>> +++ b/make/CompileDemos.gmk
>> @@ -459,7 +459,7 @@
>>    # We can only compile native code after java has been compiled 
>> (since we
>>    # depend on generated .h files)
>>    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
>> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
>> +      $(BUILD_DEMO_JAVA_Poller)
>>
>>    # Copy to image
>>    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>>
>> /Erik
>>
>> On 2015-12-08 11:46, David Holmes wrote:
>>> Looks good!
>>>
>>> Thanks,
>>> David
>>>
>>> On 8/12/2015 8:31 PM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> Please review this small fix for a misspelled dependency causing a 
>>>> race
>>>> when building on Solaris.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144857
>>>> Patch:
>>>> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
>>>> --- a/make/CompileDemos.gmk
>>>> +++ b/make/CompileDemos.gmk
>>>> @@ -459,7 +459,7 @@
>>>>     # We can only compile native code after java has been compiled
>>>> (since we
>>>>     # depend on generated .h files)
>>>>     $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
>>>> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
>>>> +      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
>>>>
>>>>     # Copy to image
>>>>     $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>>>>
>>>>
>>>> /Erik
>>
>



From yasuenag at gmail.com  Thu Dec 10 23:47:12 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 11 Dec 2015 08:47:12 +0900
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <5667AA37.6020409@oracle.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
	<565FE685.4020601@oracle.com> <56677657.1000107@gmail.com>
	<5667AA37.6020409@oracle.com>
Message-ID: <566A0F00.3030804@gmail.com>

Hi build folks,

Could you review it?

>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.06/


Thanks,

Yasumasa


On 2015/12/09 13:12, David Holmes wrote:
> Hi,
>
> On 9/12/2015 10:31 AM, Yasumasa Suenaga wrote:
>> Hi,
>>
>> I've uploaded a new webrev:
>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.06/
>>
>>
>>> Can you reinstate the comment:
>>>
>>>   581   # This must be done after the toolchain is setup, since we're
>>> looking at objcopy.
>>>
>>> as this constraint still exists.
>>
>> I've fixed.
>>
>>> I would have hoped that the deprecation macro enabled you to inform
>>> the user what the replacement is as per the comments! This seems
>>> unsatisfactory. :(
>>
>> I added one more argument to BASIC_DEPRECATED_ARG_ENABLE to show message.
>> However, I'm not certain this change should be filed another issue or not.
>
> This seems good to me - and small enough to not warrant another issue.
>
> But ultimately it is up to the build folk.
>
> I have no further comments.
>
> Thanks,
> David
>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/12/03 15:51, David Holmes wrote:
>>> On 1/12/2015 12:34 AM, Yasumasa Suenaga wrote:
>>>> Hi Magnus,
>>>>
>>>> I've uploaded new webrev:
>>>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.05/
>>>
>>> common/autoconf/jdk-options.m4
>>>
>>> Can you reinstate the comment:
>>>
>>>   581   # This must be done after the toolchain is setup, since we're
>>> looking at objcopy.
>>>
>>> as this constraint still exists.
>>>
>>> It would be nice if the external and zipped cases could somehow be
>>> shared so that we don't have to duplicate everything just to alter the
>>> value of a single variable.
>>>
>>>   634   # --enable-zip-debug-info is deprecated.
>>>   635   # Please use --with-debug-symbols=zipped .
>>>   636   BASIC_DEPRECATED_ARG_ENABLE(zip-debug-info, zip_debug_info)
>>>
>>> I would have hoped that the deprecation macro enabled you to inform
>>> the user what the replacement is as per the comments! This seems
>>> unsatisfactory. :(
>>>
>>> I'm assuming there is no change to the default behaviour if none of
>>> these options are specified. I'm unclear whether we will need to
>>> coordinate this change with any internal processes that might
>>> explicitly be using the deprecated options - I think Magnus should
>>> have a better idea about that.
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>>> If we do implement this flag, it should work as expected. If you
>>>>> believe this is too hard to get right, I'm alright with fixing this as
>>>>> a separate bug.
>>>>
>>>> Okay, I removed --enable-java-debug-symbols in this webrev.
>>>> I will file to JBS and try to create patch for it after this issue.
>>>>
>>>>
>>>>> That is, have you tried building with the four different values of
>>>>> --with-native-debug-symbols and verified that the result is indeed as
>>>>> you specified?
>>>>
>>>> Of course, I've checked all pattern of --with-native-debug-symbols.
>>>> I ran readelf -S for libjvm, libnio, libsaproc, and java command.
>>>> I checked debug section (.debug_info, and more) in ELF binaries.
>>>>
>>>>
>>>>> Just by my quick glance I can already spot what I believe is a
>>>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>>>> reasonably be no_strip.
>>>>
>>>> I've fixed in this webrev.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2015/11/30 21:26, Magnus Ihse Bursie wrote:
>>>>>
>>>>>
>>>>> On 2015-11-26 15:19, Yasumasa Suenaga wrote:
>>>>>> I uploaded a new webrev:
>>>>>>   http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/
>>>>>>
>>>>>> I implemented --with-native-debug-symbols and
>>>>>> --enable-java-debug-symbols in it.
>>>>>> And I deprecated --enable-debug-symbols and --enable-zip-debug-info .
>>>>>
>>>>> Hi Yasumasa,
>>>>>
>>>>> I apologize I have not been able to spend more time on this. I still
>>>>> only had time to take a short glimpse, but I found a few issues anyway.
>>>>>
>>>>> First, the new -enable-java-debug-symbols is problematic. If you build
>>>>> with "--enable-debug --disable-java-debug-symbols", then this implies
>>>>> that you would get a build without java debug symbols. However, this
>>>>> will not happen, since changing debug level wil enable java debug
>>>>> symbols, but the new java-debug-symbols flag will not manage to
>>>>> disable this.
>>>>>
>>>>> If we do implement this flag, it should work as expected. If you
>>>>> believe this is too hard to get right, I'm alright with fixing this as
>>>>> a separate bug.
>>>>>
>>>>> Second, all the flags we use to manage this internally makes me
>>>>> nervous. :) Are you sure you're getting them right? That is, have you
>>>>> tried building with the four different values of
>>>>> --with-native-debug-symbols and verified that the result is indeed as
>>>>> you specified? You'd need to check both libjvm.so and at least a jdk
>>>>> library, like libjava.so or so, since they use different build system
>>>>> and flags.
>>>>>
>>>>> Just by my quick glance I can already spot what I believe is a
>>>>> mistake: for "none" you set STRIP_POLICY to min_strip, but it should
>>>>> reasonably be no_strip. (I'd be surprised if strip was run if I
>>>>> compiled without debug symbols).
>>>>>
>>>>> Other than that, I believe this patch is starting to get ready.
>>>>>
>>>>> /Magnus
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>> On 2015/11/25 23:52, Yasumasa Suenaga wrote:
>>>>>>> Hi Magnus,
>>>>>>>
>>>>>>>> --with-java-debug-symbols=none,all
>>>>>>>> (or "none,internal" for consistency).
>>>>>>>
>>>>>>> Can I change this option to --enable-java-debug-symbols ?
>>>>>>> This value set to none or all. So I think that we should use
>>>>>>> AC_ARG_ENABLE for it.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>> On 2015/11/25 23:35, Magnus Ihse Bursie wrote:
>>>>>>>> On 2015-11-21 14:12, Yasumasa Suenaga wrote:
>>>>>>>>>> My point with current proposal is that either it doesn't touch
>>>>>>>>>> the zipping because we already have an option for that; or it
>>>>>>>>>> should deprecate the existing option (now Erik has pointed out
>>>>>>>>>> that capability).
>>>>>>>>>
>>>>>>>>> I'm using BASIC_DEPRECATED_ARG_ENABLE for debug-symbols and
>>>>>>>>> zip-debug-info in new webrev:
>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.03/
>>>>>>>>>
>>>>>>>>> I had thought this new option as a wrapper for existing options.
>>>>>>>>> However, if current options should be deprecated, I will follow it.
>>>>>>>>
>>>>>>>> Hi Yasumasa,
>>>>>>>>
>>>>>>>> Sorry for the delay in my response.
>>>>>>>>
>>>>>>>> I had to go back and re-read the old discussions and my personal
>>>>>>>> notes about this. It turned out that some of the complications that
>>>>>>>> existed then is not relevant from Oracle's point of view anymore
>>>>>>>> (more specifically, stripping to several distinct levels). With
>>>>>>>> that complication gone, the basic case boils down to the three ways
>>>>>>>> of doing this:
>>>>>>>> 1) Compile without debug information ("none")
>>>>>>>> 2) Compile with debug information and keep it ("internal")
>>>>>>>> 3) Compile with debug information, copy it to an external file, and
>>>>>>>> strip the binary ("external")
>>>>>>>>
>>>>>>>> So far, so good. I agree with David Holmes that the zipping
>>>>>>>> complicates things somewhat. The problem here is two-fold: Firstly,
>>>>>>>> I believe that the "external" choice will be relevant to nobody (as
>>>>>>>> in, neither the community nor Oracle), and secondly, there have
>>>>>>>> been discussions of handling the external debuginfo differently
>>>>>>>> (namely, to move all debug info, unzipped, into a separate image,
>>>>>>>> and zip them all at once). It's a bit unfortunate if we create an
>>>>>>>> interface to configure that cannot grow properly with future
>>>>>>>> changes.
>>>>>>>>
>>>>>>>> On the other hand, it does seem convenient to express the end
>>>>>>>> result for the Oracle build as "zipped" (or possibly
>>>>>>>> "external-zipped", to emphasize  the connection to "external"?).
>>>>>>>>
>>>>>>>> So I'm not sure what to think myself. But if David agrees that
>>>>>>>> adding "zipped" (or "external-zipped") to the new argument, and
>>>>>>>> deprecating the old, then I agree with it as well. :-)
>>>>>>>>
>>>>>>>> The second discussion here is the connection between java and
>>>>>>>> native debug symbols.
>>>>>>>>
>>>>>>>> Fact: We do not currently have a story for setting java debug
>>>>>>>> symbols. That's bad, and a regression as pointed out.
>>>>>>>> Fact: That does not mean it has to be fixed in this patch.
>>>>>>>>
>>>>>>>> I do think that java and native debug symbols are different things
>>>>>>>> and should be treated differently. But I also think we should have
>>>>>>>> configure arguments that show their similarity. So, I propose that
>>>>>>>> we have a
>>>>>>>> --with-native-debug-symbols=none,internal,external,zipped
>>>>>>>> as you propose, and then also a
>>>>>>>> --with-java-debug-symbols=none,all
>>>>>>>> (or "none,internal" for consistency).
>>>>>>>>
>>>>>>>> I think it would be nice if that flag could be implemented in the
>>>>>>>> same patch, but since it is a different thing I understand if you
>>>>>>>> want to leave it out. There is some added complication here, since
>>>>>>>> we already set -g for java compilation depending on debug level,
>>>>>>>> and the native debug symbol patch is obviously tricky as it is.
>>>>>>>>
>>>>>>>> /Magnus
>>>>>


From david.holmes at oracle.com  Fri Dec 11 01:31:13 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Dec 2015 11:31:13 +1000
Subject: RFR: JDK-8145106: Still intermittent build error building
	jdk/src/demo/solaris/jni/Poller/Poller.c
In-Reply-To: <5669816F.2090107@oracle.com>
References: <5666B19D.8090005@oracle.com> <5666B51C.4020805@oracle.com>
	<56698076.9030404@oracle.com> <5669816F.2090107@oracle.com>
Message-ID: <566A2761.20608@oracle.com>

Looks fine.

Thanks,
David

On 10/12/2015 11:43 PM, Erik Joelsson wrote:
> I accidentally posted diff against the wrong parent. Here is the correct
> diff:
>
> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
> --- a/make/CompileDemos.gmk
> +++ b/make/CompileDemos.gmk
> @@ -459,7 +459,7 @@
>     # We can only compile native code after java has been compiled
> (since we
>     # depend on generated .h files)
>     $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
> -      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
> +      $(BUILD_DEMO_JAVA_Poller)
>
>     # Copy to image
>     $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>
> /Erik
>
> On 2015-12-10 14:39, Erik Joelsson wrote:
>> Unfortunately, this fix failed. Depending on
>> $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS) doesn't guarantee that the
>> header file is there in all cases. There is a separate copy step of
>> headers inside SetupJavaCompilation. The simple solution to this is to
>> just depend on $(BUILD_DEMO_JAVA_Poller) instead. Not ideal for
>> efficiency, but in this small case it hardly matters.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145106
>> Patch:
>> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
>> --- a/make/CompileDemos.gmk
>> +++ b/make/CompileDemos.gmk
>> @@ -459,7 +459,7 @@
>>    # We can only compile native code after java has been compiled
>> (since we
>>    # depend on generated .h files)
>>    $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
>> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
>> +      $(BUILD_DEMO_JAVA_Poller)
>>
>>    # Copy to image
>>    $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>>
>> /Erik
>>
>> On 2015-12-08 11:46, David Holmes wrote:
>>> Looks good!
>>>
>>> Thanks,
>>> David
>>>
>>> On 8/12/2015 8:31 PM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> Please review this small fix for a misspelled dependency causing a race
>>>> when building on Solaris.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144857
>>>> Patch:
>>>> diff --git a/make/CompileDemos.gmk b/make/CompileDemos.gmk
>>>> --- a/make/CompileDemos.gmk
>>>> +++ b/make/CompileDemos.gmk
>>>> @@ -459,7 +459,7 @@
>>>>     # We can only compile native code after java has been compiled
>>>> (since we
>>>>     # depend on generated .h files)
>>>>     $(SUPPORT_OUTPUTDIR)/demos/native/jni/Poller/Poller.o: \
>>>> -      $(BUILD_DEMO_JAVA_POLLER_COMPILE_TARGETS)
>>>> +      $(BUILD_DEMO_JAVA_Poller_COMPILE_TARGET)
>>>>
>>>>     # Copy to image
>>>>     $(SUPPORT_OUTPUTDIR)/demos/image/jni/Poller/README.txt: \
>>>>
>>>>
>>>> /Erik
>>
>


From asmundak at google.com  Fri Dec 11 04:15:35 2015
From: asmundak at google.com (Alexander Smundak)
Date: Thu, 10 Dec 2015 20:15:35 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <566906CE.2050101@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
	<566906CE.2050101@oracle.com>
Message-ID: <CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>

I have jcheck enabled, so I am surprised that the absence of the
Reviewed-by: field was not flagged. Anyways, here's the new set:

http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.04
http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.04
http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.04

Note that I don't have access to the big-endian PowerPC64. The
original patch was verified by goetz.lindenmaier at sap.com, but it has
changed since. Goetz, can you verify that the new patch still works?

Sasha

On Wed, Dec 9, 2015 at 8:59 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 10/12/2015 4:16 AM, Alexander Smundak wrote:
>>
>> I am confused -- is there anything you want me to change in the existing
>> set:
>>
>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03
>
>
> Yes they need to be created using the correct, jcheck[1] compliant, commit
> messages:
>
> http://openjdk.java.net/guide/producingChangeset.html
>
> Mainly Reviewers seem to be missing - but I'm also not sure other details
> are jcheck compliant.
>
> Thanks,
> David
>
> [1] http://openjdk.java.net/projects/code-tools/jcheck/
>
>
>> Sasha
>>
>> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> I can sponsor for you Sasha. Just email me the changeset, or a link
>>> thereto.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>> On 9/12/2015 3:44 AM, Alexander Smundak wrote:
>>>>
>>>>
>>>> Thank you for the review.
>>>> If everyone involved is satisfied with the patch, I need a sponsor.
>>>>
>>>> Sasha
>>>>
>>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> It is achievable by adding a small ppc-specific check to the
>>>>>> common/autoconf/platform.m4:
>>>>>>
>>>>>> @@ -282,6 +282,8 @@
>>>>>>       elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>>>>>         # On all platforms except MacOSX replace x86_64 with amd64.
>>>>>>         OPENJDK_TARGET_CPU_LEGACY="amd64"
>>>>>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>>>>>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>>>>>       fi
>>>>>>       AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>>>>>
>>>>>> However, there is a code in make/Images.gmk using
>>>>>> OPENJDK_TARGET_CPU_LEGACY
>>>>>>      $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
>>>>>> so that the 'release' file in the image directory will now have
>>>>>> JAVA_VERSION="9"
>>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>>>>>> OS_NAME="Linux"
>>>>>> OS_VERSION="2.6"
>>>>>> OS_ARCH="ppc64"
>>>>>>            ^^^^^^^^
>>>>>> SOURCE=..,
>>>>>>
>>>>>> instead of "ppc64le".
>>>>>>
>>>>>> If someone can tell me which other variable I should use to achieve
>>>>>> that without changing the contents of the 'release' file on other
>>>>>> platforms, I'll be grateful.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Okay never mind - and thanks for looking into this. I see now this is
>>>>> set
>>>>> via:
>>>>>
>>>>> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
>>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>>>>>
>>>>> so there is no way to add a second value without introducing some
>>>>> additional
>>>>> variable. At the hotspot level it could be handled differently if we
>>>>> had
>>>>> a
>>>>> platform_ppc64le file, as it could just be added to the SYSDEFS.
>>>>>
>>>>> Thanks,
>>>>> David


From david.holmes at oracle.com  Fri Dec 11 04:47:49 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Dec 2015 14:47:49 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
	<566906CE.2050101@oracle.com>
	<CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>
Message-ID: <566A5575.3020908@oracle.com>

On 11/12/2015 2:15 PM, Alexander Smundak wrote:
> I have jcheck enabled, so I am surprised that the absence of the
> Reviewed-by: field was not flagged. Anyways, here's the new set:

Not sure what is going on with your jcheck setup but the formatting is 
still wrong:

- the changeset "user" must be OpenJDK username not email address
- reviewers must be OpenJDK user names not email addresses
- contributed-by attribution should be simple email address or the 
following is also allowed:
   Andrew Hughes <gnu.andrew at redhat.com>

Sorry.

David
-----

> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.04
> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.04
> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.04
>
> Note that I don't have access to the big-endian PowerPC64. The
> original patch was verified by goetz.lindenmaier at sap.com, but it has
> changed since. Goetz, can you verify that the new patch still works?
>
> Sasha
>
> On Wed, Dec 9, 2015 at 8:59 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 10/12/2015 4:16 AM, Alexander Smundak wrote:
>>>
>>> I am confused -- is there anything you want me to change in the existing
>>> set:
>>>
>>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
>>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
>>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03
>>
>>
>> Yes they need to be created using the correct, jcheck[1] compliant, commit
>> messages:
>>
>> http://openjdk.java.net/guide/producingChangeset.html
>>
>> Mainly Reviewers seem to be missing - but I'm also not sure other details
>> are jcheck compliant.
>>
>> Thanks,
>> David
>>
>> [1] http://openjdk.java.net/projects/code-tools/jcheck/
>>
>>
>>> Sasha
>>>
>>> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> I can sponsor for you Sasha. Just email me the changeset, or a link
>>>> thereto.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>> On 9/12/2015 3:44 AM, Alexander Smundak wrote:
>>>>>
>>>>>
>>>>> Thank you for the review.
>>>>> If everyone involved is satisfied with the patch, I need a sponsor.
>>>>>
>>>>> Sasha
>>>>>
>>>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It is achievable by adding a small ppc-specific check to the
>>>>>>> common/autoconf/platform.m4:
>>>>>>>
>>>>>>> @@ -282,6 +282,8 @@
>>>>>>>        elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>>>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>>>>>>          # On all platforms except MacOSX replace x86_64 with amd64.
>>>>>>>          OPENJDK_TARGET_CPU_LEGACY="amd64"
>>>>>>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>>>>>>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>>>>>>        fi
>>>>>>>        AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>>>>>>
>>>>>>> However, there is a code in make/Images.gmk using
>>>>>>> OPENJDK_TARGET_CPU_LEGACY
>>>>>>>       $(call info-file-item, "OS_ARCH", "$(OPENJDK_TARGET_CPU_LEGACY)")
>>>>>>> so that the 'release' file in the image directory will now have
>>>>>>> JAVA_VERSION="9"
>>>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>>>>>>> OS_NAME="Linux"
>>>>>>> OS_VERSION="2.6"
>>>>>>> OS_ARCH="ppc64"
>>>>>>>             ^^^^^^^^
>>>>>>> SOURCE=..,
>>>>>>>
>>>>>>> instead of "ppc64le".
>>>>>>>
>>>>>>> If someone can tell me which other variable I should use to achieve
>>>>>>> that without changing the contents of the 'release' file on other
>>>>>>> platforms, I'll be grateful.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Okay never mind - and thanks for looking into this. I see now this is
>>>>>> set
>>>>>> via:
>>>>>>
>>>>>> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
>>>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>>>>>>
>>>>>> so there is no way to add a second value without introducing some
>>>>>> additional
>>>>>> variable. At the hotspot level it could be handled differently if we
>>>>>> had
>>>>>> a
>>>>>> platform_ppc64le file, as it could just be added to the SYSDEFS.
>>>>>>
>>>>>> Thanks,
>>>>>> David


From magnus.ihse.bursie at oracle.com  Fri Dec 11 11:52:04 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 12:52:04 +0100
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <566A0F00.3030804@gmail.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
	<565FE685.4020601@oracle.com> <56677657.1000107@gmail.com>
	<5667AA37.6020409@oracle.com> <566A0F00.3030804@gmail.com>
Message-ID: <566AB8E4.3020901@oracle.com>

On 2015-12-11 00:47, Yasumasa Suenaga wrote:
> Hi build folks,
>
> Could you review it?
>
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.06/

I like the new way of passing a help text for deprecation. Just a note, 
in the help text you called the new option "--with-debug-symbols" 
instead of "--with-native-debug-symbols", which is kind of unhelpful. 
;-) You can just fix this, no need to upload a new webrev.

So, if you just fix this, I'm okay with the patch.

Thank you for fighting this all the way through. I do apologize for the 
slow process.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Dec 11 13:03:28 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 14:03:28 +0100
Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works
In-Reply-To: <56699106.2000709@oracle.com>
References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com>
	<1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com>
	<56685852.80705@oracle.com> <1449683585.3543.88.camel@redhat.com>
	<56699106.2000709@oracle.com>
Message-ID: <566AC9A0.1010103@oracle.com>

On 2015-12-10 15:49, Erik Joelsson wrote:
> I looked closer at your actual command lines and managed to reproduce. 
> The problem is JAVAC_FLAGS=-g. We have unfortunately used that name 
> for a local variable in make/CompileJavaModules.gmk. Fix is pretty 
> simple, just rename that local variable. In the longer term, we need 
> to be able to enable -g for javac with a configure argument instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145115
> Patch:
> diff -r a151b3ec17a1 make/CompileJavaModules.gmk
> --- a/make/CompileJavaModules.gmk
> +++ b/make/CompileJavaModules.gmk
> @@ -556,7 +556,7 @@
>    ifneq ($(BUILD_CRYPTO), true)
>    CLASSPATH += $(JDK_OUTPUTDIR)/modules/$(MODULE)
>    endif
> -JAVAC_FLAGS := -bootclasspath $(EMPTY_DIR) -extdirs $(EMPTY_DIR) \
> +JAVAC_FLAGS_BOOTCLASSPATH := -bootclasspath $(EMPTY_DIR) -extdirs 
> $(EMPTY_DIR) \
>      -endorseddirs $(EMPTY_DIR) $($(MODULE)_ADD_JAVAC_FLAGS)
>
>  $(eval $(call SetupJavaCompilation, $(MODULE), \
> @@ -566,7 +566,7 @@
>      BIN := $(if $($(MODULE)_BIN), $($(MODULE)_BIN), 
> $(JDK_OUTPUTDIR)/modules/$(MODULE)), \
>      HEADERS := $(SUPPORT_OUTPUTDIR)/headers/$(MODULE), \
>      CLASSPATH := $(CLASSPATH), \
> -    ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) $(JAVAC_FLAGS) \
> +    ADD_JAVAC_FLAGS := $($(MODULE)_ADD_JAVAC_FLAGS) 
> $(JAVAC_FLAGS_BOOTCLASSPATH) \
>  ))
>  TARGETS += $($(MODULE)) $($(MODULE)_COPY_EXTRA)
>

Patch looks good to me.

/Magnus

> /Erik
>
> On 2015-12-09 18:53, Severin Gehwolf wrote:
>> Hi Erik,
>>
>> On Wed, 2015-12-09 at 17:35 +0100, Erik Joelsson wrote:
>>> I'm not able to reproduce with either OracleJDK 8 or 8u66.
>> The simplified reproducer is (extracted from build.log):
>> ( (/usr/bin/bash 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/common/bin/logger.sh 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log 
>> /usr/lib/jvm/java-1.8.0-openjdk/bin/java -XX:+UseSerialGC -Xms32M 
>> -Xmx512M 
>> "-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar" 
>> -cp 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar 
>> com.sun.tools.sjavac.Main 
>> --server:portfile=/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/javacservers/server.port,id=java.logging,sjavac=/usr/lib/jvm/java-1.8.0-openjdk/bin/java%20-d64%20-Xms512M%20-Xmx2048M%20"-Xbootclasspath/p:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar"%20-cp%20/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/buildtools/interim_langtools.jar%20com.sun.tools.sjavac.Main 
>> -source 9 -target 9 -encoding ascii -XDignore.symbol.file=true 
>> -Xlint:all -Werror -g -Xdoclint:all/protected,-reference 
>> '-Xdoclint/package:java.*,javax.*' -g -cp 
>> "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.base:/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging" 
>> -implicit:none -d 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging 
>> -h 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/support/headers/java.logging.java.logging.tmp 
>> @/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp 
>> && /usr/bin/rm -f 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log) 
>> || (exitcode=$? && /usr/bin/mv 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.log 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/make-support/failure-logs/java.logging.log 
>> && exit $exitcode) ) && /usr/bin/mv 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch.tmp 
>> /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk-9-hs-rt-testclone/build/linux-x86_64-normal-server-release/jdk/modules/java.logging/_the.java.logging_batch 
>>
>>
>> I'm also attaching the failing command invocation as a file (Putting
>> this into a file and re-executing it reproduces the problem for me. Of
>> course, your paths may differ :)
>>
>> Cheers,
>> Severin
>>
>>> /Erik
>>>
>>> On 2015-12-09 13:33, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> On Wed, 2015-12-09 at 12:15 +0100, Severin Gehwolf wrote:
>>>>> Hi Mikael,
>>>>>
>>>>> On Wed, 2015-12-09 at 11:41 +0100, Mikael Gerdin wrote:
>>>>>> Hi Severin,
>>>>>>
>>>>>> On 2015-12-09 11:23, Severin Gehwolf wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm trying to build an OpenJDK 9, hs-rt tree which fails to
>>>>>>> build for
>>>>>>> me with:
>>>>>>>
>>>>>>> jdk/src/java.logging/share/classes/sun/util/logging/internal/
>>>>>>> LoggingProviderImpl.java:33: error: cannot find symbol
>>>>>>> import java.lang.System.LoggerFinder;
>>>>>>>                           ^
>>>>>>>      symbol:   class LoggerFinder
>>>>>>>      location: class System
>>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/file/7a67f71d3645/src
>>>>>> /java.base/share/classes/java/lang/System.java#l1377
>>>>>> the LoggerFinder inner class appears to exist on the hg server
>>>>>> at least.
>>>>> I have it in the local copy too, yet I get:
>>>>> CompileJavaModules.gmk:562: recipe for target 'hs-rt/build/linux-
>>>>> x86_64-normal-server-
>>>>> release/jdk/modules/java.logging/_the.java.logging_batch' failed
>>>>> make/Main.gmk:150: recipe for target 'java.logging-java' failed
>>>>>
>>>>> With the above root-cause. I'll try with a fresh clone...
>>>> Same failure with fresh clone :( Here is how I configure and invoke
>>>> make:
>>>> bash configure \
>>>>    --with-boot-jdk="$JDK_TO_BUILD_WITH" \
>>>>    --with-debug-level="release" \
>>>>    --disable-zip-debug-info \
>>>>    --enable-unlimited-crypto \
>>>>    --with-stdc++lib=dynamic \
>>>>    --disable-warnings-as-errors \
>>>>    --with-num-cores=8
>>>>
>>>> make \
>>>>    DEBUG_BINARIES=true \
>>>>    JAVAC_FLAGS=-g \
>>>>    STRIP_POLICY=no_strip \
>>>>    STRIP="" \
>>>>    DISABLE_INTREE_EC=true \
>>>>    ALT_OBJCOPY=none \
>>>>    LOG=debug \
>>>>    images
>>>>
>>>> Thanks,
>>>> Severin
>>>>
>>>>>>> $ hg paths
>>>>>>> default = http://hg.openjdk.java.net/jdk9/hs-rt/
>>>>>>>
>>>>>>> Do I need to use a different tree these days? What am I
>>>>>>> missing?
>>>>>> No, it should work.
>>>>>> Are you sure you've updated all the sub-trees?
>>>>>>
>>>>>> http://hg.openjdk.java.net/code-tools/trees/
>>>>>> Is a helpful hg extension to keep track of things.
>>>>>>
>>>>>> I've noticed that sometimes "bash get_source.sh" does not
>>>>>> correctly "hg
>>>>>> update" the entire forest.
>>>>> I should have an updated tree, though I usually use:
>>>>> $ hg pull -u
>>>>> $ for i in hotspot corba jaxp jaxws jdk langtools nashorn; do
>>>>> pushd $i; hg pull -u; popd; done
>>>>>
>>>>> I've checked just now and all repos seem to have updated
>>>>> correctly. The
>>>>> CI builder for Zero seems to agree[1]. Note: The above build
>>>>> failure is
>>>>> for a regular server JVM. Not sure what's wrong. I keep looking,
>>>>> thanks!
>>>>>
>>>>> Cheers,
>>>>> Severin
>>>>>
>>>>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/
>>>>> 191/console
>>>>>
>>>>>> /Mikael
>>>>>>
>>>>>>> Thanks,
>>>>>>> Severin
>>>>>>>
>
>



From yasuenag at gmail.com  Fri Dec 11 13:04:55 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 11 Dec 2015 22:04:55 +0900
Subject: RFR: JDK-8036003: Add
	--with-debug-symbols=[none|internal|external|zipped]
In-Reply-To: <566AB8E4.3020901@oracle.com>
References: <5649A3FC.8050909@gmail.com> <5649A82D.8080008@oracle.com>
	<687345981.9751911.1447689110391.JavaMail.zimbra@redhat.com>
	<564A9FE5.5070007@gmail.com> <564C4A09.6010103@oracle.com>
	<20151119161527.GA2971@redhat.com> <564E87B9.3000002@oracle.com>
	<56506DD9.3070500@gmail.com> <5655C721.5080002@oracle.com>
	<5655CB2F.4090709@gmail.com> <565714FF.40801@gmail.com>
	<565C407A.2070905@oracle.com> <565C5E91.5050102@gmail.com>
	<565FE685.4020601@oracle.com> <56677657.1000107@gmail.com>
	<5667AA37.6020409@oracle.com> <566A0F00.3030804@gmail.com>
	<566AB8E4.3020901@oracle.com>
Message-ID: <566AC9F7.4070909@gmail.com>

Hi Magnus,

Thank you for reviewing!

> I like the new way of passing a help text for deprecation. Just a note, in the help text you called the new option "--with-debug-symbols" instead of "--with-native-debug-symbols", which is kind of unhelpful. ;-) You can just fix this, no need to upload a new webrev.

Sorry, I've fixed it and pushed.


Thank you so much!

Yasumasa


On 2015/12/11 20:52, Magnus Ihse Bursie wrote:
> On 2015-12-11 00:47, Yasumasa Suenaga wrote:
>> Hi build folks,
>>
>> Could you review it?
>>
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.06/
>
> I like the new way of passing a help text for deprecation. Just a note, in the help text you called the new option "--with-debug-symbols" instead of "--with-native-debug-symbols", which is kind of unhelpful. ;-) You can just fix this, no need to upload a new webrev.
>
> So, if you just fix this, I'm okay with the patch.
>
> Thank you for fighting this all the way through. I do apologize for the slow process.
>
> /Magnus


From magnus.ihse.bursie at oracle.com  Fri Dec 11 13:10:37 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 14:10:37 +0100
Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works
In-Reply-To: <1449759745.3577.22.camel@redhat.com>
References: <1449656620.3543.3.camel@redhat.com> <5668054C.6030708@oracle.com>
	<1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com>
	<56685852.80705@oracle.com> <1449683585.3543.88.camel@redhat.com>
	<56699106.2000709@oracle.com> <1449759745.3577.22.camel@redhat.com>
Message-ID: <566ACB4D.6050405@oracle.com>

On 2015-12-10 16:02, Severin Gehwolf wrote:
> Yes, pretty please :) This is a long standing issue (not just java
> class debug info, but debug info in general). See
> JDK-8036003 with review thread:
> http://mail.openjdk.java.net/pipermail/build-dev/2015-December/016155.html
>
> Once JDK-8036003 is fixed we'd need something similar for Java classes
> and we can get rid of invoking make with build internal variables.

I agree. Yasumasa Suenaga had a pretty good implementation in 
http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/.

I think it could form the basis of getting a proper java debug symbol 
support flag to configure. My main issue with that is that it must also 
work with the case  "--enable-debug --disable-java-debug-symbols", to 
produce a build without java debug symbols. This means that this logic 
need to interact with the logic in flags.m4:
   case $DEBUG_LEVEL in
     fastdebug | slowdebug )
       CFLAGS_JDK="$CFLAGS_JDK $CFLAGS_DEBUG_SYMBOLS $CFLAGS_DEBUG_OPTIONS"
       CXXFLAGS_JDK="$CXXFLAGS_JDK $CXXFLAGS_DEBUG_SYMBOLS 
$CXXFLAGS_DEBUG_OPTIONS"
       JAVAC_FLAGS="$JAVAC_FLAGS -g"

Without digging a bit deeper in the source, I can't say the best way to 
achieve this. Perhaps the configure flag check should set a variable 
like JAVA_DEBUG_SYMBOLS:=true/false/default that can be checked in 
flags.m4? Or we should defer the modification of JAVAC_FLAGS.

/Magnus



From magnus.ihse.bursie at oracle.com  Fri Dec 11 13:16:25 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 14:16:25 +0100
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <565FA4ED.8080904@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com>
Message-ID: <566ACCA9.7060904@oracle.com>

On 2015-12-03 03:11, Roger Riggs wrote:
> Hi,
>
> It would be useful to figure out the number of cpus available when in 
> a container.
> Some comments have added to:
> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793> 
> getAvailableProcessors may incorrectly report the number of cpus in 
> Docker container
>
> But so far we haven't dug deep enough.   Suggestions are welcome?
http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container 
suggests running nproc. I'm not sure if that can be counted on to be 
present, but we could certainly check for it.

/Magnus

>
> Roger
>
>
> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>> Not to say you shouldn't do this, but I worry that increasingly 
>> computing
>> is being done in "containers" where e.g. the number of cpus is doubling
>> every year but only a small number are available to actually be used 
>> by a
>> given process.  if availableProcessors reports 1 million, what should we
>> do?  (no need to answer...)
>>
>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson <erik.joelsson at oracle.com>
>> wrote:
>>
>>> Hello,
>>>
>>> The current heuristic for figuring out what to default set the -j 
>>> flag to
>>> make needs some tweaking.
>>>
>>> In JDK 9, it looks at the amount of memory and the number of cpus in 
>>> the
>>> system. It divides memory by 1024 to get a safe number of jobs that 
>>> will
>>> fit into memory. The lower of that number and the number of cpus is 
>>> then
>>> picked. The number is then scaled down to about 90% of the number of 
>>> cpus
>>> to leave some resources for other activities. It is also capped at 16.
>>>
>>> Since we now have the build using "nice" to make sure the build isn't
>>> bogging down the system, I see no reason to do the 90% scaling anymore.
>>> Also, the performance issues that forced us to cap at 16 have long been
>>> fixed, and even if we don't scale well beyond 16, we do still scale. 
>>> So I
>>> propose we remove that arbitrary limitation too.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>
>>> /Erik
>>>
>



From david.holmes at oracle.com  Fri Dec 11 13:21:45 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Dec 2015 23:21:45 +1000
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <566ACCA9.7060904@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
Message-ID: <566ACDE9.20901@oracle.com>

On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
> On 2015-12-03 03:11, Roger Riggs wrote:
>> Hi,
>>
>> It would be useful to figure out the number of cpus available when in
>> a container.
>> Some comments have added to:
>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>> getAvailableProcessors may incorrectly report the number of cpus in
>> Docker container
>>
>> But so far we haven't dug deep enough.   Suggestions are welcome?
> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
> suggests running nproc. I'm not sure if that can be counted on to be
> present, but we could certainly check for it.

I'd like to know how nproc does it so we can try to apply the same logic 
in the VM for Runtime.availableProcessors. Can someone actually confirm 
that it returns the number of processors available to the container?

David

> /Magnus
>
>>
>> Roger
>>
>>
>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>> Not to say you shouldn't do this, but I worry that increasingly
>>> computing
>>> is being done in "containers" where e.g. the number of cpus is doubling
>>> every year but only a small number are available to actually be used
>>> by a
>>> given process.  if availableProcessors reports 1 million, what should we
>>> do?  (no need to answer...)
>>>
>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson <erik.joelsson at oracle.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> The current heuristic for figuring out what to default set the -j
>>>> flag to
>>>> make needs some tweaking.
>>>>
>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>> the
>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>> will
>>>> fit into memory. The lower of that number and the number of cpus is
>>>> then
>>>> picked. The number is then scaled down to about 90% of the number of
>>>> cpus
>>>> to leave some resources for other activities. It is also capped at 16.
>>>>
>>>> Since we now have the build using "nice" to make sure the build isn't
>>>> bogging down the system, I see no reason to do the 90% scaling anymore.
>>>> Also, the performance issues that forced us to cap at 16 have long been
>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>> So I
>>>> propose we remove that arbitrary limitation too.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>
>>>> /Erik
>>>>
>>
>


From sgehwolf at redhat.com  Fri Dec 11 13:55:35 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 11 Dec 2015 14:55:35 +0100
Subject: RFR: JDK-8145115: make JAVAC_FLAGS=-g no longer works
In-Reply-To: <566ACB4D.6050405@oracle.com>
References: <1449656620.3543.3.camel@redhat.com>
	<5668054C.6030708@oracle.com> <1449659738.3543.28.camel@redhat.com>
	<1449664422.3543.37.camel@redhat.com> <56685852.80705@oracle.com>
	<1449683585.3543.88.camel@redhat.com> <56699106.2000709@oracle.com>
	<1449759745.3577.22.camel@redhat.com> <566ACB4D.6050405@oracle.com>
Message-ID: <1449842135.4547.51.camel@redhat.com>

On Fri, 2015-12-11 at 14:10 +0100, Magnus Ihse Bursie wrote:
> On 2015-12-10 16:02, Severin Gehwolf wrote:
> > Yes, pretty please :) This is a long standing issue (not just java
> > class debug info, but debug info in general). See
> > JDK-8036003 with review thread:
> > http://mail.openjdk.java.net/pipermail/build-dev/2015-December/016155.html
> > 
> > Once JDK-8036003 is fixed we'd need something similar for Java classes
> > and we can get rid of invoking make with build internal variables.
> 
> I agree. Yasumasa Suenaga had a pretty good implementation in?
> http://cr.openjdk.java.net/~ysuenaga/JDK-8036003/webrev.04/.
> 
> I think it could form the basis of getting a proper java debug symbol?
> support flag to configure. My main issue with that is that it must also?
> work with the case??"--enable-debug --disable-java-debug-symbols", to?
> produce a build without java debug symbols. This means that this logic?
> need to interact with the logic in flags.m4:
> ???case $DEBUG_LEVEL in
> ?????fastdebug | slowdebug )
> ???????CFLAGS_JDK="$CFLAGS_JDK $CFLAGS_DEBUG_SYMBOLS $CFLAGS_DEBUG_OPTIONS"
> ???????CXXFLAGS_JDK="$CXXFLAGS_JDK $CXXFLAGS_DEBUG_SYMBOLS?
> $CXXFLAGS_DEBUG_OPTIONS"
> ???????JAVAC_FLAGS="$JAVAC_FLAGS -g"
> 
> Without digging a bit deeper in the source, I can't say the best way to?
> achieve this. Perhaps the configure flag check should set a variable?
> like JAVA_DEBUG_SYMBOLS:=true/false/default that can be checked in?
> flags.m4? Or we should defer the modification of JAVAC_FLAGS.

OK. Thanks for the info. I've created this bug for this enhancement:
https://bugs.openjdk.java.net/browse/JDK-8145188

Cheers,
Severin



From volker.simonis at gmail.com  Fri Dec 11 13:57:47 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 11 Dec 2015 14:57:47 +0100
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <566A5575.3020908@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
	<566906CE.2050101@oracle.com>
	<CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>
	<566A5575.3020908@oracle.com>
Message-ID: <CA+3eh11ONGe4ix3Y1JMPmpXcAenkyUjWVy=S8UCjU0D=OS6FRw@mail.gmail.com>

Hi Sasha, David,

I've just verified that your patch still works for linux/ppc64. I've
built and smoke-tested both linux/ppc64 and ppc64le and everything
looks good. So from my side this is ready to push.

Thanks for finally getting this ready!
Volker


On Fri, Dec 11, 2015 at 5:47 AM, David Holmes <david.holmes at oracle.com> wrote:
> On 11/12/2015 2:15 PM, Alexander Smundak wrote:
>>
>> I have jcheck enabled, so I am surprised that the absence of the
>> Reviewed-by: field was not flagged. Anyways, here's the new set:
>
>
> Not sure what is going on with your jcheck setup but the formatting is still
> wrong:
>
> - the changeset "user" must be OpenJDK username not email address
> - reviewers must be OpenJDK user names not email addresses
> - contributed-by attribution should be simple email address or the following
> is also allowed:
>   Andrew Hughes <gnu.andrew at redhat.com>
>
> Sorry.
>
> David
> -----
>
>
>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.04
>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.04
>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.04
>>
>> Note that I don't have access to the big-endian PowerPC64. The
>> original patch was verified by goetz.lindenmaier at sap.com, but it has
>> changed since. Goetz, can you verify that the new patch still works?
>>
>> Sasha
>>
>> On Wed, Dec 9, 2015 at 8:59 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> On 10/12/2015 4:16 AM, Alexander Smundak wrote:
>>>>
>>>>
>>>> I am confused -- is there anything you want me to change in the existing
>>>> set:
>>>>
>>>> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.03
>>>> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.03
>>>> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.03
>>>
>>>
>>>
>>> Yes they need to be created using the correct, jcheck[1] compliant,
>>> commit
>>> messages:
>>>
>>> http://openjdk.java.net/guide/producingChangeset.html
>>>
>>> Mainly Reviewers seem to be missing - but I'm also not sure other details
>>> are jcheck compliant.
>>>
>>> Thanks,
>>> David
>>>
>>> [1] http://openjdk.java.net/projects/code-tools/jcheck/
>>>
>>>
>>>> Sasha
>>>>
>>>> On Tue, Dec 8, 2015 at 7:10 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> I can sponsor for you Sasha. Just email me the changeset, or a link
>>>>> thereto.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>> On 9/12/2015 3:44 AM, Alexander Smundak wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thank you for the review.
>>>>>> If everyone involved is satisfied with the patch, I need a sponsor.
>>>>>>
>>>>>> Sasha
>>>>>>
>>>>>> On Mon, Dec 7, 2015 at 8:46 PM, David Holmes <david.holmes at oracle.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 8/12/2015 1:44 PM, Alexander Smundak wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It is achievable by adding a small ppc-specific check to the
>>>>>>>> common/autoconf/platform.m4:
>>>>>>>>
>>>>>>>> @@ -282,6 +282,8 @@
>>>>>>>>        elif test "x$OPENJDK_TARGET_OS" != xmacosx && test
>>>>>>>> "x$OPENJDK_TARGET_CPU" = xx86_64; then
>>>>>>>>          # On all platforms except MacOSX replace x86_64 with amd64.
>>>>>>>>          OPENJDK_TARGET_CPU_LEGACY="amd64"
>>>>>>>> +  elif test "x$OPENJDK_TARGET_CPU" = xppc64le; then
>>>>>>>> +    OPENJDK_TARGET_CPU_LEGACY="ppc64"
>>>>>>>>        fi
>>>>>>>>        AC_SUBST(OPENJDK_TARGET_CPU_LEGACY)
>>>>>>>>
>>>>>>>> However, there is a code in make/Images.gmk using
>>>>>>>> OPENJDK_TARGET_CPU_LEGACY
>>>>>>>>       $(call info-file-item, "OS_ARCH",
>>>>>>>> "$(OPENJDK_TARGET_CPU_LEGACY)")
>>>>>>>> so that the 'release' file in the image directory will now have
>>>>>>>> JAVA_VERSION="9"
>>>>>>>> JAVA_FULL_VERSION="9-internal+0-2015-12-07-190811.asmundak.hs-rt"
>>>>>>>> OS_NAME="Linux"
>>>>>>>> OS_VERSION="2.6"
>>>>>>>> OS_ARCH="ppc64"
>>>>>>>>             ^^^^^^^^
>>>>>>>> SOURCE=..,
>>>>>>>>
>>>>>>>> instead of "ppc64le".
>>>>>>>>
>>>>>>>> If someone can tell me which other variable I should use to achieve
>>>>>>>> that without changing the contents of the 'release' file on other
>>>>>>>> platforms, I'll be grateful.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Okay never mind - and thanks for looking into this. I see now this is
>>>>>>> set
>>>>>>> via:
>>>>>>>
>>>>>>> ./autoconf/flags.m4:  COMMON_CCXXFLAGS_JDK="$COMMON_CCXXFLAGS_JDK
>>>>>>> -DARCH='\"$OPENJDK_TARGET_CPU_LEGACY\"' -D$OPENJDK_TARGET_CPU_LEGACY"
>>>>>>>
>>>>>>> so there is no way to add a second value without introducing some
>>>>>>> additional
>>>>>>> variable. At the hotspot level it could be handled differently if we
>>>>>>> had
>>>>>>> a
>>>>>>> platform_ppc64le file, as it could just be added to the SYSDEFS.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David


From erik.joelsson at oracle.com  Fri Dec 11 14:50:59 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 11 Dec 2015 15:50:59 +0100
Subject: RFR: JDK-8145185: Rename JAB the build tool to JIB
Message-ID: <566AE2D3.6020305@oracle.com>

Hello,

Since the acronym JAB was already taken by Java Access Bridge, we nee 
dto find a new name for the new build tool. The new name will be JIB - 
The JDK Integrated Build tool. All references and file names associated 
with JAB in the JDK 9 repos need to be changed to JIB.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145185
Webrev: http://cr.openjdk.java.net/~erikj/8145185/webrev.01/

/Erik


From erik.joelsson at oracle.com  Fri Dec 11 15:00:29 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 11 Dec 2015 16:00:29 +0100
Subject: RFR: JDK-8145008: Add libelf package to Linux devkit
Message-ID: <566AE50D.10202@oracle.com>

The devkit used for building OracleJDK on linux needs to add libelf. 
Here is the patch to the devkit creation makefiles to make that happen.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145008
Patch:
diff --git a/make/devkit/Tools.gmk b/make/devkit/Tools.gmk
--- a/make/devkit/Tools.gmk
+++ b/make/devkit/Tools.gmk
@@ -82,7 +82,9 @@
      libXi libXi-devel \
      libXdmcp libXdmcp-devel \
      libXau libXau-devel \
-    libgcc
+    libgcc \
+    elfutils elfutils-devel \
+    elfutils-libelf elfutils-libelf-devel


  ifeq ($(ARCH),x86_64)


/Erik


From gary.adams at oracle.com  Fri Dec 11 15:15:24 2015
From: gary.adams at oracle.com (Gary Adams)
Date: Fri, 11 Dec 2015 10:15:24 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
Message-ID: <566AE88C.3040701@oracle.com>

Here's the initial upload of changes that provides support for the ios 
and android ports
for the mobile/dev repos. While there have been some preliminary reviews 
of the code,
there is still more work required before we will look for more thorough 
reviews
and an integration to mobile/jdk9 repos.

   Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
   Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/


Here's a simple configure script to generate a ios-x86_64 build for use
with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH

bash ../../configure \
     --openjdk-target=x86_64-macos-ios \
     --with-boot-jdk=$JAVA_HOME \
     --disable-warnings-as-errors \
     --disable-headful \
     --enable-static-build=yes \
     --with-jvm-variants=minimal1


Also, tested with i586-macos-ios target for 32 bit
with a locally built --with-freetype 2.6.2.


From magnus.ihse.bursie at oracle.com  Fri Dec 11 15:43:11 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 16:43:11 +0100
Subject: RFR: JDK-8145185: Rename JAB the build tool to JIB
In-Reply-To: <566AE2D3.6020305@oracle.com>
References: <566AE2D3.6020305@oracle.com>
Message-ID: <A0EE89E7-6065-472D-A31C-11ACD4526867@oracle.com>

Looks good to me. 

/Magnus

> 11 dec. 2015 kl. 15:50 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Hello,
> 
> Since the acronym JAB was already taken by Java Access Bridge, we nee dto find a new name for the new build tool. The new name will be JIB - The JDK Integrated Build tool. All references and file names associated with JAB in the JDK 9 repos need to be changed to JIB.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145185
> Webrev: http://cr.openjdk.java.net/~erikj/8145185/webrev.01/
> 
> /Erik


From erik.joelsson at oracle.com  Fri Dec 11 15:52:00 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 11 Dec 2015 16:52:00 +0100
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
Message-ID: <566AF120.1010103@oracle.com>

JDK-8036003 broke configure on Macosx:

checking what type of native debug symbols to use... zipped
configure: error: Unable to find objcopy, cannot enable native debug 
symbols

We can only fail for missing objcopy on platforms that actually use it.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/

/Erik


From tim.bell at oracle.com  Fri Dec 11 16:13:13 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 11 Dec 2015 08:13:13 -0800
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
In-Reply-To: <566AF120.1010103@oracle.com>
References: <566AF120.1010103@oracle.com>
Message-ID: <566AF619.7080104@oracle.com>

Erik:

> JDK-8036003 broke configure on Macosx:
>
> checking what type of native debug symbols to use... zipped
> configure: error: Unable to find objcopy, cannot enable native debug 
> symbols
>
> We can only fail for missing objcopy on platforms that actually use it.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
> Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/

Looks good to me.

Tim



From tim.bell at oracle.com  Fri Dec 11 16:15:11 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 11 Dec 2015 08:15:11 -0800
Subject: RFR: JDK-8145185: Rename JAB the build tool to JIB
In-Reply-To: <A0EE89E7-6065-472D-A31C-11ACD4526867@oracle.com>
References: <566AE2D3.6020305@oracle.com>
	<A0EE89E7-6065-472D-A31C-11ACD4526867@oracle.com>
Message-ID: <566AF68F.5050701@oracle.com>

Hi Erik

Looks good to me as well.

/Tim

On 12/11/15 07:43, Magnus Ihse Bursie wrote:
> Looks good to me.
>
> /Magnus
>
>> 11 dec. 2015 kl. 15:50 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>
>> Hello,
>>
>> Since the acronym JAB was already taken by Java Access Bridge, we nee dto find a new name for the new build tool. The new name will be JIB - The JDK Integrated Build tool. All references and file names associated with JAB in the JDK 9 repos need to be changed to JIB.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145185
>> Webrev: http://cr.openjdk.java.net/~erikj/8145185/webrev.01/
>>
>> /Erik



From magnus.ihse.bursie at oracle.com  Fri Dec 11 17:23:18 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 18:23:18 +0100
Subject: RFR: JDK-8145008: Add libelf package to Linux devkit
In-Reply-To: <566AE50D.10202@oracle.com>
References: <566AE50D.10202@oracle.com>
Message-ID: <566B0686.5000901@oracle.com>

On 2015-12-11 16:00, Erik Joelsson wrote:
> The devkit used for building OracleJDK on linux needs to add libelf. 
> Here is the patch to the devkit creation makefiles to make that happen.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145008
> Patch:
> diff --git a/make/devkit/Tools.gmk b/make/devkit/Tools.gmk
> --- a/make/devkit/Tools.gmk
> +++ b/make/devkit/Tools.gmk
> @@ -82,7 +82,9 @@
>      libXi libXi-devel \
>      libXdmcp libXdmcp-devel \
>      libXau libXau-devel \
> -    libgcc
> +    libgcc \
> +    elfutils elfutils-devel \
> +    elfutils-libelf elfutils-libelf-devel
>
>
>  ifeq ($(ARCH),x86_64)
>
>
> /Erik

Looks good to me.

/Magnus


From asmundak at google.com  Fri Dec 11 19:05:19 2015
From: asmundak at google.com (Alexander Smundak)
Date: Fri, 11 Dec 2015 11:05:19 -0800
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CA+3eh11ONGe4ix3Y1JMPmpXcAenkyUjWVy=S8UCjU0D=OS6FRw@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
	<566906CE.2050101@oracle.com>
	<CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>
	<566A5575.3020908@oracle.com>
	<CA+3eh11ONGe4ix3Y1JMPmpXcAenkyUjWVy=S8UCjU0D=OS6FRw@mail.gmail.com>
Message-ID: <CAHQ51u6DCTSudcboaY9FGLZRMYr-a+uEq2u9+Q77ikCYhD3LTA@mail.gmail.com>

On Fri, Dec 11, 2015 at 5:57 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> I've just verified that your patch still works for linux/ppc64. I've
> built and smoke-tested both linux/ppc64 and ppc64le and everything
> looks good. So from my side this is ready to push.
Thanks.

Here's the new revision, with headers verified by jcheck:

http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.05
http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.05
http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.05

Sasha


From magnus.ihse.bursie at oracle.com  Fri Dec 11 20:20:15 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 21:20:15 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <564A897D.7010707@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
	<5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com>
	<5649C8B8.2000707@oracle.com> <564A897D.7010707@oracle.com>
Message-ID: <566B2FFF.3090109@oracle.com>

I'm trying to resurrect this review.

Here is a new version:
http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.03

I have dropped all the changes related to -g and OPT_CFLAGS. I'm not 
interested in that kind of large scale operations on the old build 
system, I just wanted to transfer the small patches we have in the 
build-infra forest to mainline to facilitate comparison between old and 
new build. If that was too problematic, let's skip it.

Remaining changes are:
  * Making adlc more quiet
  * Sorting the windows build

Also, in the meantime, a new difference has surfaced. In the first push 
of the new hotspot build system, the rewrite of SA, the file 
make/bsd/makefiles/saproc.make unfortunately was not deleted in 
mainline. I added the deletion of this file.

I intend to push this through hs-rt. David and Erik, please confirm that 
these changes are OK for you.

/Magnus


On 2015-11-17 02:57, David Holmes wrote:
> On 16/11/2015 10:14 PM, Erik Joelsson wrote:
>> On 2015-11-16 12:11, David Holmes wrote:
>>> On 16/11/2015 6:22 PM, Erik Joelsson wrote:
>>>> On 2015-11-16 03:10, David Holmes wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> make/bsd/makefiles/amd64.make:
>>>>>>> make/bsd/makefiles/gcc.make:
>>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) 
>>>>>>> $(OPT_CFLAGS/$(BUILDARCH))"
>>>>>>> should be reversed to guarantee that NOOPT is the one used in case
>>>>>>> BUILDARCH contains something that conflicts? The solaris file 
>>>>>>> does it
>>>>>>> this way.
>>>>>> You know you wrote that code originally? ;-)
>>>>>>
>>>>>> Yeah, I agree, it's more reasonable. Updated webrev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I don't like this particular change as it is too generic. It gives 
>>>>> the
>>>>> appearance of being apply to apply whatever the BUILDARCH specific
>>>>> optflags are, which makes no sense if the whole point here is to not
>>>>> optimize these files. If all this is intended to do is include -g 
>>>>> then
>>>>> I think that should be done explicitly.
>>>>>
>>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume
>>>> the intention was to have it added to all compilation command lines.
>>>> However, the OPT_CFLAGS/<filename> variable overrides
>>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files
>>>> where we explicitly change the optimization level. The patch 
>>>> intends to
>>>> make sure -g is used on those files too.
>>>
>>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH
>>> means -g (why???), or that putting other things in that variable might
>>> break files that should not be optimized.
>>>
>>>> A cleaner solution would be to not have -g be part of the OPT flags at
>>>> all but its own set of DEBUG_CFLAGS.
>>>
>>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway
>>> if all we are interested in is adding -g then I agree it should have
>>> its own variable.
>>>
>> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS
>> and OPT_CFLAGS. These get picked depending on the debug level of the
>> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to
>> CFLAGS.
>>
>> I can't really see a better way of making sure the -g does not fall off
>> for some files than what is proposed here. At least not without
>> completely reworking the flags handling in the current hotspot
>> makefiles, something I'm very uninterested in doing.
>
> In the -g case what we are handling is the addition of -g to product 
> builds (it is already on fastdebug, debug) when 
> ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures. 
> As a convenience we define it thus (BSD version):
>
> OPT_CFLAGS/ia64 = -g
> OPT_CFLAGS/amd64 = -g
> OPT_CFLAGS/arm = -g
> OPT_CFLAGS/ppc = -g
> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH))
>
> so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy 
> if the above were changed to:
>
> FDS_CFLAGS/ia64 = -g
> FDS_CFLAGS/amd64 = -g
> FDS_CFLAGS/arm = -g
> FDS_CFLAGS/ppc = -g
> OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH))
>
> and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file" 
> definitions, where it would be much clearer what kind of flag is 
> actually being applied. However this needs to be done everywhere, and 
> I don't see this fix attempting to do that. We set 
> OPT_CFLAGS/<filename> in numerous places (open and closed) to regain 
> control over the "opt" flags applied to that file. Sometimes we use 
> predefined opt flags, like NOOPT or SPEED, and sometimes we don't eg:
>
> linux/makefiles/amd64.make
>
> OPT_CFLAGS/compactingPermGenGen.o = -O1
>
> This would need to be applied to every occurrence of the "byfile" 
> definitions in all the makefiles. Or else ascertained on a 
> case-by-case basis that we don't want -g for a specific file.
>
> Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set 
> you still have to somehow handle the rest of the above logic:
>
>  507     ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
>  508       ifeq ($(USE_CLANG), true)
>  509         # Clang doesn't understand -gstabs
>  510         OPT_CFLAGS += -g
>  511       else
>  512         OPT_CFLAGS += -gstabs
>  513       endif
>  514     endif
>
> else you again fail to set -g or -gstabs on the "by-file" definitions.
>
> Also looking at the change in make/solaris/makefiles/amd64.make you 
> have taken the file specific flags:
>
>  OPT_CFLAGS/generateOptoStub.o = -xO2
>
> and added the generic OPT_CFLAGS value:
>
> OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2
>
> which seems extremely dubious from a correctness perspective.
>
> Thanks,
> David
> -----
>
>>>>> ---
>>>>>
>>>>> make/bsd/makefiles/saproc.make
>>>>>
>>>>> ! # Order src files alfabetically
>>>>>
>>>>> That would be "alphabetically". But that list doesn't seem alphabetic
>>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and
>>>>> $(AGENTDIR) should come first. I really see no point in forcing such
>>>>> lists to be in alphabetic order.
>>>>>
>>>> This is to make comparison of binaries between the old hotspot 
>>>> build and
>>>> the new hotspot build easier. In build-infra, we $(sort ) the object
>>>> files before linking to get a reproducible order. The linker output is
>>>> affected by the order of the object files. By making sure the old and
>>>> the new build sorts them the same way, we get cleaner comparisons and
>>>> can more easily detect other types of differences through those
>>>> comparisons. The sort order isn't strictly alphabetical, it's on byte
>>>> order so upper case goes before lower case.
>>>
>>> I saw the change for the ordered object files on Windows, but this
>>> simply orders source files in a list. Not sure how that has any affect
>>> on the linking ??
>>>
>> It has an effect on the linking because that list is used verbatim on
>> the combined compile/link command line.
>>
>> /Erik
>>> Cheers,
>>> David
>>>
>>>> /Erik
>>>>> make/linux/makefiles/saproc.make doesn't have the comment that was
>>>>> added for bsd.
>>>>>
>>>>> ----
>>>>>
>>>>> make/solaris/makefiles/amd64.make
>>>>>
>>>>> Similar issue with bsd amd64.make. Not sure what you are trying to
>>>>> achieve here - is it some kind of last option wins situation ?
>>>>>
>>>>> ---
>>>>>
>>>>> make/windows/create_obj_files.sh
>>>>>
>>>>> Harmless I guess but not sure about relevance of sort order here.
>>>>>
>>>>> ----
>>>>>
>>>>>  src/share/vm/adlc/adlparse.cpp
>>>>>
>>>>> So that's where that comes from! :)
>>>>>
>>>>> ---
>>>>>
>>>>> src/share/vm/gc/g1/g1EvacStats.cpp
>>>>>
>>>>> I don't see anything in the cpp files that uses anything from the
>>>>> atomic class ???
>>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>>
>>>>>>> Otherwise looks good.
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>>>>>> In the new hotspot build project, we have made a few changes to 
>>>>>>>> the
>>>>>>>> existing build. In preparation for the new build, I'd like to
>>>>>>>> integrate these into mainline.
>>>>>>>>
>>>>>>>> These changes are:
>>>>>>>> * When overriding optimization, do not lose current debug (-g)
>>>>>>>> setting (!)
>>>>>>>> * Make adlc actually quiet in quiet mode
>>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled
>>>>>>>> headers
>>>>>>>> * Sort saproc object files when linking (facilitates comparison to
>>>>>>>> new build)
>>>>>>>>
>>>>>>>> Unless someone suggests otherwise, I intend to push this (using
>>>>>>>> JPRT)
>>>>>>>> to hs-rt.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>>>>>> WebRev:
>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> /Magnus
>>>>>>>
>>>>>>
>>>>
>>



From magnus.ihse.bursie at oracle.com  Fri Dec 11 21:43:07 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 22:43:07 +0100
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <56495C9C.5070501@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
Message-ID: <566B436B.90506@oracle.com>

Hi David,

Resurrecting the second part of the build-infra integrations. :) 
Fortunately, no major code changes in the meantime has affected this 
patch. (I did need to update the new 
hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)


On 2015-11-16 05:33, David Holmes wrote:
> Hi Magnus,
>
> I had a flick through most of the files. Overall seems okay but I have 
> a few queries below.

Replies inline.

>
> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>> The build-infra project has collected a number of minor fixes and
>> changes during the new hotspot build development. It&#39;s a mix of code
>> cleanup and new capabilities.
>>
>> Not all of these new features are immediately beneficial to the JDK, but
>> they will be needed for the upcoming new Hotspot build, and it will not
>> hurt to have them in mainline. (In fact, it will tremendously help
>> merging between mainline and build-infra.)
>>
>> The fix addresses these issues:
>>
>> In general:
>> * Break out hotspot configuration into hotspot.m4
>> * Long link lines uses @-files
>> * Consistently use -Wl instead of -Xlinker
>> * Improve clang on linux compilation
>> * Set shared library name explicitely on solaris
>> * Set correct shared library flag on Windows (-dll)
>> * Consistency fixes for build toolchain
>> * Bring compare script up to date
>> * General code/whitespace cleanup
>> * Additional functionality in MakeBase
>>
>> In NativeCompilation.gmk:
>> * More efficient vardeps for per-file CFLAGS
>> * Fewer shell executions (means better performance on Windows)
>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>> * Debug symbols on macosx (disabled for existing code to keep current
>> behavior)
>>
>> Enabling debug info on macosx on existing jdk should be treated in a
>> follow-up bug.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01 
>>
>>
>>
>> (It turned out that WebRev could not at the same time include files from
>> multiple repos and track the history of a "hg cp":ied file. So I created
>> an alternative revision here:
>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/ 
>>
>>
>>
>> It does not include the jdk files, but hotspot.m4 might be easier to
>> understand)
>
> flags.m4:
>
>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>   63
>   64   AC_SUBST(EXTRA_CFLAGS)
>   65   AC_SUBST(EXTRA_CXXFLAGS)
>   66   AC_SUBST(EXTRA_LDFLAGS)
>
> IIRC we added the legacy flags purely to pass the cross-compilation 
> args through to hotspot. Not sure why we need both legacy and 
> non-legancy variants now ??

This is part of an ongoing effort to split CFLAGS_JDK into more 
reasonable parts. The current model is that we throw all possible flags 
together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et al). 
While it was questionable even before, it did work when we only built 
the JDK native libraries. Now that we need to build libjvm.so as well, 
which has (for historical reason) a set of flags that are both partially 
the same and partially different, this is not so good.

We would like to see a change to a situation where the different "parts" 
that we build CFLAGS_JDK from would be handled separately, and then 
combined as needed for JDK libraries, and for Hotspot. So, currently we 
use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and then drop them. In 
the new Hotspot build, we use the EXTRA_CFLAGS to add them to the 
Hotspot flags. Of course, we could have used LEGACY_EXTRA_CFLAGS, but 
we'd like to avoid using "LEGACY" for new stuff.

With that being said, I now realize that maybe this change will not be 
needed anyway, at least not right now. Since doing a proper flag cleanup 
is a major task, we decided to copy the CFLAGS_JDK behavior for Hotspot 
flags as well in the current implementation of the new hotspot build, 
and saving the cleanup for another day (so it will not block the new 
build system). So I'll revert this part of the change for now.

> On Windows -LD is a superset of -dll, so it isn't obvious the change 
> is correct.
I hope Erik's reply to that was satisfactory.
>
> ---
>
> jdk/make/lib/LibCommon.gmk
>
> + # Disable it here for the jdk binaries until we decide to enable them.
>
> s/binaries/libraries/ ?
Sure, I'll fix.

> Actually both this fragment and the one in 
> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the 
> relation with hotspot here, and the role of SetupNativeCompilation?
I hope Erik's reply to that is acceptable as well. As for the other 
changes in the jdk repo, most of them is to either standardize on -Wl, 
or to fix some places were we didn't do a proper $$ (instead of $) in an 
macro that was supposed to be eval'd. (This was incorrect before as 
well, but it broke the build when the LDFLAGS started having commas in 
them.)

/Magnus

>
> Thanks,
> David
>
>
>> /Magnus



From magnus.ihse.bursie at oracle.com  Fri Dec 11 22:24:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2015 23:24:09 +0100
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <566B436B.90506@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
	<566B436B.90506@oracle.com>
Message-ID: <566B4D09.5050601@oracle.com>

On 2015-12-11 22:43, Magnus Ihse Bursie wrote:
> Hi David,
>
> Resurrecting the second part of the build-infra integrations. :) 
> Fortunately, no major code changes in the meantime has affected this 
> patch. (I did need to update the new 
> hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)

It seems I forgot to include the link to the new webrev:

http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05

/Magnus

>
>
> On 2015-11-16 05:33, David Holmes wrote:
>> Hi Magnus,
>>
>> I had a flick through most of the files. Overall seems okay but I 
>> have a few queries below.
>
> Replies inline.
>
>>
>> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>>> The build-infra project has collected a number of minor fixes and
>>> changes during the new hotspot build development. It&#39;s a mix of 
>>> code
>>> cleanup and new capabilities.
>>>
>>> Not all of these new features are immediately beneficial to the JDK, 
>>> but
>>> they will be needed for the upcoming new Hotspot build, and it will not
>>> hurt to have them in mainline. (In fact, it will tremendously help
>>> merging between mainline and build-infra.)
>>>
>>> The fix addresses these issues:
>>>
>>> In general:
>>> * Break out hotspot configuration into hotspot.m4
>>> * Long link lines uses @-files
>>> * Consistently use -Wl instead of -Xlinker
>>> * Improve clang on linux compilation
>>> * Set shared library name explicitely on solaris
>>> * Set correct shared library flag on Windows (-dll)
>>> * Consistency fixes for build toolchain
>>> * Bring compare script up to date
>>> * General code/whitespace cleanup
>>> * Additional functionality in MakeBase
>>>
>>> In NativeCompilation.gmk:
>>> * More efficient vardeps for per-file CFLAGS
>>> * Fewer shell executions (means better performance on Windows)
>>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>>> * Debug symbols on macosx (disabled for existing code to keep current
>>> behavior)
>>>
>>> Enabling debug info on macosx on existing jdk should be treated in a
>>> follow-up bug.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01 
>>>
>>>
>>>
>>> (It turned out that WebRev could not at the same time include files 
>>> from
>>> multiple repos and track the history of a "hg cp":ied file. So I 
>>> created
>>> an alternative revision here:
>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/ 
>>>
>>>
>>>
>>> It does not include the jdk files, but hotspot.m4 might be easier to
>>> understand)
>>
>> flags.m4:
>>
>>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>>   63
>>   64   AC_SUBST(EXTRA_CFLAGS)
>>   65   AC_SUBST(EXTRA_CXXFLAGS)
>>   66   AC_SUBST(EXTRA_LDFLAGS)
>>
>> IIRC we added the legacy flags purely to pass the cross-compilation 
>> args through to hotspot. Not sure why we need both legacy and 
>> non-legancy variants now ??
>
> This is part of an ongoing effort to split CFLAGS_JDK into more 
> reasonable parts. The current model is that we throw all possible 
> flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et 
> al). While it was questionable even before, it did work when we only 
> built the JDK native libraries. Now that we need to build libjvm.so as 
> well, which has (for historical reason) a set of flags that are both 
> partially the same and partially different, this is not so good.
>
> We would like to see a change to a situation where the different 
> "parts" that we build CFLAGS_JDK from would be handled separately, and 
> then combined as needed for JDK libraries, and for Hotspot. So, 
> currently we use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and then 
> drop them. In the new Hotspot build, we use the EXTRA_CFLAGS to add 
> them to the Hotspot flags. Of course, we could have used 
> LEGACY_EXTRA_CFLAGS, but we'd like to avoid using "LEGACY" for new stuff.
>
> With that being said, I now realize that maybe this change will not be 
> needed anyway, at least not right now. Since doing a proper flag 
> cleanup is a major task, we decided to copy the CFLAGS_JDK behavior 
> for Hotspot flags as well in the current implementation of the new 
> hotspot build, and saving the cleanup for another day (so it will not 
> block the new build system). So I'll revert this part of the change 
> for now.
>
>> On Windows -LD is a superset of -dll, so it isn't obvious the change 
>> is correct.
> I hope Erik's reply to that was satisfactory.
>>
>> ---
>>
>> jdk/make/lib/LibCommon.gmk
>>
>> + # Disable it here for the jdk binaries until we decide to enable them.
>>
>> s/binaries/libraries/ ?
> Sure, I'll fix.
>
>> Actually both this fragment and the one in 
>> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the 
>> relation with hotspot here, and the role of SetupNativeCompilation?
> I hope Erik's reply to that is acceptable as well. As for the other 
> changes in the jdk repo, most of them is to either standardize on -Wl, 
> or to fix some places were we didn't do a proper $$ (instead of $) in 
> an macro that was supposed to be eval'd. (This was incorrect before as 
> well, but it broke the build when the LDFLAGS started having commas in 
> them.)
>
> /Magnus
>
>>
>> Thanks,
>> David
>>
>>
>>> /Magnus
>



From david.holmes at oracle.com  Sat Dec 12 12:40:31 2015
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 12 Dec 2015 22:40:31 +1000
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
In-Reply-To: <566AF120.1010103@oracle.com>
References: <566AF120.1010103@oracle.com>
Message-ID: <566C15BF.7030504@oracle.com>

On 12/12/2015 1:52 AM, Erik Joelsson wrote:
> JDK-8036003 broke configure on Macosx:
>
> checking what type of native debug symbols to use... zipped
> configure: error: Unable to find objcopy, cannot enable native debug
> symbols
>
> We can only fail for missing objcopy on platforms that actually use it.

Silly question but how do we do the zipped debuginfo on platforms 
without an objcopy ??

Thanks,
David

> Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
> Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/
>
> /Erik


From yasuenag at gmail.com  Sat Dec 12 12:48:48 2015
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sat, 12 Dec 2015 21:48:48 +0900
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
In-Reply-To: <566C15BF.7030504@oracle.com>
References: <566AF120.1010103@oracle.com> <566C15BF.7030504@oracle.com>
Message-ID: <566C17B0.9090103@gmail.com>

I agree to David.

If your environment does not have objcopy, you should set --with-native-debug-symbols
to internal or none.


Thanks,

Yasumasa


On 2015/12/12 21:40, David Holmes wrote:
> On 12/12/2015 1:52 AM, Erik Joelsson wrote:
>> JDK-8036003 broke configure on Macosx:
>>
>> checking what type of native debug symbols to use... zipped
>> configure: error: Unable to find objcopy, cannot enable native debug
>> symbols
>>
>> We can only fail for missing objcopy on platforms that actually use it.
>
> Silly question but how do we do the zipped debuginfo on platforms without an objcopy ??
>
> Thanks,
> David
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
>> Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/
>>
>> /Erik


From erik.joelsson at oracle.com  Sun Dec 13 09:53:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Sun, 13 Dec 2015 10:53:06 +0100
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
In-Reply-To: <566C17B0.9090103@gmail.com>
References: <566AF120.1010103@oracle.com> <566C15BF.7030504@oracle.com>
	<566C17B0.9090103@gmail.com>
Message-ID: <566D4002.7070902@oracle.com>

On Macosx, the utility to use is dsymutil. On Windows, debugsymbols are 
controlled with flags to the compiler and linker. On Linux and Solaris, 
we use objcopy. Each platform is different.

/Erik

On 2015-12-12 13:48, Yasumasa Suenaga wrote:
> I agree to David.
>
> If your environment does not have objcopy, you should set 
> --with-native-debug-symbols
> to internal or none.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2015/12/12 21:40, David Holmes wrote:
>> On 12/12/2015 1:52 AM, Erik Joelsson wrote:
>>> JDK-8036003 broke configure on Macosx:
>>>
>>> checking what type of native debug symbols to use... zipped
>>> configure: error: Unable to find objcopy, cannot enable native debug
>>> symbols
>>>
>>> We can only fail for missing objcopy on platforms that actually use it.
>>
>> Silly question but how do we do the zipped debuginfo on platforms 
>> without an objcopy ??
>>
>> Thanks,
>> David
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
>>> Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/
>>>
>>> /Erik



From david.holmes at oracle.com  Mon Dec 14 01:58:28 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Dec 2015 11:58:28 +1000
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
In-Reply-To: <566D4002.7070902@oracle.com>
References: <566AF120.1010103@oracle.com> <566C15BF.7030504@oracle.com>
	<566C17B0.9090103@gmail.com> <566D4002.7070902@oracle.com>
Message-ID: <566E2244.1090000@oracle.com>

On 13/12/2015 7:53 PM, Erik Joelsson wrote:
> On Macosx, the utility to use is dsymutil. On Windows, debugsymbols are
> controlled with flags to the compiler and linker. On Linux and Solaris,
> we use objcopy. Each platform is different.

Okay so for some reason (that I probably should know) we give objcopy 
special handling in ensuring it exists. Make sense then to only do it on 
the expected platforms.

Thanks,
David

> /Erik
>
> On 2015-12-12 13:48, Yasumasa Suenaga wrote:
>> I agree to David.
>>
>> If your environment does not have objcopy, you should set
>> --with-native-debug-symbols
>> to internal or none.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2015/12/12 21:40, David Holmes wrote:
>>> On 12/12/2015 1:52 AM, Erik Joelsson wrote:
>>>> JDK-8036003 broke configure on Macosx:
>>>>
>>>> checking what type of native debug symbols to use... zipped
>>>> configure: error: Unable to find objcopy, cannot enable native debug
>>>> symbols
>>>>
>>>> We can only fail for missing objcopy on platforms that actually use it.
>>>
>>> Silly question but how do we do the zipped debuginfo on platforms
>>> without an objcopy ??
>>>
>>> Thanks,
>>> David
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/
>>>>
>>>> /Erik
>


From david.holmes at oracle.com  Mon Dec 14 03:49:56 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Dec 2015 13:49:56 +1000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <CAHQ51u6DCTSudcboaY9FGLZRMYr-a+uEq2u9+Q77ikCYhD3LTA@mail.gmail.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
	<566906CE.2050101@oracle.com>
	<CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>
	<566A5575.3020908@oracle.com>
	<CA+3eh11ONGe4ix3Y1JMPmpXcAenkyUjWVy=S8UCjU0D=OS6FRw@mail.gmail.com>
	<CAHQ51u6DCTSudcboaY9FGLZRMYr-a+uEq2u9+Q77ikCYhD3LTA@mail.gmail.com>
Message-ID: <566E3C64.2030506@oracle.com>

On 12/12/2015 5:05 AM, Alexander Smundak wrote:
> On Fri, Dec 11, 2015 at 5:57 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> I've just verified that your patch still works for linux/ppc64. I've
>> built and smoke-tested both linux/ppc64 and ppc64le and everything
>> looks good. So from my side this is ready to push.
> Thanks.
>
> Here's the new revision, with headers verified by jcheck:
>
> http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.05
> http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.05
> http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.05

Thanks for your patience Sasha! Hopefully this will all be trivial next 
time round. I had to rebase the changeset to accommodate the change from:

  8144885: agent/src/os/linux/libproc.h needs to support Linux/SPARC builds

but otherwise all okay. (I didn't want to send it back to you again :) ).

Cheers,
David

> Sasha
>


From david.holmes at oracle.com  Mon Dec 14 07:17:36 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Dec 2015 17:17:36 +1000
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <566B2FFF.3090109@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
	<5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com>
	<5649C8B8.2000707@oracle.com> <564A897D.7010707@oracle.com>
	<566B2FFF.3090109@oracle.com>
Message-ID: <566E6D10.3050502@oracle.com>

Looks trivially fine to me :)

Thanks,
David

On 12/12/2015 6:20 AM, Magnus Ihse Bursie wrote:
> I'm trying to resurrect this review.
>
> Here is a new version:
> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.03
>
>
> I have dropped all the changes related to -g and OPT_CFLAGS. I'm not
> interested in that kind of large scale operations on the old build
> system, I just wanted to transfer the small patches we have in the
> build-infra forest to mainline to facilitate comparison between old and
> new build. If that was too problematic, let's skip it.
>
> Remaining changes are:
>   * Making adlc more quiet
>   * Sorting the windows build
>
> Also, in the meantime, a new difference has surfaced. In the first push
> of the new hotspot build system, the rewrite of SA, the file
> make/bsd/makefiles/saproc.make unfortunately was not deleted in
> mainline. I added the deletion of this file.
>
> I intend to push this through hs-rt. David and Erik, please confirm that
> these changes are OK for you.
>
> /Magnus
>
>
> On 2015-11-17 02:57, David Holmes wrote:
>> On 16/11/2015 10:14 PM, Erik Joelsson wrote:
>>> On 2015-11-16 12:11, David Holmes wrote:
>>>> On 16/11/2015 6:22 PM, Erik Joelsson wrote:
>>>>> On 2015-11-16 03:10, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> make/bsd/makefiles/amd64.make:
>>>>>>>> make/bsd/makefiles/gcc.make:
>>>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT)
>>>>>>>> $(OPT_CFLAGS/$(BUILDARCH))"
>>>>>>>> should be reversed to guarantee that NOOPT is the one used in case
>>>>>>>> BUILDARCH contains something that conflicts? The solaris file
>>>>>>>> does it
>>>>>>>> this way.
>>>>>>> You know you wrote that code originally? ;-)
>>>>>>>
>>>>>>> Yeah, I agree, it's more reasonable. Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I don't like this particular change as it is too generic. It gives
>>>>>> the
>>>>>> appearance of being apply to apply whatever the BUILDARCH specific
>>>>>> optflags are, which makes no sense if the whole point here is to not
>>>>>> optimize these files. If all this is intended to do is include -g
>>>>>> then
>>>>>> I think that should be done explicitly.
>>>>>>
>>>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume
>>>>> the intention was to have it added to all compilation command lines.
>>>>> However, the OPT_CFLAGS/<filename> variable overrides
>>>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files
>>>>> where we explicitly change the optimization level. The patch
>>>>> intends to
>>>>> make sure -g is used on those files too.
>>>>
>>>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH
>>>> means -g (why???), or that putting other things in that variable might
>>>> break files that should not be optimized.
>>>>
>>>>> A cleaner solution would be to not have -g be part of the OPT flags at
>>>>> all but its own set of DEBUG_CFLAGS.
>>>>
>>>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway
>>>> if all we are interested in is adding -g then I agree it should have
>>>> its own variable.
>>>>
>>> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS
>>> and OPT_CFLAGS. These get picked depending on the debug level of the
>>> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to
>>> CFLAGS.
>>>
>>> I can't really see a better way of making sure the -g does not fall off
>>> for some files than what is proposed here. At least not without
>>> completely reworking the flags handling in the current hotspot
>>> makefiles, something I'm very uninterested in doing.
>>
>> In the -g case what we are handling is the addition of -g to product
>> builds (it is already on fastdebug, debug) when
>> ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures.
>> As a convenience we define it thus (BSD version):
>>
>> OPT_CFLAGS/ia64 = -g
>> OPT_CFLAGS/amd64 = -g
>> OPT_CFLAGS/arm = -g
>> OPT_CFLAGS/ppc = -g
>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH))
>>
>> so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy
>> if the above were changed to:
>>
>> FDS_CFLAGS/ia64 = -g
>> FDS_CFLAGS/amd64 = -g
>> FDS_CFLAGS/arm = -g
>> FDS_CFLAGS/ppc = -g
>> OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH))
>>
>> and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file"
>> definitions, where it would be much clearer what kind of flag is
>> actually being applied. However this needs to be done everywhere, and
>> I don't see this fix attempting to do that. We set
>> OPT_CFLAGS/<filename> in numerous places (open and closed) to regain
>> control over the "opt" flags applied to that file. Sometimes we use
>> predefined opt flags, like NOOPT or SPEED, and sometimes we don't eg:
>>
>> linux/makefiles/amd64.make
>>
>> OPT_CFLAGS/compactingPermGenGen.o = -O1
>>
>> This would need to be applied to every occurrence of the "byfile"
>> definitions in all the makefiles. Or else ascertained on a
>> case-by-case basis that we don't want -g for a specific file.
>>
>> Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set
>> you still have to somehow handle the rest of the above logic:
>>
>>  507     ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
>>  508       ifeq ($(USE_CLANG), true)
>>  509         # Clang doesn't understand -gstabs
>>  510         OPT_CFLAGS += -g
>>  511       else
>>  512         OPT_CFLAGS += -gstabs
>>  513       endif
>>  514     endif
>>
>> else you again fail to set -g or -gstabs on the "by-file" definitions.
>>
>> Also looking at the change in make/solaris/makefiles/amd64.make you
>> have taken the file specific flags:
>>
>>  OPT_CFLAGS/generateOptoStub.o = -xO2
>>
>> and added the generic OPT_CFLAGS value:
>>
>> OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2
>>
>> which seems extremely dubious from a correctness perspective.
>>
>> Thanks,
>> David
>> -----
>>
>>>>>> ---
>>>>>>
>>>>>> make/bsd/makefiles/saproc.make
>>>>>>
>>>>>> ! # Order src files alfabetically
>>>>>>
>>>>>> That would be "alphabetically". But that list doesn't seem alphabetic
>>>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and
>>>>>> $(AGENTDIR) should come first. I really see no point in forcing such
>>>>>> lists to be in alphabetic order.
>>>>>>
>>>>> This is to make comparison of binaries between the old hotspot
>>>>> build and
>>>>> the new hotspot build easier. In build-infra, we $(sort ) the object
>>>>> files before linking to get a reproducible order. The linker output is
>>>>> affected by the order of the object files. By making sure the old and
>>>>> the new build sorts them the same way, we get cleaner comparisons and
>>>>> can more easily detect other types of differences through those
>>>>> comparisons. The sort order isn't strictly alphabetical, it's on byte
>>>>> order so upper case goes before lower case.
>>>>
>>>> I saw the change for the ordered object files on Windows, but this
>>>> simply orders source files in a list. Not sure how that has any affect
>>>> on the linking ??
>>>>
>>> It has an effect on the linking because that list is used verbatim on
>>> the combined compile/link command line.
>>>
>>> /Erik
>>>> Cheers,
>>>> David
>>>>
>>>>> /Erik
>>>>>> make/linux/makefiles/saproc.make doesn't have the comment that was
>>>>>> added for bsd.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> make/solaris/makefiles/amd64.make
>>>>>>
>>>>>> Similar issue with bsd amd64.make. Not sure what you are trying to
>>>>>> achieve here - is it some kind of last option wins situation ?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> make/windows/create_obj_files.sh
>>>>>>
>>>>>> Harmless I guess but not sure about relevance of sort order here.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>>  src/share/vm/adlc/adlparse.cpp
>>>>>>
>>>>>> So that's where that comes from! :)
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/gc/g1/g1EvacStats.cpp
>>>>>>
>>>>>> I don't see anything in the cpp files that uses anything from the
>>>>>> atomic class ???
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise looks good.
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>>>>>>> In the new hotspot build project, we have made a few changes to
>>>>>>>>> the
>>>>>>>>> existing build. In preparation for the new build, I'd like to
>>>>>>>>> integrate these into mainline.
>>>>>>>>>
>>>>>>>>> These changes are:
>>>>>>>>> * When overriding optimization, do not lose current debug (-g)
>>>>>>>>> setting (!)
>>>>>>>>> * Make adlc actually quiet in quiet mode
>>>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled
>>>>>>>>> headers
>>>>>>>>> * Sort saproc object files when linking (facilitates comparison to
>>>>>>>>> new build)
>>>>>>>>>
>>>>>>>>> Unless someone suggests otherwise, I intend to push this (using
>>>>>>>>> JPRT)
>>>>>>>>> to hs-rt.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>>>>>>> WebRev:
>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>
>>>>>
>>>
>


From magnus.ihse.bursie at oracle.com  Mon Dec 14 07:46:11 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 14 Dec 2015 08:46:11 +0100
Subject: [urgent] RFR: JDK-8145206: Configure broken on Macosx
In-Reply-To: <566E2244.1090000@oracle.com>
References: <566AF120.1010103@oracle.com> <566C15BF.7030504@oracle.com>
	<566C17B0.9090103@gmail.com> <566D4002.7070902@oracle.com>
	<566E2244.1090000@oracle.com>
Message-ID: <566E73C3.8060202@oracle.com>

On 2015-12-14 02:58, David Holmes wrote:
> On 13/12/2015 7:53 PM, Erik Joelsson wrote:
>> On Macosx, the utility to use is dsymutil. On Windows, debugsymbols are
>> controlled with flags to the compiler and linker. On Linux and Solaris,
>> we use objcopy. Each platform is different.
>
> Okay so for some reason (that I probably should know) we give objcopy 
> special handling in ensuring it exists. Make sense then to only do it 
> on the expected platforms.

For consistency, we should probably check that dsymutil exists as well, 
if creating external debug symbols on macosx. My guess is that not 
having objcopy have been a historical problem (at least has having a 
non-broken objcopy on Solaris been a problem), but not so for dsymutil.

As I've said before, we don't really have a coherent story for debug 
symbols. :-( I think Yasumasa's change was good in that it introduced a 
nice interface towards the user, and it solved the problems, but I'd 
really like to redesign the debug symbol handling "under the hood".

/Magnus

>
> Thanks,
> David
>
>> /Erik
>>
>> On 2015-12-12 13:48, Yasumasa Suenaga wrote:
>>> I agree to David.
>>>
>>> If your environment does not have objcopy, you should set
>>> --with-native-debug-symbols
>>> to internal or none.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2015/12/12 21:40, David Holmes wrote:
>>>> On 12/12/2015 1:52 AM, Erik Joelsson wrote:
>>>>> JDK-8036003 broke configure on Macosx:
>>>>>
>>>>> checking what type of native debug symbols to use... zipped
>>>>> configure: error: Unable to find objcopy, cannot enable native debug
>>>>> symbols
>>>>>
>>>>> We can only fail for missing objcopy on platforms that actually 
>>>>> use it.
>>>>
>>>> Silly question but how do we do the zipped debuginfo on platforms
>>>> without an objcopy ??
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/
>>>>>
>>>>> /Erik
>>



From david.holmes at oracle.com  Mon Dec 14 08:12:42 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Dec 2015 18:12:42 +1000
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <566B4D09.5050601@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
	<566B436B.90506@oracle.com> <566B4D09.5050601@oracle.com>
Message-ID: <566E79FA.4010600@oracle.com>

Hi Magnus,

On 12/12/2015 8:24 AM, Magnus Ihse Bursie wrote:
> On 2015-12-11 22:43, Magnus Ihse Bursie wrote:
>> Hi David,
>>
>> Resurrecting the second part of the build-infra integrations. :)
>> Fortunately, no major code changes in the meantime has affected this
>> patch. (I did need to update the new
>> hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)
>
> It seems I forgot to include the link to the new webrev:
>
> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05

hotspot.m4:

  54 #    server: normal interpreter and a tiered C1/C2 compiler
   55 #    client: normal interpreter and C1 (no C2 compiler) (only 
32-bit platforms)

Neither of these statements are necessarily 100% true - not all 
platforms have tiered enable; some 64-bit platforms do (or will) support 
client.

Otherwise I didn't see anything else that I obviously needed to comment 
on. The proof of this is in the building. So as long as this gets 
through JPRT with -testset hotspot we should be okay. :)

Thanks,
David

>
> /Magnus
>
>>
>>
>> On 2015-11-16 05:33, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> I had a flick through most of the files. Overall seems okay but I
>>> have a few queries below.
>>
>> Replies inline.
>>
>>>
>>> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>>>> The build-infra project has collected a number of minor fixes and
>>>> changes during the new hotspot build development. It&#39;s a mix of
>>>> code
>>>> cleanup and new capabilities.
>>>>
>>>> Not all of these new features are immediately beneficial to the JDK,
>>>> but
>>>> they will be needed for the upcoming new Hotspot build, and it will not
>>>> hurt to have them in mainline. (In fact, it will tremendously help
>>>> merging between mainline and build-infra.)
>>>>
>>>> The fix addresses these issues:
>>>>
>>>> In general:
>>>> * Break out hotspot configuration into hotspot.m4
>>>> * Long link lines uses @-files
>>>> * Consistently use -Wl instead of -Xlinker
>>>> * Improve clang on linux compilation
>>>> * Set shared library name explicitely on solaris
>>>> * Set correct shared library flag on Windows (-dll)
>>>> * Consistency fixes for build toolchain
>>>> * Bring compare script up to date
>>>> * General code/whitespace cleanup
>>>> * Additional functionality in MakeBase
>>>>
>>>> In NativeCompilation.gmk:
>>>> * More efficient vardeps for per-file CFLAGS
>>>> * Fewer shell executions (means better performance on Windows)
>>>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>>>> * Debug symbols on macosx (disabled for existing code to keep current
>>>> behavior)
>>>>
>>>> Enabling debug info on macosx on existing jdk should be treated in a
>>>> follow-up bug.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01
>>>>
>>>>
>>>>
>>>> (It turned out that WebRev could not at the same time include files
>>>> from
>>>> multiple repos and track the history of a "hg cp":ied file. So I
>>>> created
>>>> an alternative revision here:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/
>>>>
>>>>
>>>>
>>>> It does not include the jdk files, but hotspot.m4 might be easier to
>>>> understand)
>>>
>>> flags.m4:
>>>
>>>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>>>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>>>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>>>   63
>>>   64   AC_SUBST(EXTRA_CFLAGS)
>>>   65   AC_SUBST(EXTRA_CXXFLAGS)
>>>   66   AC_SUBST(EXTRA_LDFLAGS)
>>>
>>> IIRC we added the legacy flags purely to pass the cross-compilation
>>> args through to hotspot. Not sure why we need both legacy and
>>> non-legancy variants now ??
>>
>> This is part of an ongoing effort to split CFLAGS_JDK into more
>> reasonable parts. The current model is that we throw all possible
>> flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et
>> al). While it was questionable even before, it did work when we only
>> built the JDK native libraries. Now that we need to build libjvm.so as
>> well, which has (for historical reason) a set of flags that are both
>> partially the same and partially different, this is not so good.
>>
>> We would like to see a change to a situation where the different
>> "parts" that we build CFLAGS_JDK from would be handled separately, and
>> then combined as needed for JDK libraries, and for Hotspot. So,
>> currently we use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and then
>> drop them. In the new Hotspot build, we use the EXTRA_CFLAGS to add
>> them to the Hotspot flags. Of course, we could have used
>> LEGACY_EXTRA_CFLAGS, but we'd like to avoid using "LEGACY" for new stuff.
>>
>> With that being said, I now realize that maybe this change will not be
>> needed anyway, at least not right now. Since doing a proper flag
>> cleanup is a major task, we decided to copy the CFLAGS_JDK behavior
>> for Hotspot flags as well in the current implementation of the new
>> hotspot build, and saving the cleanup for another day (so it will not
>> block the new build system). So I'll revert this part of the change
>> for now.
>>
>>> On Windows -LD is a superset of -dll, so it isn't obvious the change
>>> is correct.
>> I hope Erik's reply to that was satisfactory.
>>>
>>> ---
>>>
>>> jdk/make/lib/LibCommon.gmk
>>>
>>> + # Disable it here for the jdk binaries until we decide to enable them.
>>>
>>> s/binaries/libraries/ ?
>> Sure, I'll fix.
>>
>>> Actually both this fragment and the one in
>>> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the
>>> relation with hotspot here, and the role of SetupNativeCompilation?
>> I hope Erik's reply to that is acceptable as well. As for the other
>> changes in the jdk repo, most of them is to either standardize on -Wl,
>> or to fix some places were we didn't do a proper $$ (instead of $) in
>> an macro that was supposed to be eval'd. (This was incorrect before as
>> well, but it broke the build when the LDFLAGS started having commas in
>> them.)
>>
>> /Magnus
>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> /Magnus
>>
>


From magnus.ihse.bursie at oracle.com  Mon Dec 14 08:30:30 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 14 Dec 2015 09:30:30 +0100
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <566E79FA.4010600@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
	<566B436B.90506@oracle.com> <566B4D09.5050601@oracle.com>
	<566E79FA.4010600@oracle.com>
Message-ID: <566E7E26.70408@oracle.com>

On 2015-12-14 09:12, David Holmes wrote:
> Hi Magnus,
>
> On 12/12/2015 8:24 AM, Magnus Ihse Bursie wrote:
>> On 2015-12-11 22:43, Magnus Ihse Bursie wrote:
>>> Hi David,
>>>
>>> Resurrecting the second part of the build-infra integrations. :)
>>> Fortunately, no major code changes in the meantime has affected this
>>> patch. (I did need to update the new
>>> hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)
>>
>> It seems I forgot to include the link to the new webrev:
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05 
>>
>
> hotspot.m4:
>
>  54 #    server: normal interpreter and a tiered C1/C2 compiler
>   55 #    client: normal interpreter and C1 (no C2 compiler) (only 
> 32-bit platforms)
>
> Neither of these statements are necessarily 100% true - not all 
> platforms have tiered enable; some 64-bit platforms do (or will) 
> support client.

This code was directly moved from jdk-options.m4. But I can update the 
text to better fit reality. I suggest updating the comment about server to:
# server: normal interpreter, and a C2 or tiered C1/C2 compiler 
depending on platform
Ok?

However, a few lines below we explicitely block enabling of client on 
64-bit platforms, so I believe this statement is correct, at least for 
the code as it looks now. It might be the case that the configure check 
is too strict, and if so we should modify it, but as long as the check 
remains I believe the comment should remain. Ok?

> Otherwise I didn't see anything else that I obviously needed to 
> comment on. The proof of this is in the building. So as long as this 
> gets through JPRT with -testset hotspot we should be okay. :)
Great. Thanks for the review!

/Magnus
>
> Thanks,
> David
>
>>
>> /Magnus
>>
>>>
>>>
>>> On 2015-11-16 05:33, David Holmes wrote:
>>>> Hi Magnus,
>>>>
>>>> I had a flick through most of the files. Overall seems okay but I
>>>> have a few queries below.
>>>
>>> Replies inline.
>>>
>>>>
>>>> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>>>>> The build-infra project has collected a number of minor fixes and
>>>>> changes during the new hotspot build development. It&#39;s a mix of
>>>>> code
>>>>> cleanup and new capabilities.
>>>>>
>>>>> Not all of these new features are immediately beneficial to the JDK,
>>>>> but
>>>>> they will be needed for the upcoming new Hotspot build, and it 
>>>>> will not
>>>>> hurt to have them in mainline. (In fact, it will tremendously help
>>>>> merging between mainline and build-infra.)
>>>>>
>>>>> The fix addresses these issues:
>>>>>
>>>>> In general:
>>>>> * Break out hotspot configuration into hotspot.m4
>>>>> * Long link lines uses @-files
>>>>> * Consistently use -Wl instead of -Xlinker
>>>>> * Improve clang on linux compilation
>>>>> * Set shared library name explicitely on solaris
>>>>> * Set correct shared library flag on Windows (-dll)
>>>>> * Consistency fixes for build toolchain
>>>>> * Bring compare script up to date
>>>>> * General code/whitespace cleanup
>>>>> * Additional functionality in MakeBase
>>>>>
>>>>> In NativeCompilation.gmk:
>>>>> * More efficient vardeps for per-file CFLAGS
>>>>> * Fewer shell executions (means better performance on Windows)
>>>>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>>>>> * Debug symbols on macosx (disabled for existing code to keep current
>>>>> behavior)
>>>>>
>>>>> Enabling debug info on macosx on existing jdk should be treated in a
>>>>> follow-up bug.
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>>>>> WebRev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> (It turned out that WebRev could not at the same time include files
>>>>> from
>>>>> multiple repos and track the history of a "hg cp":ied file. So I
>>>>> created
>>>>> an alternative revision here:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/ 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It does not include the jdk files, but hotspot.m4 might be easier to
>>>>> understand)
>>>>
>>>> flags.m4:
>>>>
>>>>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>>>>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>>>>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>>>>   63
>>>>   64   AC_SUBST(EXTRA_CFLAGS)
>>>>   65   AC_SUBST(EXTRA_CXXFLAGS)
>>>>   66   AC_SUBST(EXTRA_LDFLAGS)
>>>>
>>>> IIRC we added the legacy flags purely to pass the cross-compilation
>>>> args through to hotspot. Not sure why we need both legacy and
>>>> non-legancy variants now ??
>>>
>>> This is part of an ongoing effort to split CFLAGS_JDK into more
>>> reasonable parts. The current model is that we throw all possible
>>> flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et
>>> al). While it was questionable even before, it did work when we only
>>> built the JDK native libraries. Now that we need to build libjvm.so as
>>> well, which has (for historical reason) a set of flags that are both
>>> partially the same and partially different, this is not so good.
>>>
>>> We would like to see a change to a situation where the different
>>> "parts" that we build CFLAGS_JDK from would be handled separately, and
>>> then combined as needed for JDK libraries, and for Hotspot. So,
>>> currently we use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and then
>>> drop them. In the new Hotspot build, we use the EXTRA_CFLAGS to add
>>> them to the Hotspot flags. Of course, we could have used
>>> LEGACY_EXTRA_CFLAGS, but we'd like to avoid using "LEGACY" for new 
>>> stuff.
>>>
>>> With that being said, I now realize that maybe this change will not be
>>> needed anyway, at least not right now. Since doing a proper flag
>>> cleanup is a major task, we decided to copy the CFLAGS_JDK behavior
>>> for Hotspot flags as well in the current implementation of the new
>>> hotspot build, and saving the cleanup for another day (so it will not
>>> block the new build system). So I'll revert this part of the change
>>> for now.
>>>
>>>> On Windows -LD is a superset of -dll, so it isn't obvious the change
>>>> is correct.
>>> I hope Erik's reply to that was satisfactory.
>>>>
>>>> ---
>>>>
>>>> jdk/make/lib/LibCommon.gmk
>>>>
>>>> + # Disable it here for the jdk binaries until we decide to enable 
>>>> them.
>>>>
>>>> s/binaries/libraries/ ?
>>> Sure, I'll fix.
>>>
>>>> Actually both this fragment and the one in
>>>> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the
>>>> relation with hotspot here, and the role of SetupNativeCompilation?
>>> I hope Erik's reply to that is acceptable as well. As for the other
>>> changes in the jdk repo, most of them is to either standardize on -Wl,
>>> or to fix some places were we didn't do a proper $$ (instead of $) in
>>> an macro that was supposed to be eval'd. (This was incorrect before as
>>> well, but it broke the build when the LDFLAGS started having commas in
>>> them.)
>>>
>>> /Magnus
>>>
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>>> /Magnus
>>>
>>



From erik.joelsson at oracle.com  Mon Dec 14 08:32:31 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 14 Dec 2015 09:32:31 +0100
Subject: RFR (S): JDK-8142909 Integration of minor fixes from the
	build-infra project
In-Reply-To: <566B2FFF.3090109@oracle.com>
References: <56454C21.4010005@oracle.com> <56459BA1.1060604@oracle.com>
	<5645CA9E.4060205@oracle.com> <56493B10.6040207@oracle.com>
	<5649923E.8010707@oracle.com> <5649B9DB.2030507@oracle.com>
	<5649C8B8.2000707@oracle.com> <564A897D.7010707@oracle.com>
	<566B2FFF.3090109@oracle.com>
Message-ID: <566E7E9F.8090904@oracle.com>

Looks good to me.

/Erik

On 2015-12-11 21:20, Magnus Ihse Bursie wrote:
> I'm trying to resurrect this review.
>
> Here is a new version:
> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.03 
>
>
> I have dropped all the changes related to -g and OPT_CFLAGS. I'm not 
> interested in that kind of large scale operations on the old build 
> system, I just wanted to transfer the small patches we have in the 
> build-infra forest to mainline to facilitate comparison between old 
> and new build. If that was too problematic, let's skip it.
>
> Remaining changes are:
>  * Making adlc more quiet
>  * Sorting the windows build
>
> Also, in the meantime, a new difference has surfaced. In the first 
> push of the new hotspot build system, the rewrite of SA, the file 
> make/bsd/makefiles/saproc.make unfortunately was not deleted in 
> mainline. I added the deletion of this file.
>
> I intend to push this through hs-rt. David and Erik, please confirm 
> that these changes are OK for you.
>
> /Magnus
>
>
> On 2015-11-17 02:57, David Holmes wrote:
>> On 16/11/2015 10:14 PM, Erik Joelsson wrote:
>>> On 2015-11-16 12:11, David Holmes wrote:
>>>> On 16/11/2015 6:22 PM, Erik Joelsson wrote:
>>>>> On 2015-11-16 03:10, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> On 13/11/2015 9:33 PM, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-11-13 09:13, Erik Joelsson wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> make/bsd/makefiles/amd64.make:
>>>>>>>> make/bsd/makefiles/gcc.make:
>>>>>>>> Perhaps the order of "$(OPT_CFLAGS/NOOPT) 
>>>>>>>> $(OPT_CFLAGS/$(BUILDARCH))"
>>>>>>>> should be reversed to guarantee that NOOPT is the one used in case
>>>>>>>> BUILDARCH contains something that conflicts? The solaris file 
>>>>>>>> does it
>>>>>>>> this way.
>>>>>>> You know you wrote that code originally? ;-)
>>>>>>>
>>>>>>> Yeah, I agree, it's more reasonable. Updated webrev:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.02 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I don't like this particular change as it is too generic. It 
>>>>>> gives the
>>>>>> appearance of being apply to apply whatever the BUILDARCH specific
>>>>>> optflags are, which makes no sense if the whole point here is to not
>>>>>> optimize these files. If all this is intended to do is include -g 
>>>>>> then
>>>>>> I think that should be done explicitly.
>>>>>>
>>>>> The -g flag is added to OPT_CFLAGS/$(BUILDARCH) and I can only assume
>>>>> the intention was to have it added to all compilation command lines.
>>>>> However, the OPT_CFLAGS/<filename> variable overrides
>>>>> CFLAGS/$(BUILDARCH), effectively removing the -g flag from the files
>>>>> where we explicitly change the optimization level. The patch 
>>>>> intends to
>>>>> make sure -g is used on those files too.
>>>>
>>>> I understand that, but it is far from obvious that OPT_FLAGS/BUILDARCH
>>>> means -g (why???), or that putting other things in that variable might
>>>> break files that should not be optimized.
>>>>
>>>>> A cleaner solution would be to not have -g be part of the OPT 
>>>>> flags at
>>>>> all but its own set of DEBUG_CFLAGS.
>>>>
>>>> I thought -g was in the DEBUG_CFLAGS ?? Or maybe it used to be. Anyway
>>>> if all we are interested in is adding -g then I agree it should have
>>>> its own variable.
>>>>
>>> I looked some more at this. There is a DEBUG_CFLAGS, FASTDEBUG_CFLAGS
>>> and OPT_CFLAGS. These get picked depending on the debug level of the
>>> build. For example in product.make, $(OPT_CFLAGS/BYFILE) gets added to
>>> CFLAGS.
>>>
>>> I can't really see a better way of making sure the -g does not fall off
>>> for some files than what is proposed here. At least not without
>>> completely reworking the flags handling in the current hotspot
>>> makefiles, something I'm very uninterested in doing.
>>
>> In the -g case what we are handling is the addition of -g to product 
>> builds (it is already on fastdebug, debug) when 
>> ENABLE_FULL_DEBUG_SYMBOLS is selected, on a subset of architectures. 
>> As a convenience we define it thus (BSD version):
>>
>> OPT_CFLAGS/ia64 = -g
>> OPT_CFLAGS/amd64 = -g
>> OPT_CFLAGS/arm = -g
>> OPT_CFLAGS/ppc = -g
>> OPT_CFLAGS += $(OPT_CFLAGS/$(BUILDARCH))
>>
>> so $(OPT_CFLAGS/$(BUILDARCH)) happens to contain -g. I would be happy 
>> if the above were changed to:
>>
>> FDS_CFLAGS/ia64 = -g
>> FDS_CFLAGS/amd64 = -g
>> FDS_CFLAGS/arm = -g
>> FDS_CFLAGS/ppc = -g
>> OPT_CFLAGS += $(FDS_CFLAGS/$(BUILDARCH))
>>
>> and then you could use $(FDS_CFLAGS/$(BUILDARCH) on the "by-file" 
>> definitions, where it would be much clearer what kind of flag is 
>> actually being applied. However this needs to be done everywhere, and 
>> I don't see this fix attempting to do that. We set 
>> OPT_CFLAGS/<filename> in numerous places (open and closed) to regain 
>> control over the "opt" flags applied to that file. Sometimes we use 
>> predefined opt flags, like NOOPT or SPEED, and sometimes we don't eg:
>>
>> linux/makefiles/amd64.make
>>
>> OPT_CFLAGS/compactingPermGenGen.o = -O1
>>
>> This would need to be applied to every occurrence of the "byfile" 
>> definitions in all the makefiles. Or else ascertained on a 
>> case-by-case basis that we don't want -g for a specific file.
>>
>> Further, on architectures where $(FDS_CFLAGS/$(BUILDARCH) is not set 
>> you still have to somehow handle the rest of the above logic:
>>
>>  507     ifeq ($(OPT_CFLAGS/$(BUILDARCH)),)
>>  508       ifeq ($(USE_CLANG), true)
>>  509         # Clang doesn't understand -gstabs
>>  510         OPT_CFLAGS += -g
>>  511       else
>>  512         OPT_CFLAGS += -gstabs
>>  513       endif
>>  514     endif
>>
>> else you again fail to set -g or -gstabs on the "by-file" definitions.
>>
>> Also looking at the change in make/solaris/makefiles/amd64.make you 
>> have taken the file specific flags:
>>
>>  OPT_CFLAGS/generateOptoStub.o = -xO2
>>
>> and added the generic OPT_CFLAGS value:
>>
>> OPT_CFLAGS/generateOptoStub.o = $(OPT_CFLAGS) -xO2
>>
>> which seems extremely dubious from a correctness perspective.
>>
>> Thanks,
>> David
>> -----
>>
>>>>>> ---
>>>>>>
>>>>>> make/bsd/makefiles/saproc.make
>>>>>>
>>>>>> ! # Order src files alfabetically
>>>>>>
>>>>>> That would be "alphabetically". But that list doesn't seem 
>>>>>> alphabetic
>>>>>> anyway: MacosxDebuggerLocal.m would come after libproc_impl.c; and
>>>>>> $(AGENTDIR) should come first. I really see no point in forcing such
>>>>>> lists to be in alphabetic order.
>>>>>>
>>>>> This is to make comparison of binaries between the old hotspot 
>>>>> build and
>>>>> the new hotspot build easier. In build-infra, we $(sort ) the object
>>>>> files before linking to get a reproducible order. The linker 
>>>>> output is
>>>>> affected by the order of the object files. By making sure the old and
>>>>> the new build sorts them the same way, we get cleaner comparisons and
>>>>> can more easily detect other types of differences through those
>>>>> comparisons. The sort order isn't strictly alphabetical, it's on byte
>>>>> order so upper case goes before lower case.
>>>>
>>>> I saw the change for the ordered object files on Windows, but this
>>>> simply orders source files in a list. Not sure how that has any affect
>>>> on the linking ??
>>>>
>>> It has an effect on the linking because that list is used verbatim on
>>> the combined compile/link command line.
>>>
>>> /Erik
>>>> Cheers,
>>>> David
>>>>
>>>>> /Erik
>>>>>> make/linux/makefiles/saproc.make doesn't have the comment that was
>>>>>> added for bsd.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> make/solaris/makefiles/amd64.make
>>>>>>
>>>>>> Similar issue with bsd amd64.make. Not sure what you are trying to
>>>>>> achieve here - is it some kind of last option wins situation ?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> make/windows/create_obj_files.sh
>>>>>>
>>>>>> Harmless I guess but not sure about relevance of sort order here.
>>>>>>
>>>>>> ----
>>>>>>
>>>>>>  src/share/vm/adlc/adlparse.cpp
>>>>>>
>>>>>> So that's where that comes from! :)
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> src/share/vm/gc/g1/g1EvacStats.cpp
>>>>>>
>>>>>> I don't see anything in the cpp files that uses anything from the
>>>>>> atomic class ???
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /Magnus
>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise looks good.
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>>>>>>>> On 2015-11-13 03:34, Magnus Ihse Bursie wrote:
>>>>>>>>> In the new hotspot build project, we have made a few changes 
>>>>>>>>> to the
>>>>>>>>> existing build. In preparation for the new build, I'd like to
>>>>>>>>> integrate these into mainline.
>>>>>>>>>
>>>>>>>>> These changes are:
>>>>>>>>> * When overriding optimization, do not lose current debug (-g)
>>>>>>>>> setting (!)
>>>>>>>>> * Make adlc actually quiet in quiet mode
>>>>>>>>> * Make g1EvacStats.cpp compile in all cases without precompiled
>>>>>>>>> headers
>>>>>>>>> * Sort saproc object files when linking (facilitates 
>>>>>>>>> comparison to
>>>>>>>>> new build)
>>>>>>>>>
>>>>>>>>> Unless someone suggests otherwise, I intend to push this (using
>>>>>>>>> JPRT)
>>>>>>>>> to hs-rt.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142909
>>>>>>>>> WebRev:
>>>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142909-hotspot-build-infra-integration/webrev.01 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>
>>>>>
>>>
>



From erik.joelsson at oracle.com  Mon Dec 14 08:40:47 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 14 Dec 2015 09:40:47 +0100
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <566B4D09.5050601@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
	<566B436B.90506@oracle.com> <566B4D09.5050601@oracle.com>
Message-ID: <566E808F.5000401@oracle.com>

Looks good to me.

/Erik

On 2015-12-11 23:24, Magnus Ihse Bursie wrote:
> On 2015-12-11 22:43, Magnus Ihse Bursie wrote:
>> Hi David,
>>
>> Resurrecting the second part of the build-infra integrations. :) 
>> Fortunately, no major code changes in the meantime has affected this 
>> patch. (I did need to update the new 
>> hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)
>
> It seems I forgot to include the link to the new webrev:
>
> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05 
>
>
> /Magnus
>
>>
>>
>> On 2015-11-16 05:33, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> I had a flick through most of the files. Overall seems okay but I 
>>> have a few queries below.
>>
>> Replies inline.
>>
>>>
>>> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>>>> The build-infra project has collected a number of minor fixes and
>>>> changes during the new hotspot build development. It&#39;s a mix of 
>>>> code
>>>> cleanup and new capabilities.
>>>>
>>>> Not all of these new features are immediately beneficial to the 
>>>> JDK, but
>>>> they will be needed for the upcoming new Hotspot build, and it will 
>>>> not
>>>> hurt to have them in mainline. (In fact, it will tremendously help
>>>> merging between mainline and build-infra.)
>>>>
>>>> The fix addresses these issues:
>>>>
>>>> In general:
>>>> * Break out hotspot configuration into hotspot.m4
>>>> * Long link lines uses @-files
>>>> * Consistently use -Wl instead of -Xlinker
>>>> * Improve clang on linux compilation
>>>> * Set shared library name explicitely on solaris
>>>> * Set correct shared library flag on Windows (-dll)
>>>> * Consistency fixes for build toolchain
>>>> * Bring compare script up to date
>>>> * General code/whitespace cleanup
>>>> * Additional functionality in MakeBase
>>>>
>>>> In NativeCompilation.gmk:
>>>> * More efficient vardeps for per-file CFLAGS
>>>> * Fewer shell executions (means better performance on Windows)
>>>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>>>> * Debug symbols on macosx (disabled for existing code to keep current
>>>> behavior)
>>>>
>>>> Enabling debug info on macosx on existing jdk should be treated in a
>>>> follow-up bug.
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01 
>>>>
>>>>
>>>>
>>>> (It turned out that WebRev could not at the same time include files 
>>>> from
>>>> multiple repos and track the history of a "hg cp":ied file. So I 
>>>> created
>>>> an alternative revision here:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/ 
>>>>
>>>>
>>>>
>>>> It does not include the jdk files, but hotspot.m4 might be easier to
>>>> understand)
>>>
>>> flags.m4:
>>>
>>>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>>>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>>>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>>>   63
>>>   64   AC_SUBST(EXTRA_CFLAGS)
>>>   65   AC_SUBST(EXTRA_CXXFLAGS)
>>>   66   AC_SUBST(EXTRA_LDFLAGS)
>>>
>>> IIRC we added the legacy flags purely to pass the cross-compilation 
>>> args through to hotspot. Not sure why we need both legacy and 
>>> non-legancy variants now ??
>>
>> This is part of an ongoing effort to split CFLAGS_JDK into more 
>> reasonable parts. The current model is that we throw all possible 
>> flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et 
>> al). While it was questionable even before, it did work when we only 
>> built the JDK native libraries. Now that we need to build libjvm.so 
>> as well, which has (for historical reason) a set of flags that are 
>> both partially the same and partially different, this is not so good.
>>
>> We would like to see a change to a situation where the different 
>> "parts" that we build CFLAGS_JDK from would be handled separately, 
>> and then combined as needed for JDK libraries, and for Hotspot. So, 
>> currently we use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and 
>> then drop them. In the new Hotspot build, we use the EXTRA_CFLAGS to 
>> add them to the Hotspot flags. Of course, we could have used 
>> LEGACY_EXTRA_CFLAGS, but we'd like to avoid using "LEGACY" for new 
>> stuff.
>>
>> With that being said, I now realize that maybe this change will not 
>> be needed anyway, at least not right now. Since doing a proper flag 
>> cleanup is a major task, we decided to copy the CFLAGS_JDK behavior 
>> for Hotspot flags as well in the current implementation of the new 
>> hotspot build, and saving the cleanup for another day (so it will not 
>> block the new build system). So I'll revert this part of the change 
>> for now.
>>
>>> On Windows -LD is a superset of -dll, so it isn't obvious the change 
>>> is correct.
>> I hope Erik's reply to that was satisfactory.
>>>
>>> ---
>>>
>>> jdk/make/lib/LibCommon.gmk
>>>
>>> + # Disable it here for the jdk binaries until we decide to enable 
>>> them.
>>>
>>> s/binaries/libraries/ ?
>> Sure, I'll fix.
>>
>>> Actually both this fragment and the one in 
>>> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the 
>>> relation with hotspot here, and the role of SetupNativeCompilation?
>> I hope Erik's reply to that is acceptable as well. As for the other 
>> changes in the jdk repo, most of them is to either standardize on 
>> -Wl, or to fix some places were we didn't do a proper $$ (instead of 
>> $) in an macro that was supposed to be eval'd. (This was incorrect 
>> before as well, but it broke the build when the LDFLAGS started 
>> having commas in them.)
>>
>> /Magnus
>>
>>>
>>> Thanks,
>>> David
>>>
>>>
>>>> /Magnus
>>
>



From david.holmes at oracle.com  Mon Dec 14 12:34:51 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Dec 2015 22:34:51 +1000
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <566E7E26.70408@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
	<566B436B.90506@oracle.com> <566B4D09.5050601@oracle.com>
	<566E79FA.4010600@oracle.com> <566E7E26.70408@oracle.com>
Message-ID: <566EB76B.10403@oracle.com>

On 14/12/2015 6:30 PM, Magnus Ihse Bursie wrote:
> On 2015-12-14 09:12, David Holmes wrote:
>> Hi Magnus,
>>
>> On 12/12/2015 8:24 AM, Magnus Ihse Bursie wrote:
>>> On 2015-12-11 22:43, Magnus Ihse Bursie wrote:
>>>> Hi David,
>>>>
>>>> Resurrecting the second part of the build-infra integrations. :)
>>>> Fortunately, no major code changes in the meantime has affected this
>>>> patch. (I did need to update the new
>>>> hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)
>>>
>>> It seems I forgot to include the link to the new webrev:
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05
>>>
>>
>> hotspot.m4:
>>
>>  54 #    server: normal interpreter and a tiered C1/C2 compiler
>>   55 #    client: normal interpreter and C1 (no C2 compiler) (only
>> 32-bit platforms)
>>
>> Neither of these statements are necessarily 100% true - not all
>> platforms have tiered enable; some 64-bit platforms do (or will)
>> support client.
>
> This code was directly moved from jdk-options.m4. But I can update the
> text to better fit reality. I suggest updating the comment about server to:
> # server: normal interpreter, and a C2 or tiered C1/C2 compiler
> depending on platform
> Ok?

Ok.

> However, a few lines below we explicitely block enabling of client on
> 64-bit platforms, so I believe this statement is correct, at least for
> the code as it looks now. It might be the case that the configure check
> is too strict, and if so we should modify it, but as long as the check
> remains I believe the comment should remain. Ok?

OK. As long as whomever removes the check knows to remove the comment. 
Both the arm32 port and the mobile project will be relaxing this afaik.

Thanks,
David

>> Otherwise I didn't see anything else that I obviously needed to
>> comment on. The proof of this is in the building. So as long as this
>> gets through JPRT with -testset hotspot we should be okay. :)
> Great. Thanks for the review!
>
> /Magnus
>>
>> Thanks,
>> David
>>
>>>
>>> /Magnus
>>>
>>>>
>>>>
>>>> On 2015-11-16 05:33, David Holmes wrote:
>>>>> Hi Magnus,
>>>>>
>>>>> I had a flick through most of the files. Overall seems okay but I
>>>>> have a few queries below.
>>>>
>>>> Replies inline.
>>>>
>>>>>
>>>>> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>>>>>> The build-infra project has collected a number of minor fixes and
>>>>>> changes during the new hotspot build development. It&#39;s a mix of
>>>>>> code
>>>>>> cleanup and new capabilities.
>>>>>>
>>>>>> Not all of these new features are immediately beneficial to the JDK,
>>>>>> but
>>>>>> they will be needed for the upcoming new Hotspot build, and it
>>>>>> will not
>>>>>> hurt to have them in mainline. (In fact, it will tremendously help
>>>>>> merging between mainline and build-infra.)
>>>>>>
>>>>>> The fix addresses these issues:
>>>>>>
>>>>>> In general:
>>>>>> * Break out hotspot configuration into hotspot.m4
>>>>>> * Long link lines uses @-files
>>>>>> * Consistently use -Wl instead of -Xlinker
>>>>>> * Improve clang on linux compilation
>>>>>> * Set shared library name explicitely on solaris
>>>>>> * Set correct shared library flag on Windows (-dll)
>>>>>> * Consistency fixes for build toolchain
>>>>>> * Bring compare script up to date
>>>>>> * General code/whitespace cleanup
>>>>>> * Additional functionality in MakeBase
>>>>>>
>>>>>> In NativeCompilation.gmk:
>>>>>> * More efficient vardeps for per-file CFLAGS
>>>>>> * Fewer shell executions (means better performance on Windows)
>>>>>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>>>>>> * Debug symbols on macosx (disabled for existing code to keep current
>>>>>> behavior)
>>>>>>
>>>>>> Enabling debug info on macosx on existing jdk should be treated in a
>>>>>> follow-up bug.
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>>>>>> WebRev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> (It turned out that WebRev could not at the same time include files
>>>>>> from
>>>>>> multiple repos and track the history of a "hg cp":ied file. So I
>>>>>> created
>>>>>> an alternative revision here:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It does not include the jdk files, but hotspot.m4 might be easier to
>>>>>> understand)
>>>>>
>>>>> flags.m4:
>>>>>
>>>>>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>>>>>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>>>>>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>>>>>   63
>>>>>   64   AC_SUBST(EXTRA_CFLAGS)
>>>>>   65   AC_SUBST(EXTRA_CXXFLAGS)
>>>>>   66   AC_SUBST(EXTRA_LDFLAGS)
>>>>>
>>>>> IIRC we added the legacy flags purely to pass the cross-compilation
>>>>> args through to hotspot. Not sure why we need both legacy and
>>>>> non-legancy variants now ??
>>>>
>>>> This is part of an ongoing effort to split CFLAGS_JDK into more
>>>> reasonable parts. The current model is that we throw all possible
>>>> flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et
>>>> al). While it was questionable even before, it did work when we only
>>>> built the JDK native libraries. Now that we need to build libjvm.so as
>>>> well, which has (for historical reason) a set of flags that are both
>>>> partially the same and partially different, this is not so good.
>>>>
>>>> We would like to see a change to a situation where the different
>>>> "parts" that we build CFLAGS_JDK from would be handled separately, and
>>>> then combined as needed for JDK libraries, and for Hotspot. So,
>>>> currently we use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and then
>>>> drop them. In the new Hotspot build, we use the EXTRA_CFLAGS to add
>>>> them to the Hotspot flags. Of course, we could have used
>>>> LEGACY_EXTRA_CFLAGS, but we'd like to avoid using "LEGACY" for new
>>>> stuff.
>>>>
>>>> With that being said, I now realize that maybe this change will not be
>>>> needed anyway, at least not right now. Since doing a proper flag
>>>> cleanup is a major task, we decided to copy the CFLAGS_JDK behavior
>>>> for Hotspot flags as well in the current implementation of the new
>>>> hotspot build, and saving the cleanup for another day (so it will not
>>>> block the new build system). So I'll revert this part of the change
>>>> for now.
>>>>
>>>>> On Windows -LD is a superset of -dll, so it isn't obvious the change
>>>>> is correct.
>>>> I hope Erik's reply to that was satisfactory.
>>>>>
>>>>> ---
>>>>>
>>>>> jdk/make/lib/LibCommon.gmk
>>>>>
>>>>> + # Disable it here for the jdk binaries until we decide to enable
>>>>> them.
>>>>>
>>>>> s/binaries/libraries/ ?
>>>> Sure, I'll fix.
>>>>
>>>>> Actually both this fragment and the one in
>>>>> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the
>>>>> relation with hotspot here, and the role of SetupNativeCompilation?
>>>> I hope Erik's reply to that is acceptable as well. As for the other
>>>> changes in the jdk repo, most of them is to either standardize on -Wl,
>>>> or to fix some places were we didn't do a proper $$ (instead of $) in
>>>> an macro that was supposed to be eval'd. (This was incorrect before as
>>>> well, but it broke the build when the LDFLAGS started having commas in
>>>> them.)
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>>> /Magnus
>>>>
>>>
>


From gary.adams at oracle.com  Mon Dec 14 13:56:29 2015
From: gary.adams at oracle.com (Gary Adams)
Date: Mon, 14 Dec 2015 08:56:29 -0500
Subject: RFR: JDK-8142907 Integration of minor fixes from the build-infra
	project
In-Reply-To: <566EB76B.10403@oracle.com>
References: <56454E3E.8090703@oracle.com> <56495C9C.5070501@oracle.com>
	<566B436B.90506@oracle.com> <566B4D09.5050601@oracle.com>
	<566E79FA.4010600@oracle.com> <566E7E26.70408@oracle.com>
	<566EB76B.10403@oracle.com>
Message-ID: <566ECA8D.1080403@oracle.com>

On 12/14/15 07:34, David Holmes wrote:
> On 14/12/2015 6:30 PM, Magnus Ihse Bursie wrote:
>> On 2015-12-14 09:12, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> On 12/12/2015 8:24 AM, Magnus Ihse Bursie wrote:
>>>> On 2015-12-11 22:43, Magnus Ihse Bursie wrote:
>>>>> Hi David,
>>>>>
>>>>> Resurrecting the second part of the build-infra integrations. :)
>>>>> Fortunately, no major code changes in the meantime has affected this
>>>>> patch. (I did need to update the new
>>>>> hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)
>>>>
>>>> It seems I forgot to include the link to the new webrev:
>>>>
>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05 
>>>>
>>>>
>>>
>>> hotspot.m4:
>>>
>>>  54 #    server: normal interpreter and a tiered C1/C2 compiler
>>>   55 #    client: normal interpreter and C1 (no C2 compiler) (only
>>> 32-bit platforms)
>>>
>>> Neither of these statements are necessarily 100% true - not all
>>> platforms have tiered enable; some 64-bit platforms do (or will)
>>> support client.
>>
>> This code was directly moved from jdk-options.m4. But I can update the
>> text to better fit reality. I suggest updating the comment about 
>> server to:
>> # server: normal interpreter, and a C2 or tiered C1/C2 compiler
>> depending on platform
>> Ok?
>
> Ok.
>
>> However, a few lines below we explicitely block enabling of client on
>> 64-bit platforms, so I believe this statement is correct, at least for
>> the code as it looks now. It might be the case that the configure check
>> is too strict, and if so we should modify it, but as long as the check
>> remains I believe the comment should remain. Ok?
>
> OK. As long as whomever removes the check knows to remove the comment. 
> Both the arm32 port and the mobile project will be relaxing this afaik.
For the mobile port we have relaxed the constraint and allow a 64 bit 
client and
minimal vm to be built. I'll make sure the comment is updated in our repos.
I don't think there was a fundamental reason those variations were not 
support,
just a question of which platforms were being built and tested on a 
regular basis.

>
> Thanks,
> David
>
>>> Otherwise I didn't see anything else that I obviously needed to
>>> comment on. The proof of this is in the building. So as long as this
>>> gets through JPRT with -testset hotspot we should be okay. :)
>> Great. Thanks for the review!
>>
>> /Magnus
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>>
>>>>> On 2015-11-16 05:33, David Holmes wrote:
>>>>>> Hi Magnus,
>>>>>>
>>>>>> I had a flick through most of the files. Overall seems okay but I
>>>>>> have a few queries below.
>>>>>
>>>>> Replies inline.
>>>>>
>>>>>>
>>>>>> On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:
>>>>>>> The build-infra project has collected a number of minor fixes and
>>>>>>> changes during the new hotspot build development. It&#39;s a mix of
>>>>>>> code
>>>>>>> cleanup and new capabilities.
>>>>>>>
>>>>>>> Not all of these new features are immediately beneficial to the 
>>>>>>> JDK,
>>>>>>> but
>>>>>>> they will be needed for the upcoming new Hotspot build, and it
>>>>>>> will not
>>>>>>> hurt to have them in mainline. (In fact, it will tremendously help
>>>>>>> merging between mainline and build-infra.)
>>>>>>>
>>>>>>> The fix addresses these issues:
>>>>>>>
>>>>>>> In general:
>>>>>>> * Break out hotspot configuration into hotspot.m4
>>>>>>> * Long link lines uses @-files
>>>>>>> * Consistently use -Wl instead of -Xlinker
>>>>>>> * Improve clang on linux compilation
>>>>>>> * Set shared library name explicitely on solaris
>>>>>>> * Set correct shared library flag on Windows (-dll)
>>>>>>> * Consistency fixes for build toolchain
>>>>>>> * Bring compare script up to date
>>>>>>> * General code/whitespace cleanup
>>>>>>> * Additional functionality in MakeBase
>>>>>>>
>>>>>>> In NativeCompilation.gmk:
>>>>>>> * More efficient vardeps for per-file CFLAGS
>>>>>>> * Fewer shell executions (means better performance on Windows)
>>>>>>> * EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
>>>>>>> * Debug symbols on macosx (disabled for existing code to keep 
>>>>>>> current
>>>>>>> behavior)
>>>>>>>
>>>>>>> Enabling debug info on macosx on existing jdk should be treated 
>>>>>>> in a
>>>>>>> follow-up bug.
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
>>>>>>> WebRev:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> (It turned out that WebRev could not at the same time include files
>>>>>>> from
>>>>>>> multiple repos and track the history of a "hg cp":ied file. So I
>>>>>>> created
>>>>>>> an alternative revision here:
>>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/ 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It does not include the jdk files, but hotspot.m4 might be 
>>>>>>> easier to
>>>>>>> understand)
>>>>>>
>>>>>> flags.m4:
>>>>>>
>>>>>>   60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
>>>>>>   61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
>>>>>>   62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
>>>>>>   63
>>>>>>   64   AC_SUBST(EXTRA_CFLAGS)
>>>>>>   65   AC_SUBST(EXTRA_CXXFLAGS)
>>>>>>   66   AC_SUBST(EXTRA_LDFLAGS)
>>>>>>
>>>>>> IIRC we added the legacy flags purely to pass the cross-compilation
>>>>>> args through to hotspot. Not sure why we need both legacy and
>>>>>> non-legancy variants now ??
>>>>>
>>>>> This is part of an ongoing effort to split CFLAGS_JDK into more
>>>>> reasonable parts. The current model is that we throw all possible
>>>>> flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et
>>>>> al). While it was questionable even before, it did work when we only
>>>>> built the JDK native libraries. Now that we need to build 
>>>>> libjvm.so as
>>>>> well, which has (for historical reason) a set of flags that are both
>>>>> partially the same and partially different, this is not so good.
>>>>>
>>>>> We would like to see a change to a situation where the different
>>>>> "parts" that we build CFLAGS_JDK from would be handled separately, 
>>>>> and
>>>>> then combined as needed for JDK libraries, and for Hotspot. So,
>>>>> currently we use EXTRA_CFLAGS just to add them to CFLAGS_JDK, and 
>>>>> then
>>>>> drop them. In the new Hotspot build, we use the EXTRA_CFLAGS to add
>>>>> them to the Hotspot flags. Of course, we could have used
>>>>> LEGACY_EXTRA_CFLAGS, but we'd like to avoid using "LEGACY" for new
>>>>> stuff.
>>>>>
>>>>> With that being said, I now realize that maybe this change will 
>>>>> not be
>>>>> needed anyway, at least not right now. Since doing a proper flag
>>>>> cleanup is a major task, we decided to copy the CFLAGS_JDK behavior
>>>>> for Hotspot flags as well in the current implementation of the new
>>>>> hotspot build, and saving the cleanup for another day (so it will not
>>>>> block the new build system). So I'll revert this part of the change
>>>>> for now.
>>>>>
>>>>>> On Windows -LD is a superset of -dll, so it isn't obvious the change
>>>>>> is correct.
>>>>> I hope Erik's reply to that was satisfactory.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> jdk/make/lib/LibCommon.gmk
>>>>>>
>>>>>> + # Disable it here for the jdk binaries until we decide to enable
>>>>>> them.
>>>>>>
>>>>>> s/binaries/libraries/ ?
>>>>> Sure, I'll fix.
>>>>>
>>>>>> Actually both this fragment and the one in
>>>>>> jdk/make/launcher/LauncherCommon.gmk I find confusing - what is the
>>>>>> relation with hotspot here, and the role of SetupNativeCompilation?
>>>>> I hope Erik's reply to that is acceptable as well. As for the other
>>>>> changes in the jdk repo, most of them is to either standardize on 
>>>>> -Wl,
>>>>> or to fix some places were we didn't do a proper $$ (instead of $) in
>>>>> an macro that was supposed to be eval'd. (This was incorrect 
>>>>> before as
>>>>> well, but it broke the build when the LDFLAGS started having 
>>>>> commas in
>>>>> them.)
>>>>>
>>>>> /Magnus
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> /Magnus
>>>>>
>>>>
>>



From mikael.gerdin at oracle.com  Mon Dec 14 14:58:37 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 14 Dec 2015 15:58:37 +0100
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <566ACDE9.20901@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com>
Message-ID: <566ED91D.1030701@oracle.com>

Hi David,

On 2015-12-11 14:21, David Holmes wrote:
> On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
>> On 2015-12-03 03:11, Roger Riggs wrote:
>>> Hi,
>>>
>>> It would be useful to figure out the number of cpus available when in
>>> a container.
>>> Some comments have added to:
>>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>>> getAvailableProcessors may incorrectly report the number of cpus in
>>> Docker container
>>>
>>> But so far we haven't dug deep enough.   Suggestions are welcome?
>> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
>>
>> suggests running nproc. I'm not sure if that can be counted on to be
>> present, but we could certainly check for it.
>
> I'd like to know how nproc does it so we can try to apply the same logic
> in the VM for Runtime.availableProcessors. Can someone actually confirm
> that it returns the number of processors available to the container?

I don't have a container at hand but running nproc under strace suggests 
that it calls sched_getaffinity and counts the number of set bits in the 
cpu affinity mask:

$ strace -e trace=sched_getaffinity nproc
sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
4
+++ exited with 0 +++

It would be nice if anyone with access to a system where the number of 
cpus is limited in a similar manner to a docker container could run the 
above command and see if it
1) returns the correct number of cpus
2) works as I think, that is, it counts the number of set bits in the 
array which is the third syscall argument.


/Mikael


>
> David
>
>> /Magnus
>>
>>>
>>> Roger
>>>
>>>
>>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>>> Not to say you shouldn't do this, but I worry that increasingly
>>>> computing
>>>> is being done in "containers" where e.g. the number of cpus is doubling
>>>> every year but only a small number are available to actually be used
>>>> by a
>>>> given process.  if availableProcessors reports 1 million, what
>>>> should we
>>>> do?  (no need to answer...)
>>>>
>>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson
>>>> <erik.joelsson at oracle.com>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> The current heuristic for figuring out what to default set the -j
>>>>> flag to
>>>>> make needs some tweaking.
>>>>>
>>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>>> the
>>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>>> will
>>>>> fit into memory. The lower of that number and the number of cpus is
>>>>> then
>>>>> picked. The number is then scaled down to about 90% of the number of
>>>>> cpus
>>>>> to leave some resources for other activities. It is also capped at 16.
>>>>>
>>>>> Since we now have the build using "nice" to make sure the build isn't
>>>>> bogging down the system, I see no reason to do the 90% scaling
>>>>> anymore.
>>>>> Also, the performance issues that forced us to cap at 16 have long
>>>>> been
>>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>>> So I
>>>>> propose we remove that arbitrary limitation too.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>>
>>>>> /Erik
>>>>>
>>>
>>
>


From jaroslav.bachorik at oracle.com  Mon Dec 14 16:55:42 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Mon, 14 Dec 2015 17:55:42 +0100
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access
	a member of class java.lang.management.ManagementFactory (module
	java.management)
Message-ID: <566EF48E.3050300@oracle.com>

Please, review the following change

Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00

The problem is that the class UsageTrackerClient is accessing 
RuntimeMXBean.getInputArguments() method via reflection to avoid static 
dependency. However, with functional module boundaries this fails.

Since the functionality provided by RuntimeMXBean.getInputArguments() is 
not, in fact, specific to the management subsystem, it makes sense to 
move it out of jmm.h to jvm.h

Full suite of SVC tests was run against this change successfully on all 
platforms.


Thanks,

-JB-


From asmundak at google.com  Mon Dec 14 18:04:43 2015
From: asmundak at google.com (Alexander Smundak)
Date: Mon, 14 Dec 2015 18:04:43 +0000
Subject: RFR: 8073139 PPC64: User-visible arch directory and os.arch value
	on ppc64le cause issues with Java tooling
In-Reply-To: <566E3C64.2030506@oracle.com>
References: <CAHQ51u5HVr2PpJOXMb5kDnUkrDGYtUUEKo1jyZzH06uVPTYPFg@mail.gmail.com>
	<565BCF58.90405@oracle.com> <565C4477.4090708@oracle.com>
	<CAHQ51u6gWmeKCO=355-2GhZgaQ_dKw6RX5BJjr4yyaXXv_VBRw@mail.gmail.com>
	<565FE186.7090508@oracle.com>
	<CAHQ51u6qn81VHTvrxwfc+2swTF6=o2_AadSrB3hpAg-QtdzQSQ@mail.gmail.com>
	<566147EF.4000109@oracle.com>
	<CAHQ51u6T=E+wPYjAp2sTWnVJFeNBB61juPtQ+EVO_wkxhcgtEQ@mail.gmail.com>
	<5664DBF9.7010708@oracle.com>
	<CAHQ51u6dpiuEGzwFfXsb1hw3R6=o=YxynoYwG_BrXiw8ym1CeA@mail.gmail.com>
	<566660B2.4030100@oracle.com>
	<CAHQ51u5sGZdYFksA4xpRnm4cy_TSk2mz6G-a45qGaVBY++C5vg@mail.gmail.com>
	<56679B9F.8030105@oracle.com>
	<CAHQ51u42tPYXy0T1+-ZYDQWA7DZW5w2Tee=6c5U7+J05P-nfbw@mail.gmail.com>
	<566906CE.2050101@oracle.com>
	<CAHQ51u6Td=xrEVkwKtW2DVOqH2e1x7MhmzMGk6HkMvisYLiYOg@mail.gmail.com>
	<566A5575.3020908@oracle.com>
	<CA+3eh11ONGe4ix3Y1JMPmpXcAenkyUjWVy=S8UCjU0D=OS6FRw@mail.gmail.com>
	<CAHQ51u6DCTSudcboaY9FGLZRMYr-a+uEq2u9+Q77ikCYhD3LTA@mail.gmail.com>
	<566E3C64.2030506@oracle.com>
Message-ID: <CAHQ51u7tz2SS1ymWHgYpbKoJRCcpV8G2xormpfdYCLYFw1Sj9w@mail.gmail.com>

Thanks for your patience, too:-).
I saw that patch and verified it works for the PPC64LE, but it wasn't
committed yet.

Sasha

On Sun, Dec 13, 2015 at 7:50 PM David Holmes <david.holmes at oracle.com>
wrote:

> On 12/12/2015 5:05 AM, Alexander Smundak wrote:
> > On Fri, Dec 11, 2015 at 5:57 AM, Volker Simonis
> > <volker.simonis at gmail.com> wrote:
> >> I've just verified that your patch still works for linux/ppc64. I've
> >> built and smoke-tested both linux/ppc64 and ppc64le and everything
> >> looks good. So from my side this is ready to push.
> > Thanks.
> >
> > Here's the new revision, with headers verified by jcheck:
> >
> > http://cr.openjdk.java.net/~asmundak/8073139/hotspot/webrev.05
> > http://cr.openjdk.java.net/~asmundak/8073139/jdk/webrev.05
> > http://cr.openjdk.java.net/~asmundak/8073139/root/webrev.05
>
> Thanks for your patience Sasha! Hopefully this will all be trivial next
> time round. I had to rebase the changeset to accommodate the change from:
>
>   8144885: agent/src/os/linux/libproc.h needs to support Linux/SPARC builds
>
> but otherwise all okay. (I didn't want to send it back to you again :) ).
>
> Cheers,
> David
>
> > Sasha
> >
>


From martinrb at google.com  Tue Dec 15 03:27:04 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 14 Dec 2015 19:27:04 -0800
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <566ED91D.1030701@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
Message-ID: <CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>

My current mental model is
configured cpus >= online cpus >= allowed cpus
In a traditional system they are all the same.

I experimented and saw that cpusets are indeed turned on in some
systems used for testing at Google.
I.e. allowed cpus is a strict subset of online cpus.

It seems likely that the following would be a better implementation of
availableProcessors on Linux:

  cpu_set_t s;
  return (sched_getaffinity(0, sizeof(s), &s) == 0) ? CPU_COUNT(&s) :
fallback_to_old_way();

with all the pain in configury.

On Mon, Dec 14, 2015 at 6:58 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
> Hi David,
>
> On 2015-12-11 14:21, David Holmes wrote:
>>
>> On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
>>>
>>> On 2015-12-03 03:11, Roger Riggs wrote:
>>>>
>>>> Hi,
>>>>
>>>> It would be useful to figure out the number of cpus available when in
>>>> a container.
>>>> Some comments have added to:
>>>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>>>> getAvailableProcessors may incorrectly report the number of cpus in
>>>> Docker container
>>>>
>>>> But so far we haven't dug deep enough.   Suggestions are welcome?
>>>
>>>
>>> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
>>>
>>> suggests running nproc. I'm not sure if that can be counted on to be
>>> present, but we could certainly check for it.
>>
>>
>> I'd like to know how nproc does it so we can try to apply the same logic
>> in the VM for Runtime.availableProcessors. Can someone actually confirm
>> that it returns the number of processors available to the container?
>
>
> I don't have a container at hand but running nproc under strace suggests
> that it calls sched_getaffinity and counts the number of set bits in the cpu
> affinity mask:
>
> $ strace -e trace=sched_getaffinity nproc
> sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
> 4
> +++ exited with 0 +++
>
> It would be nice if anyone with access to a system where the number of cpus
> is limited in a similar manner to a docker container could run the above
> command and see if it
> 1) returns the correct number of cpus
> 2) works as I think, that is, it counts the number of set bits in the array
> which is the third syscall argument.
>
>
> /Mikael
>
>
>
>>
>> David
>>
>>> /Magnus
>>>
>>>>
>>>> Roger
>>>>
>>>>
>>>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>>>>
>>>>> Not to say you shouldn't do this, but I worry that increasingly
>>>>> computing
>>>>> is being done in "containers" where e.g. the number of cpus is doubling
>>>>> every year but only a small number are available to actually be used
>>>>> by a
>>>>> given process.  if availableProcessors reports 1 million, what
>>>>> should we
>>>>> do?  (no need to answer...)
>>>>>
>>>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson
>>>>> <erik.joelsson at oracle.com>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> The current heuristic for figuring out what to default set the -j
>>>>>> flag to
>>>>>> make needs some tweaking.
>>>>>>
>>>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>>>> the
>>>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>>>> will
>>>>>> fit into memory. The lower of that number and the number of cpus is
>>>>>> then
>>>>>> picked. The number is then scaled down to about 90% of the number of
>>>>>> cpus
>>>>>> to leave some resources for other activities. It is also capped at 16.
>>>>>>
>>>>>> Since we now have the build using "nice" to make sure the build isn't
>>>>>> bogging down the system, I see no reason to do the 90% scaling
>>>>>> anymore.
>>>>>> Also, the performance issues that forced us to cap at 16 have long
>>>>>> been
>>>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>>>> So I
>>>>>> propose we remove that arbitrary limitation too.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>
>>>
>>
>


From david.holmes at oracle.com  Tue Dec 15 05:41:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Dec 2015 15:41:43 +1000
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access
	a member of class java.lang.management.ManagementFactory (module
	java.management)
In-Reply-To: <566EF48E.3050300@oracle.com>
References: <566EF48E.3050300@oracle.com>
Message-ID: <566FA817.3080908@oracle.com>

Hi Jaroslav,

This movement of functionality seems okay to me. And good to see the JDK 
6 code removed :)

Thanks,
David

On 15/12/2015 2:55 AM, Jaroslav Bachorik wrote:
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
>
> The problem is that the class UsageTrackerClient is accessing
> RuntimeMXBean.getInputArguments() method via reflection to avoid static
> dependency. However, with functional module boundaries this fails.
>
> Since the functionality provided by RuntimeMXBean.getInputArguments() is
> not, in fact, specific to the management subsystem, it makes sense to
> move it out of jmm.h to jvm.h
>
> Full suite of SVC tests was run against this change successfully on all
> platforms.
>
>
> Thanks,
>
> -JB-


From mandy.chung at oracle.com  Tue Dec 15 05:57:59 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 14 Dec 2015 21:57:59 -0800
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can
	not access a member of class
	java.lang.management.ManagementFactory (module java.management)
In-Reply-To: <566EF48E.3050300@oracle.com>
References: <566EF48E.3050300@oracle.com>
Message-ID: <98F38847-D110-45CB-9E64-B38B41C56444@oracle.com>


> On Dec 14, 2015, at 8:55 AM, Jaroslav Bachorik <jaroslav.bachorik at oracle.com> wrote:
> 
> Please, review the following change
> 
> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
> 
> The problem is that the class UsageTrackerClient is accessing RuntimeMXBean.getInputArguments() method via reflection to avoid static dependency. However, with functional module boundaries this fails.
> 
> Since the functionality provided by RuntimeMXBean.getInputArguments() is not, in fact, specific to the management subsystem, it makes sense to move it out of jmm.h to jvm.h
> 

This change looks okay.

Mandy



From Alan.Bateman at oracle.com  Tue Dec 15 07:03:21 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Dec 2015 07:03:21 +0000
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access
	a member of class java.lang.management.ManagementFactory (module
	java.management)
In-Reply-To: <566EF48E.3050300@oracle.com>
References: <566EF48E.3050300@oracle.com>
Message-ID: <566FBB39.8010806@oracle.com>



On 14/12/2015 16:55, Jaroslav Bachorik wrote:
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
>
> The problem is that the class UsageTrackerClient is accessing 
> RuntimeMXBean.getInputArguments() method via reflection to avoid 
> static dependency. However, with functional module boundaries this fails.
>
> Since the functionality provided by RuntimeMXBean.getInputArguments() 
> is not, in fact, specific to the management subsystem, it makes sense 
> to move it out of jmm.h to jvm.h
Make sense to me too and the changes look okay. One small thing is that 
make/share/makefiles/mapfile-vers seems to list the JVM_ functions in 
alphabetic order, I assume you want to preserve that convention.

-Alan.


From david.holmes at oracle.com  Tue Dec 15 07:43:35 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Dec 2015 17:43:35 +1000
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
Message-ID: <566FC4A7.1010709@oracle.com>

On 15/12/2015 1:27 PM, Martin Buchholz wrote:
> My current mental model is
> configured cpus >= online cpus >= allowed cpus
> In a traditional system they are all the same.
>
> I experimented and saw that cpusets are indeed turned on in some
> systems used for testing at Google.
> I.e. allowed cpus is a strict subset of online cpus.
>
> It seems likely that the following would be a better implementation of
> availableProcessors on Linux:
>
>    cpu_set_t s;
>    return (sched_getaffinity(0, sizeof(s), &s) == 0) ? CPU_COUNT(&s) :
> fallback_to_old_way();
>
> with all the pain in configury.

Yes this is covered in this older bug that I had forgotten about:

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

David
-----

> On Mon, Dec 14, 2015 at 6:58 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>> Hi David,
>>
>> On 2015-12-11 14:21, David Holmes wrote:
>>>
>>> On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
>>>>
>>>> On 2015-12-03 03:11, Roger Riggs wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> It would be useful to figure out the number of cpus available when in
>>>>> a container.
>>>>> Some comments have added to:
>>>>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>>>>> getAvailableProcessors may incorrectly report the number of cpus in
>>>>> Docker container
>>>>>
>>>>> But so far we haven't dug deep enough.   Suggestions are welcome?
>>>>
>>>>
>>>> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
>>>>
>>>> suggests running nproc. I'm not sure if that can be counted on to be
>>>> present, but we could certainly check for it.
>>>
>>>
>>> I'd like to know how nproc does it so we can try to apply the same logic
>>> in the VM for Runtime.availableProcessors. Can someone actually confirm
>>> that it returns the number of processors available to the container?
>>
>>
>> I don't have a container at hand but running nproc under strace suggests
>> that it calls sched_getaffinity and counts the number of set bits in the cpu
>> affinity mask:
>>
>> $ strace -e trace=sched_getaffinity nproc
>> sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
>> 4
>> +++ exited with 0 +++
>>
>> It would be nice if anyone with access to a system where the number of cpus
>> is limited in a similar manner to a docker container could run the above
>> command and see if it
>> 1) returns the correct number of cpus
>> 2) works as I think, that is, it counts the number of set bits in the array
>> which is the third syscall argument.
>>
>>
>> /Mikael
>>
>>
>>
>>>
>>> David
>>>
>>>> /Magnus
>>>>
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>>>>>
>>>>>> Not to say you shouldn't do this, but I worry that increasingly
>>>>>> computing
>>>>>> is being done in "containers" where e.g. the number of cpus is doubling
>>>>>> every year but only a small number are available to actually be used
>>>>>> by a
>>>>>> given process.  if availableProcessors reports 1 million, what
>>>>>> should we
>>>>>> do?  (no need to answer...)
>>>>>>
>>>>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson
>>>>>> <erik.joelsson at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> The current heuristic for figuring out what to default set the -j
>>>>>>> flag to
>>>>>>> make needs some tweaking.
>>>>>>>
>>>>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>>>>> the
>>>>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>>>>> will
>>>>>>> fit into memory. The lower of that number and the number of cpus is
>>>>>>> then
>>>>>>> picked. The number is then scaled down to about 90% of the number of
>>>>>>> cpus
>>>>>>> to leave some resources for other activities. It is also capped at 16.
>>>>>>>
>>>>>>> Since we now have the build using "nice" to make sure the build isn't
>>>>>>> bogging down the system, I see no reason to do the 90% scaling
>>>>>>> anymore.
>>>>>>> Also, the performance issues that forced us to cap at 16 have long
>>>>>>> been
>>>>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>>>>> So I
>>>>>>> propose we remove that arbitrary limitation too.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>
>>>>
>>>
>>


From jaroslav.bachorik at oracle.com  Tue Dec 15 08:16:52 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 15 Dec 2015 09:16:52 +0100
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access
	a member of class java.lang.management.ManagementFactory (module
	java.management)
In-Reply-To: <566FBB39.8010806@oracle.com>
References: <566EF48E.3050300@oracle.com> <566FBB39.8010806@oracle.com>
Message-ID: <566FCC74.3010101@oracle.com>

On 15.12.2015 08:03, Alan Bateman wrote:
>
>
> On 14/12/2015 16:55, Jaroslav Bachorik wrote:
>> Please, review the following change
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
>>
>> The problem is that the class UsageTrackerClient is accessing
>> RuntimeMXBean.getInputArguments() method via reflection to avoid
>> static dependency. However, with functional module boundaries this fails.
>>
>> Since the functionality provided by RuntimeMXBean.getInputArguments()
>> is not, in fact, specific to the management subsystem, it makes sense
>> to move it out of jmm.h to jvm.h
> Make sense to me too and the changes look okay. One small thing is that
> make/share/makefiles/mapfile-vers seems to list the JVM_ functions in
> alphabetic order, I assume you want to preserve that convention.

Sure. I will update this before pushing. Slipped my attention - I pasted 
it there like JVM_GetInputArguments and then renamed it :(
Thanks for catching this.

-JB-

>
> -Alan.



From erik.joelsson at oracle.com  Tue Dec 15 09:21:14 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 15 Dec 2015 10:21:14 +0100
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access
	a member of class java.lang.management.ManagementFactory (module
	java.management)
In-Reply-To: <566EF48E.3050300@oracle.com>
References: <566EF48E.3050300@oracle.com>
Message-ID: <566FDB8A.4060209@oracle.com>

Build changes look good to me.

/Erik

On 2015-12-14 17:55, Jaroslav Bachorik wrote:
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
>
> The problem is that the class UsageTrackerClient is accessing 
> RuntimeMXBean.getInputArguments() method via reflection to avoid 
> static dependency. However, with functional module boundaries this fails.
>
> Since the functionality provided by RuntimeMXBean.getInputArguments() 
> is not, in fact, specific to the management subsystem, it makes sense 
> to move it out of jmm.h to jvm.h
>
> Full suite of SVC tests was run against this change successfully on 
> all platforms.
>
>
> Thanks,
>
> -JB-



From erik.joelsson at oracle.com  Tue Dec 15 10:37:46 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 15 Dec 2015 11:37:46 +0100
Subject: RFR: JDK-8145391: Updated jprt.properties, devtools, jib and readme
	with SS12u4
Message-ID: <566FED7A.2040100@oracle.com>

The default compiler for Solaris was changed in build 96. The jprt 
configuration, jib, devtools and readme needs to be updated to reflect 
this. In the readme, there are some other left overs from other compiler 
changes that also need to be tweaked.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145391
Webrev: http://cr.openjdk.java.net/~erikj/8145391/webrev.01/

/Erik


From magnus.ihse.bursie at oracle.com  Tue Dec 15 13:01:05 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2015 14:01:05 +0100
Subject: RFR: JDK-8145391: Updated jprt.properties, devtools, jib and
	readme with SS12u4
In-Reply-To: <566FED7A.2040100@oracle.com>
References: <566FED7A.2040100@oracle.com>
Message-ID: <56700F11.1000609@oracle.com>

On 2015-12-15 11:37, Erik Joelsson wrote:
> The default compiler for Solaris was changed in build 96. The jprt 
> configuration, jib, devtools and readme needs to be updated to reflect 
> this. In the readme, there are some other left overs from other 
> compiler changes that also need to be tweaked.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145391
> Webrev: http://cr.openjdk.java.net/~erikj/8145391/webrev.01/
>
> /Erik
Looks good to me.

/Magnus


From magnus.ihse.bursie at oracle.com  Tue Dec 15 13:23:49 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2015 14:23:49 +0100
Subject: RFR 8142398: IllegalAccessException Class
	sun.usagetracker.UsageTrackerClient$4 (module java.base) can not access
	a member of class java.lang.management.ManagementFactory (module
	java.management)
In-Reply-To: <566EF48E.3050300@oracle.com>
References: <566EF48E.3050300@oracle.com>
Message-ID: <56701465.4060503@oracle.com>

On 2015-12-14 17:55, Jaroslav Bachorik wrote:
> Please, review the following change
>
> Issue : https://bugs.openjdk.java.net/browse/JDK-8138677
> Webrev: http://cr.openjdk.java.net/~jbachorik/8138677/webrev.00
>
> The problem is that the class UsageTrackerClient is accessing 
> RuntimeMXBean.getInputArguments() method via reflection to avoid 
> static dependency. However, with functional module boundaries this fails.
>
> Since the functionality provided by RuntimeMXBean.getInputArguments() 
> is not, in fact, specific to the management subsystem, it makes sense 
> to move it out of jmm.h to jvm.h
>
> Full suite of SVC tests was run against this change successfully on 
> all platforms.
>
>
> Thanks,
>
> -JB-

Build changes look good to me.

/Magnus



From magnus.ihse.bursie at oracle.com  Tue Dec 15 13:28:06 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2015 14:28:06 +0100
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
Message-ID: <56701566.6080508@oracle.com>

On 2015-12-15 04:27, Martin Buchholz wrote:
> My current mental model is
> configured cpus >= online cpus >= allowed cpus
> In a traditional system they are all the same.
>
> I experimented and saw that cpusets are indeed turned on in some
> systems used for testing at Google.
> I.e. allowed cpus is a strict subset of online cpus.
>
> It seems likely that the following would be a better implementation of
> availableProcessors on Linux:
>
>    cpu_set_t s;
>    return (sched_getaffinity(0, sizeof(s), &s) == 0) ? CPU_COUNT(&s) :
> fallback_to_old_way();
>
> with all the pain in configury.

Making system calls from configure is more than acceptably difficult. 
:-) But if nproc does this, we can do something like checking if nproc 
is present, and if so, if it returns a non-zero value, we use it, 
otherwise we fall back to the current method. Is that what you're 
suggesting?

/Magnus


>
> On Mon, Dec 14, 2015 at 6:58 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>> Hi David,
>>
>> On 2015-12-11 14:21, David Holmes wrote:
>>> On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
>>>> On 2015-12-03 03:11, Roger Riggs wrote:
>>>>> Hi,
>>>>>
>>>>> It would be useful to figure out the number of cpus available when in
>>>>> a container.
>>>>> Some comments have added to:
>>>>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>>>>> getAvailableProcessors may incorrectly report the number of cpus in
>>>>> Docker container
>>>>>
>>>>> But so far we haven't dug deep enough.   Suggestions are welcome?
>>>>
>>>> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
>>>>
>>>> suggests running nproc. I'm not sure if that can be counted on to be
>>>> present, but we could certainly check for it.
>>>
>>> I'd like to know how nproc does it so we can try to apply the same logic
>>> in the VM for Runtime.availableProcessors. Can someone actually confirm
>>> that it returns the number of processors available to the container?
>>
>> I don't have a container at hand but running nproc under strace suggests
>> that it calls sched_getaffinity and counts the number of set bits in the cpu
>> affinity mask:
>>
>> $ strace -e trace=sched_getaffinity nproc
>> sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
>> 4
>> +++ exited with 0 +++
>>
>> It would be nice if anyone with access to a system where the number of cpus
>> is limited in a similar manner to a docker container could run the above
>> command and see if it
>> 1) returns the correct number of cpus
>> 2) works as I think, that is, it counts the number of set bits in the array
>> which is the third syscall argument.
>>
>>
>> /Mikael
>>
>>
>>
>>> David
>>>
>>>> /Magnus
>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>>>>> Not to say you shouldn't do this, but I worry that increasingly
>>>>>> computing
>>>>>> is being done in "containers" where e.g. the number of cpus is doubling
>>>>>> every year but only a small number are available to actually be used
>>>>>> by a
>>>>>> given process.  if availableProcessors reports 1 million, what
>>>>>> should we
>>>>>> do?  (no need to answer...)
>>>>>>
>>>>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson
>>>>>> <erik.joelsson at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> The current heuristic for figuring out what to default set the -j
>>>>>>> flag to
>>>>>>> make needs some tweaking.
>>>>>>>
>>>>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>>>>> the
>>>>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>>>>> will
>>>>>>> fit into memory. The lower of that number and the number of cpus is
>>>>>>> then
>>>>>>> picked. The number is then scaled down to about 90% of the number of
>>>>>>> cpus
>>>>>>> to leave some resources for other activities. It is also capped at 16.
>>>>>>>
>>>>>>> Since we now have the build using "nice" to make sure the build isn't
>>>>>>> bogging down the system, I see no reason to do the 90% scaling
>>>>>>> anymore.
>>>>>>> Also, the performance issues that forced us to cap at 16 have long
>>>>>>> been
>>>>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>>>>> So I
>>>>>>> propose we remove that arbitrary limitation too.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>>>>
>>>>>>> /Erik
>>>>>>>



From erik.joelsson at oracle.com  Tue Dec 15 14:29:50 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 15 Dec 2015 15:29:50 +0100
Subject: RFR: JDK-8145391: Updated jprt.properties, devtools, jib and
	readme with SS12u4
In-Reply-To: <56700F11.1000609@oracle.com>
References: <566FED7A.2040100@oracle.com> <56700F11.1000609@oracle.com>
Message-ID: <567023DE.7010004@oracle.com>

I missed adding two files. New webrev:

http://cr.openjdk.java.net/~erikj/8145391/webrev.02/

/Erik

On 2015-12-15 14:01, Magnus Ihse Bursie wrote:
> On 2015-12-15 11:37, Erik Joelsson wrote:
>> The default compiler for Solaris was changed in build 96. The jprt 
>> configuration, jib, devtools and readme needs to be updated to 
>> reflect this. In the readme, there are some other left overs from 
>> other compiler changes that also need to be tweaked.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145391
>> Webrev: http://cr.openjdk.java.net/~erikj/8145391/webrev.01/
>>
>> /Erik
> Looks good to me.
>
> /Magnus



From tim.bell at oracle.com  Tue Dec 15 14:40:11 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 15 Dec 2015 06:40:11 -0800
Subject: RFR: JDK-8145391: Updated jprt.properties, devtools, jib and
	readme with SS12u4
In-Reply-To: <567023DE.7010004@oracle.com>
References: <566FED7A.2040100@oracle.com> <56700F11.1000609@oracle.com>
	<567023DE.7010004@oracle.com>
Message-ID: <5670264B.3040704@oracle.com>

Erik:

> I missed adding two files. New webrev:
>
> http://cr.openjdk.java.net/~erikj/8145391/webrev.02/
>
> /Erik
>
> On 2015-12-15 14:01, Magnus Ihse Bursie wrote:
>> On 2015-12-15 11:37, Erik Joelsson wrote:
>>> The default compiler for Solaris was changed in build 96. The jprt 
>>> configuration, jib, devtools and readme needs to be updated to 
>>> reflect this. In the readme, there are some other left overs from 
>>> other compiler changes that also need to be tweaked.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145391
>>> Webrev: http://cr.openjdk.java.net/~erikj/8145391/webrev.01/
>>>
>>> /Erik
>> Looks good to me.
>>
>> /Magnus

Looks good to me as well.

/Tim




From magnus.ihse.bursie at oracle.com  Tue Dec 15 14:43:35 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2015 15:43:35 +0100
Subject: RFR: JDK-8145391: Updated jprt.properties, devtools, jib and
	readme with SS12u4
In-Reply-To: <567023DE.7010004@oracle.com>
References: <566FED7A.2040100@oracle.com> <56700F11.1000609@oracle.com>
	<567023DE.7010004@oracle.com>
Message-ID: <56702717.1070402@oracle.com>

On 2015-12-15 15:29, Erik Joelsson wrote:
> I missed adding two files. New webrev:
>
> http://cr.openjdk.java.net/~erikj/8145391/webrev.02/
Looks good to me.

/Magnus

>
> /Erik
>
> On 2015-12-15 14:01, Magnus Ihse Bursie wrote:
>> On 2015-12-15 11:37, Erik Joelsson wrote:
>>> The default compiler for Solaris was changed in build 96. The jprt 
>>> configuration, jib, devtools and readme needs to be updated to 
>>> reflect this. In the readme, there are some other left overs from 
>>> other compiler changes that also need to be tweaked.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145391
>>> Webrev: http://cr.openjdk.java.net/~erikj/8145391/webrev.01/
>>>
>>> /Erik
>> Looks good to me.
>>
>> /Magnus
>



From martinrb at google.com  Tue Dec 15 17:25:52 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Dec 2015 09:25:52 -0800
Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe
In-Reply-To: <56704076.8050203@Oracle.com>
References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com>
	<56704076.8050203@Oracle.com>
Message-ID: <CA+kOe08k4S5vejaLeMHghG6HkgAokEUubHHbgROvoiDUq-N2BQ@mail.gmail.com>

_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
affects interoperability between translation units.  It would be good
to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but
that would be a big job.  So traditionally the JDK has instead used
the functions made available via _LARGEFILE64_SOURCE.  But that is
also a JDK-wide job now, because every call to plain stat in the
source code is broken on 32-bit systems with 64-bit inodes, which are
becoming more common.

I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job
for build-dev, not core-libs-dev.




On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Yvom,
>
> Minor comments:
>
> src/java.base/share/native/libjava/RandomAccessFile.c:
>  - "length fail" might be clearer as "GetLength failed"
>
> src/java.base/unix/native/libjava/io_util_md.c:
>
>  - Please add a comment before the define of FILE_OFFSET_BITS to indicate
> where it is used and why it is there.
>  - BTW, are there any unintended side effects?
>    Perhaps a different issue but perhaps 64 bit offsets should be used
> everywhere
>
> src/java.base/windows/native/libjava/io_util_md.c
>  - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used
> elsewhere in the file
>    BTW, Testing for invalid handle might be unnecessary since the call to
> GetFileSizeEx will fail
>    if it is invalid, yielding the same result.
>
> Roger
>
>
> On 12/10/2015 5:52 AM, vyom wrote:
>>
>> Hi All,
>>
>> Please review my changes for below bug.
>>
>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe
>>
>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/
>> <http://cr.openjdk.java.net/%7Evtewari/4823133/webrev0.0/>
>>
>> This change ensure that  length() does not temporarily changes the file
>> pointer and it will make sure that there is no race
>> condition in case of multi thread uses.
>>
>> Thanks,
>> Vyom
>>
>>
>>
>>
>


From martinrb at google.com  Tue Dec 15 17:28:21 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Dec 2015 09:28:21 -0800
Subject: RFR: JDK-8115868: 32-bit JVM failed to start from a large network
	filesystem
In-Reply-To: <567037AA.30801@oracle.com>
References: <567037AA.30801@oracle.com>
Message-ID: <CA+kOe09AQOSbVMO+janN8+=cGyZTB8Woj2+05hrQiT5DUqoV2Q@mail.gmail.com>

Note that the semantics of stat and access may be subtly different,
and that there are many calls to stat in the JDK sources, and they may
all be broken on 32-bit systems.

I just wrote elsewhere:

_FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
affects interoperability between translation units.  It would be good
to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but
that would be a big job.  So traditionally the JDK has instead used
the functions made available via _LARGEFILE64_SOURCE.  But that is
also a JDK-wide job now, because every call to plain stat in the
source code is broken on 32-bit systems with 64-bit inodes, which are
becoming more common.

I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job
for build-dev, not core-libs-dev.

On Tue, Dec 15, 2015 at 7:54 AM, Kumar Srinivasan
<kumar.x.srinivasan at oracle.com> wrote:
> Hello,
>
> Please review fix for: JDK-8115868
>
> The webrev is here:
> http://cr.openjdk.java.net/~ksrini/8115868/webrev.0/
>
> The background:
> The launcher uses stat(2) to check for the existence of a file,
> unfortunately
> on 32-bit system with large file systems causes the inode storage to
> overflow
> causing the syscall to return EOVERFLOW.
>
> Solution:
> * stat(2)  replaced with access(3), in most cases.
> * jbs is marked noreg-hard hard to replicate the problem
>
> Thanks
> Kumar
>
>
>
>
>


From martinrb at google.com  Tue Dec 15 18:38:19 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Dec 2015 10:38:19 -0800
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <56701566.6080508@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
	<56701566.6080508@oracle.com>
Message-ID: <CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>

Actually calling nproc as a separate process at runtime is interesting
but totally unorthodox.

I think the configury pain is the usual: detecting sched.h,
sched_getaffinity, CPU_COUNT, don't forget _GNU_SOURCE, check you're
on a glibc system, probably check at runtime too, so use dlsym to
access sched_getaffinity, look for similar hacks on non-glibc systems.
Worry about systems with more than 1024 cpus.  Worry about
sched_getaffinity returning a higher number than the old way.

Is that enough things to worry about?

On Tue, Dec 15, 2015 at 5:28 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2015-12-15 04:27, Martin Buchholz wrote:
>>
>> My current mental model is
>> configured cpus >= online cpus >= allowed cpus
>> In a traditional system they are all the same.
>>
>> I experimented and saw that cpusets are indeed turned on in some
>> systems used for testing at Google.
>> I.e. allowed cpus is a strict subset of online cpus.
>>
>> It seems likely that the following would be a better implementation of
>> availableProcessors on Linux:
>>
>>    cpu_set_t s;
>>    return (sched_getaffinity(0, sizeof(s), &s) == 0) ? CPU_COUNT(&s) :
>> fallback_to_old_way();
>>
>> with all the pain in configury.
>
>
> Making system calls from configure is more than acceptably difficult. :-)
> But if nproc does this, we can do something like checking if nproc is
> present, and if so, if it returns a non-zero value, we use it, otherwise we
> fall back to the current method. Is that what you're suggesting?
>
> /Magnus
>
>
>
>>
>> On Mon, Dec 14, 2015 at 6:58 AM, Mikael Gerdin <mikael.gerdin at oracle.com>
>> wrote:
>>>
>>> Hi David,
>>>
>>> On 2015-12-11 14:21, David Holmes wrote:
>>>>
>>>> On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
>>>>>
>>>>> On 2015-12-03 03:11, Roger Riggs wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It would be useful to figure out the number of cpus available when in
>>>>>> a container.
>>>>>> Some comments have added to:
>>>>>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>>>>>> getAvailableProcessors may incorrectly report the number of cpus in
>>>>>> Docker container
>>>>>>
>>>>>> But so far we haven't dug deep enough.   Suggestions are welcome?
>>>>>
>>>>>
>>>>>
>>>>> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
>>>>>
>>>>> suggests running nproc. I'm not sure if that can be counted on to be
>>>>> present, but we could certainly check for it.
>>>>
>>>>
>>>> I'd like to know how nproc does it so we can try to apply the same logic
>>>> in the VM for Runtime.availableProcessors. Can someone actually confirm
>>>> that it returns the number of processors available to the container?
>>>
>>>
>>> I don't have a container at hand but running nproc under strace suggests
>>> that it calls sched_getaffinity and counts the number of set bits in the
>>> cpu
>>> affinity mask:
>>>
>>> $ strace -e trace=sched_getaffinity nproc
>>> sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
>>> 4
>>> +++ exited with 0 +++
>>>
>>> It would be nice if anyone with access to a system where the number of
>>> cpus
>>> is limited in a similar manner to a docker container could run the above
>>> command and see if it
>>> 1) returns the correct number of cpus
>>> 2) works as I think, that is, it counts the number of set bits in the
>>> array
>>> which is the third syscall argument.
>>>
>>>
>>> /Mikael
>>>
>>>
>>>
>>>> David
>>>>
>>>>> /Magnus
>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>>>>>>
>>>>>>> Not to say you shouldn't do this, but I worry that increasingly
>>>>>>> computing
>>>>>>> is being done in "containers" where e.g. the number of cpus is
>>>>>>> doubling
>>>>>>> every year but only a small number are available to actually be used
>>>>>>> by a
>>>>>>> given process.  if availableProcessors reports 1 million, what
>>>>>>> should we
>>>>>>> do?  (no need to answer...)
>>>>>>>
>>>>>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson
>>>>>>> <erik.joelsson at oracle.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> The current heuristic for figuring out what to default set the -j
>>>>>>>> flag to
>>>>>>>> make needs some tweaking.
>>>>>>>>
>>>>>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>>>>>> the
>>>>>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>>>>>> will
>>>>>>>> fit into memory. The lower of that number and the number of cpus is
>>>>>>>> then
>>>>>>>> picked. The number is then scaled down to about 90% of the number of
>>>>>>>> cpus
>>>>>>>> to leave some resources for other activities. It is also capped at
>>>>>>>> 16.
>>>>>>>>
>>>>>>>> Since we now have the build using "nice" to make sure the build
>>>>>>>> isn't
>>>>>>>> bogging down the system, I see no reason to do the 90% scaling
>>>>>>>> anymore.
>>>>>>>> Also, the performance issues that forced us to cap at 16 have long
>>>>>>>> been
>>>>>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>>>>>> So I
>>>>>>>> propose we remove that arbitrary limitation too.
>>>>>>>>
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>>>>>
>>>>>>>> /Erik
>>>>>>>>
>


From david.holmes at oracle.com  Wed Dec 16 06:21:31 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 16 Dec 2015 16:21:31 +1000
Subject: RFR(xs): 8145427: [aix] xlc: wrong flag used to switch off
	optimization
In-Reply-To: <CAA-vtUxVUPgJsdKapeOqro=ThdXzvNVcZaVcJav3ktXyp3ifFQ@mail.gmail.com>
References: <CAA-vtUxVUPgJsdKapeOqro=ThdXzvNVcZaVcJav3ktXyp3ifFQ@mail.gmail.com>
Message-ID: <567102EB.9070407@oracle.com>

Hi Thomas,

This kind of thing goes to build-dev (cc'd) not jdk9-dev (which doesn't 
take code reviews).

I've Reviewed this, and as it is a trivial change, and we're going to 
put it into hs-rt forest, I will sponsor it for you.

Thanks,
David

On 16/12/2015 3:22 AM, Thomas St?fe wrote:
> Hi all,
>
> this fixes a small typo in flags.m4 for AIX-specific compiler flags
> introduced with JDK-8032045. Please review and sponsor.
>
> The fix itself is trivial, but this is the first time I modified the
> configure script and I hope all is well. After modifying flags.m4, I ran
> "bash ./common/bin/autogen.sh".
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145427
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8145427-aix-typo-flags.m4/webrev.00/webrev/
>
> Thank you!
>
> ..Thomas
>


From thomas.stuefe at gmail.com  Wed Dec 16 06:46:09 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 16 Dec 2015 07:46:09 +0100
Subject: RFR(xs): 8145427: [aix] xlc: wrong flag used to switch off
	optimization
In-Reply-To: <567102EB.9070407@oracle.com>
References: <CAA-vtUxVUPgJsdKapeOqro=ThdXzvNVcZaVcJav3ktXyp3ifFQ@mail.gmail.com>
	<567102EB.9070407@oracle.com>
Message-ID: <CAA-vtUyO6YMT6_TfxJgLFTcMyr6XVYUToR4ktq1-=t9AtaryrQ@mail.gmail.com>

Hi David,

thank you!

..Thomas

On Wed, Dec 16, 2015 at 7:21 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> This kind of thing goes to build-dev (cc'd) not jdk9-dev (which doesn't
> take code reviews).
>
> I've Reviewed this, and as it is a trivial change, and we're going to put
> it into hs-rt forest, I will sponsor it for you.
>
> Thanks,
> David
>
>
> On 16/12/2015 3:22 AM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> this fixes a small typo in flags.m4 for AIX-specific compiler flags
>> introduced with JDK-8032045. Please review and sponsor.
>>
>> The fix itself is trivial, but this is the first time I modified the
>> configure script and I hope all is well. After modifying flags.m4, I ran
>> "bash ./common/bin/autogen.sh".
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145427
>> webrev:
>>
>> http://cr.openjdk.java.net/~stuefe/webrevs/8145427-aix-typo-flags.m4/webrev.00/webrev/
>>
>> Thank you!
>>
>> ..Thomas
>>
>>


From magnus.ihse.bursie at oracle.com  Wed Dec 16 13:35:15 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2015 14:35:15 +0100
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
Message-ID: <BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>

> On 2015-11-05 18:03, Timo Kinnunen wrote:
> Hi,
>  
> I have signed the OCA and emailed a scan according the instructions. I separated the freetype changes into a separate batch as suggested. I have shared the patch files on OneDrive, they are my Public folder. Here?s the link to the folder: https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>  
> The OneDrive folder should contain these 4 files:
>  
> freetype_JDK9.patch
> vs2015_JDK9.patch
> vs2015_JDK9_hotspot.patch
> vs2015_JDK9_jdk.patch
>  
> The first two target the root repository, the other two are for hotspot and jdk repositories, respectively.
>  
> I rebased the patches on JDK9 tip today. I           ran ?make images? and fixed a couple of new errors that have appeared since the previous version. A couple of the changes I had made were also not needed any more.
>  
> Please have a look!

Hi Timo,

I'm sorry for the long delay.

I have created JDK-8145548 for the freetype fix. I'm sponsoring this fix. I'll send out a proper review on cr.openjdk.java.net shortly.

The vs2015 changes are more complicated since they touch multiple places in the code. Also, your patch had started bitrotting slightly during my long response time. I'm trying to fix it up, and will post a review when I have sorted everything out. I will verify that the change does not break any of our supported platforms, but I'd like you to verify that the patch still works on VS2015. When I publish the webrev, there will be a download link to the patch file.

Also, this patch touches both hotspot code and multiple jdk modules, so it will need to be reviewed by other groups as well, besides the build team.

/Magnus

>  
>  
>  
>  
>  
>  
> Sent from Mail for Windows 10
>  
>  
> 
> From: Magnus Ihse Bursie
> Sent: Friday, October 23, 2015 17:13
> To: timo.kinnunen at gmail.com;build-dev
> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition
>  
>  
> On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
> > Hi,
> > 
> > I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete.
> > 
> > I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes.
> > 
> > The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes.
> > 
> > The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?.
> > 
> > Would you be willing to incorporate these? How should I proceed with this?
>  
> Hi Timo,
>  
> First of all, I apologize that you have not recieved any response for
> far too long. :-(
>  
> Thank you for your interest in helping to improve OpenJDK!
>  
> In general, a patch to allow compilation on           VS 2015 Community edition
> sounds like a good edition to OpenJDK. I am willing to sponsor this
> patch and help you work with getting it accepted.
>  
> My first question to you is: have you signed the OCA? Also, unless
> you've done so already, reading http://openjdk.java.net/contribute/ is a
> good start for starting to contribute to OpenJDK.
>  
> However, supporting a new compiler, without at the same time breaking an
> older one, can sometimes be tricky business. This means that you might
> need to iterate your patch a number of times, until it's suitable for
> inclusion. I don't want to scare you away, just be realistic up front
> that it might require some more work from your part (and our!). Also,
> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
> SP4, so I know what I'm talking about...)
>  
> From what you write, I think you should try           to separate the
> freetype-src default directory from the compiler upgrade settings. The
> former might be easier to start with, as it's less likely to be
> disruptive for anything else.
>  
> Also, at this point, I think it would be helpful for me to be able to
> have an initial look at the patches. You need to be an OpenJDK Author to
> be able to access the OpenJDK infrastructure, so unfortunately that is
> not available to you. :-( For a first peek, the patches can be provided
> just about any way (but attachments to this list is unfortunately not
> allowed). For a final, proper, code review they need to reside on our
> infrastructure, but at that point I can help with fixing that.
>  
> /Magnus



From magnus.ihse.bursie at oracle.com  Wed Dec 16 13:35:50 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2015 14:35:50 +0100
Subject: RFR: JDK-8145548 Add default directory for freetype source
Message-ID: <ADF42B82-638B-45A3-ADBC-BE115E2F5B18@oracle.com>

To facilitate building freetype from source on Windows, search a well-defined location ($HOME/freetype) for freetype sources. 

Patch contributed by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145548
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145548-add-default-freetype-src-dir/webrev.01

/Magnus



From erik.joelsson at oracle.com  Wed Dec 16 13:45:34 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Dec 2015 14:45:34 +0100
Subject: RFR: JDK-8145548 Add default directory for freetype source
In-Reply-To: <ADF42B82-638B-45A3-ADBC-BE115E2F5B18@oracle.com>
References: <ADF42B82-638B-45A3-ADBC-BE115E2F5B18@oracle.com>
Message-ID: <56716AFE.3040501@oracle.com>

Looks ok to me.

/Erik

On 2015-12-16 14:35, Magnus Ihse Bursie wrote:
> To facilitate building freetype from source on Windows, search a well-defined location ($HOME/freetype) for freetype sources.
>
> Patch contributed by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145548
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145548-add-default-freetype-src-dir/webrev.01
>
> /Magnus
>



From magnus.ihse.bursie at oracle.com  Wed Dec 16 13:50:20 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2015 14:50:20 +0100
Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community edition
Message-ID: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>

There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. 

This patch is provided by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.

The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well.

I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145549
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Wed Dec 16 14:08:23 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2015 15:08:23 +0100
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
	<56701566.6080508@oracle.com>
	<CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>
Message-ID: <56717057.2000701@oracle.com>

On 2015-12-15 19:38, Martin Buchholz wrote:
> Actually calling nproc as a separate process at runtime is interesting
> but totally unorthodox.
>
> I think the configury pain is the usual: detecting sched.h,
> sched_getaffinity, CPU_COUNT, don't forget _GNU_SOURCE, check you're
> on a glibc system, probably check at runtime too, so use dlsym to
> access sched_getaffinity, look for similar hacks on non-glibc systems.
> Worry about systems with more than 1024 cpus.  Worry about
> sched_getaffinity returning a higher number than the old way.
>
> Is that enough things to worry about?

Are you talking about JDK-6515172? I was thinking on how to implement a 
proper check in the configure script, where calling separate process are 
not so unorthodox after all. ;-)

I'd still like to see some real-world confirmation that nproc does 
indeed return the correct number of cpus in a Docker environment.

/Magnus


>
> On Tue, Dec 15, 2015 at 5:28 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2015-12-15 04:27, Martin Buchholz wrote:
>>> My current mental model is
>>> configured cpus >= online cpus >= allowed cpus
>>> In a traditional system they are all the same.
>>>
>>> I experimented and saw that cpusets are indeed turned on in some
>>> systems used for testing at Google.
>>> I.e. allowed cpus is a strict subset of online cpus.
>>>
>>> It seems likely that the following would be a better implementation of
>>> availableProcessors on Linux:
>>>
>>>     cpu_set_t s;
>>>     return (sched_getaffinity(0, sizeof(s), &s) == 0) ? CPU_COUNT(&s) :
>>> fallback_to_old_way();
>>>
>>> with all the pain in configury.
>>
>> Making system calls from configure is more than acceptably difficult. :-)
>> But if nproc does this, we can do something like checking if nproc is
>> present, and if so, if it returns a non-zero value, we use it, otherwise we
>> fall back to the current method. Is that what you're suggesting?
>>
>> /Magnus
>>
>>
>>
>>> On Mon, Dec 14, 2015 at 6:58 AM, Mikael Gerdin <mikael.gerdin at oracle.com>
>>> wrote:
>>>> Hi David,
>>>>
>>>> On 2015-12-11 14:21, David Holmes wrote:
>>>>> On 11/12/2015 11:16 PM, Magnus Ihse Bursie wrote:
>>>>>> On 2015-12-03 03:11, Roger Riggs wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> It would be useful to figure out the number of cpus available when in
>>>>>>> a container.
>>>>>>> Some comments have added to:
>>>>>>> 8140793 <https://bugs.openjdk.java.net/browse/JDK-8140793>
>>>>>>> getAvailableProcessors may incorrectly report the number of cpus in
>>>>>>> Docker container
>>>>>>>
>>>>>>> But so far we haven't dug deep enough.   Suggestions are welcome?
>>>>>>
>>>>>>
>>>>>> http://serverfault.com/questions/691659/count-number-of-allowed-cpus-in-a-docker-container
>>>>>>
>>>>>> suggests running nproc. I'm not sure if that can be counted on to be
>>>>>> present, but we could certainly check for it.
>>>>>
>>>>> I'd like to know how nproc does it so we can try to apply the same logic
>>>>> in the VM for Runtime.availableProcessors. Can someone actually confirm
>>>>> that it returns the number of processors available to the container?
>>>>
>>>> I don't have a container at hand but running nproc under strace suggests
>>>> that it calls sched_getaffinity and counts the number of set bits in the
>>>> cpu
>>>> affinity mask:
>>>>
>>>> $ strace -e trace=sched_getaffinity nproc
>>>> sched_getaffinity(0, 128, {f, 0, 0, 0}) = 32
>>>> 4
>>>> +++ exited with 0 +++
>>>>
>>>> It would be nice if anyone with access to a system where the number of
>>>> cpus
>>>> is limited in a similar manner to a docker container could run the above
>>>> command and see if it
>>>> 1) returns the correct number of cpus
>>>> 2) works as I think, that is, it counts the number of set bits in the
>>>> array
>>>> which is the third syscall argument.
>>>>
>>>>
>>>> /Mikael
>>>>
>>>>
>>>>
>>>>> David
>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>> On 12/2/15 6:59 PM, Martin Buchholz wrote:
>>>>>>>> Not to say you shouldn't do this, but I worry that increasingly
>>>>>>>> computing
>>>>>>>> is being done in "containers" where e.g. the number of cpus is
>>>>>>>> doubling
>>>>>>>> every year but only a small number are available to actually be used
>>>>>>>> by a
>>>>>>>> given process.  if availableProcessors reports 1 million, what
>>>>>>>> should we
>>>>>>>> do?  (no need to answer...)
>>>>>>>>
>>>>>>>> On Tue, Dec 1, 2015 at 1:55 AM, Erik Joelsson
>>>>>>>> <erik.joelsson at oracle.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> The current heuristic for figuring out what to default set the -j
>>>>>>>>> flag to
>>>>>>>>> make needs some tweaking.
>>>>>>>>>
>>>>>>>>> In JDK 9, it looks at the amount of memory and the number of cpus in
>>>>>>>>> the
>>>>>>>>> system. It divides memory by 1024 to get a safe number of jobs that
>>>>>>>>> will
>>>>>>>>> fit into memory. The lower of that number and the number of cpus is
>>>>>>>>> then
>>>>>>>>> picked. The number is then scaled down to about 90% of the number of
>>>>>>>>> cpus
>>>>>>>>> to leave some resources for other activities. It is also capped at
>>>>>>>>> 16.
>>>>>>>>>
>>>>>>>>> Since we now have the build using "nice" to make sure the build
>>>>>>>>> isn't
>>>>>>>>> bogging down the system, I see no reason to do the 90% scaling
>>>>>>>>> anymore.
>>>>>>>>> Also, the performance issues that forced us to cap at 16 have long
>>>>>>>>> been
>>>>>>>>> fixed, and even if we don't scale well beyond 16, we do still scale.
>>>>>>>>> So I
>>>>>>>>> propose we remove that arbitrary limitation too.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144312
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8144312/webrev.01/
>>>>>>>>>
>>>>>>>>> /Erik
>>>>>>>>>



From erik.joelsson at oracle.com  Wed Dec 16 14:37:02 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Dec 2015 15:37:02 +0100
Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community
	edition
In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
Message-ID: <5671770E.90001@oracle.com>

The configure change looks good. Can't comment on the code changes.

/Erik

On 2015-12-16 14:50, Magnus Ihse Bursie wrote:
> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition.
>
> This patch is provided by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.
>
> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well.
>
> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01
>
> /Magnus



From volker.simonis at gmail.com  Wed Dec 16 14:45:01 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Dec 2015 15:45:01 +0100
Subject: RFR(S): 8145560: AIX: change '8036003: Add --with-debug-symbols'
	broke AIX build
Message-ID: <CA+3eh129kGNkAfThfzx4Vs8Rh=9i+ogzqoed6-wo4dKMkJksFg@mail.gmail.com>

Hi,

could somebody please review and sponsor (regeneration of
'generated-configure.sh' is required) the following small change:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8145560/
https://bugs.openjdk.java.net/browse/JDK-8145560

Change 8036003 introduced the the '--with-native-debug-symbols'
configure option the default of which is set to 'zipped'.

On AIX we can not generated external debug info and hence we also can
not zip it. Currently the build breaks because of the missing
dependencies from .diz to .debuginfo files.

The fix is simple - make 'internal' the default value for the
'--with-native-debug-symbols' configure option on AIX.

Thank you and best regards,
Volker


From erik.joelsson at oracle.com  Wed Dec 16 14:47:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Dec 2015 15:47:06 +0100
Subject: RFR(S): 8145560: AIX: change '8036003: Add --with-debug-symbols'
	broke AIX build
In-Reply-To: <CA+3eh129kGNkAfThfzx4Vs8Rh=9i+ogzqoed6-wo4dKMkJksFg@mail.gmail.com>
References: <CA+3eh129kGNkAfThfzx4Vs8Rh=9i+ogzqoed6-wo4dKMkJksFg@mail.gmail.com>
Message-ID: <5671796A.6070702@oracle.com>

Looks good to me. I will sponsor it.

/Erik

On 2015-12-16 15:45, Volker Simonis wrote:
> Hi,
>
> could somebody please review and sponsor (regeneration of
> 'generated-configure.sh' is required) the following small change:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145560/
> https://bugs.openjdk.java.net/browse/JDK-8145560
>
> Change 8036003 introduced the the '--with-native-debug-symbols'
> configure option the default of which is set to 'zipped'.
>
> On AIX we can not generated external debug info and hence we also can
> not zip it. Currently the build breaks because of the missing
> dependencies from .diz to .debuginfo files.
>
> The fix is simple - make 'internal' the default value for the
> '--with-native-debug-symbols' configure option on AIX.
>
> Thank you and best regards,
> Volker



From volker.simonis at gmail.com  Wed Dec 16 15:08:09 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Dec 2015 16:08:09 +0100
Subject: RFR(S): 8145560: AIX: change '8036003: Add --with-debug-symbols'
	broke AIX build
In-Reply-To: <5671796A.6070702@oracle.com>
References: <CA+3eh129kGNkAfThfzx4Vs8Rh=9i+ogzqoed6-wo4dKMkJksFg@mail.gmail.com>
	<5671796A.6070702@oracle.com>
Message-ID: <CA+3eh13yb2xGxV=d4Qx=mmU-vgT5gNPr-dT=VdXw213M+WYAiw@mail.gmail.com>

Thanks a lot Erik!

That was really fast :)

Regards,
Volker


On Wed, Dec 16, 2015 at 3:47 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Looks good to me. I will sponsor it.
>
> /Erik
>
>
> On 2015-12-16 15:45, Volker Simonis wrote:
>>
>> Hi,
>>
>> could somebody please review and sponsor (regeneration of
>> 'generated-configure.sh' is required) the following small change:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8145560/
>> https://bugs.openjdk.java.net/browse/JDK-8145560
>>
>> Change 8036003 introduced the the '--with-native-debug-symbols'
>> configure option the default of which is set to 'zipped'.
>>
>> On AIX we can not generated external debug info and hence we also can
>> not zip it. Currently the build breaks because of the missing
>> dependencies from .diz to .debuginfo files.
>>
>> The fix is simple - make 'internal' the default value for the
>> '--with-native-debug-symbols' configure option on AIX.
>>
>> Thank you and best regards,
>> Volker
>
>


From timo.kinnunen at gmail.com  Wed Dec 16 15:28:23 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 16 Dec 2015 16:28:23 +0100
Subject: Building jdk9 on Windows x64 and Visual Studio
	2015Communityedition
In-Reply-To: <BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
Message-ID: <56718317.6650c20a.a11d6.55cd@mx.google.com>

Thank you very much! 

Don?t worry about the delay, I see that things are hectic and also just picking up speed :) 

Regarding the other non-freetype changes, hopefully a lot of them could be introduced by enabling warnings in other compilers until VS2015 is supported. I went with not simply disabling all the new warnings to make evaluating this easier.





-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10


From: Magnus Ihse Bursie
Sent: Wednesday, December 16, 2015 14:35
To: Timo Kinnunen; build-dev
Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015Communityedition

On 2015-11-05 18:03, Timo Kinnunen wrote:
Hi, 
?
I have signed the OCA and emailed a scan according the instructions. I separated the freetype changes into a separate batch as suggested. I have shared the patch files on OneDrive, they are my Public folder. Here?s the link to the folder: https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107 
?
The OneDrive folder should contain these 4 files:
?
freetype_JDK9.patch
vs2015_JDK9.patch
vs2015_JDK9_hotspot.patch
vs2015_JDK9_jdk.patch
?
The first two target the root repository, the other two are for hotspot and jdk repositories, respectively.
?
I rebased the patches on JDK9 tip today. I ran ?make images? and fixed a couple of new errors that have appeared since the previous version. A couple of the changes I had made were also not needed any more.
?
Please have a look!

Hi Timo,

I'm sorry for the long delay.

I have created JDK-8145548 for the freetype fix. I'm sponsoring this fix. I'll send out a proper review on cr.openjdk.java.net shortly.

The vs2015 changes are more complicated since they touch multiple places in the code. Also, your patch had started bitrotting slightly during my long response time. I'm trying to fix it up, and will post a review when I have sorted everything out. I will verify that the change does not break any of our supported platforms, but I'd like you to verify that the patch still works on VS2015. When I publish the webrev, there will be a download link to the patch file.

Also, this patch touches both hotspot code and multiple jdk modules, so it will need to be reviewed by other groups as well, besides the build team.

/Magnus


?
?
?
?
?
?
Sent from Mail for Windows 10
?
?

From: Magnus Ihse Bursie
Sent: Friday, October 23, 2015 17:13
To: timo.kinnunen at gmail.com;build-dev
Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition
?
?
On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
> Hi,
>?
> I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete.
>?
> I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes.
>?
> The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes.
>?
> The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?.
>?
> Would you be willing to incorporate these? How should I proceed with this?
?
Hi Timo,
?
First of all, I apologize that you have not recieved any response for 
far too long. :-(
?
Thank you for your interest in helping to improve OpenJDK!
?
In general, a patch to allow compilation on VS 2015 Community edition 
sounds like a good edition to OpenJDK. I am willing to sponsor this 
patch and help you work with getting it accepted.
?
My first question to you is: have you signed the OCA? Also, unless 
you've done so already, reading http://openjdk.java.net/contribute/ is a 
good start for starting to contribute to OpenJDK.
?
However, supporting a new compiler, without at the same time breaking an 
older one, can sometimes be tricky business. This means that you might 
need to iterate your patch a number of times, until it's suitable for 
inclusion. I don't want to scare you away, just be realistic up front 
that it might require some more work from your part (and our!). Also, 
(FYI, we have recently upgraded the compilers used at Oracle to VS2013 
SP4, so I know what I'm talking about...)
?
>From what you write, I think you should try to separate the 
freetype-src default directory from the compiler upgrade settings. The 
former might be easier to start with, as it's less likely to be 
disruptive for anything else.
?
Also, at this point, I think it would be helpful for me to be able to 
have an initial look at the patches. You need to be an OpenJDK Author to 
be able to access the OpenJDK infrastructure, so unfortunately that is 
not available to you. :-( For a first peek, the patches can be provided 
just about any way (but attachments to this list is unfortunately not 
allowed). For a final, proper, code review they need to reside on our 
infrastructure, but at that point I can help with fixing that.
?
/Magnus
?
?




From kumar.x.srinivasan at oracle.com  Wed Dec 16 15:33:20 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 16 Dec 2015 07:33:20 -0800
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
Message-ID: <56718440.2070501@oracle.com>

Hello,

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html

You are undefining Windows math.h OVERFLOW, what is it defined
as ? With you redefining this, will it cause problems for users of
this API, likely to affect JNI apps.

Probably need to redefine the pack200 OVERFLOW constant to
something else, probably PACK200_OVERFLOW to prevent namespace
collisions.

Kumar

On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>> Hi,
>>   
>> I have signed the OCA and emailed a scan according the instructions. I separated the freetype changes into a separate batch as suggested. I have shared the patch files on OneDrive, they are my Public folder. Here?s the link to the folder: https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>   
>> The OneDrive folder should contain these 4 files:
>>   
>> freetype_JDK9.patch
>> vs2015_JDK9.patch
>> vs2015_JDK9_hotspot.patch
>> vs2015_JDK9_jdk.patch
>>   
>> The first two target the root repository, the other two are for hotspot and jdk repositories, respectively.
>>   
>> I rebased the patches on JDK9 tip today. I           ran ?make images? and fixed a couple of new errors that have appeared since the previous version. A couple of the changes I had made were also not needed any more.
>>   
>> Please have a look!
> Hi Timo,
>
> I'm sorry for the long delay.
>
> I have created JDK-8145548 for the freetype fix. I'm sponsoring this fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>
> The vs2015 changes are more complicated since they touch multiple places in the code. Also, your patch had started bitrotting slightly during my long response time. I'm trying to fix it up, and will post a review when I have sorted everything out. I will verify that the change does not break any of our supported platforms, but I'd like you to verify that the patch still works on VS2015. When I publish the webrev, there will be a download link to the patch file.
>
> Also, this patch touches both hotspot code and multiple jdk modules, so it will need to be reviewed by other groups as well, besides the build team.
>
> /Magnus
>
>>   
>>   
>>   
>>   
>>   
>>   
>> Sent from Mail for Windows 10
>>   
>>   
>>
>> From: Magnus Ihse Bursie
>> Sent: Friday, October 23, 2015 17:13
>> To: timo.kinnunen at gmail.com;build-dev
>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition
>>   
>>   
>> On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>> Hi,
>>>
>>> I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete.
>>>
>>> I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes.
>>>
>>> The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes.
>>>
>>> The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?.
>>>
>>> Would you be willing to incorporate these? How should I proceed with this?
>>   
>> Hi Timo,
>>   
>> First of all, I apologize that you have not recieved any response for
>> far too long. :-(
>>   
>> Thank you for your interest in helping to improve OpenJDK!
>>   
>> In general, a patch to allow compilation on           VS 2015 Community edition
>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>> patch and help you work with getting it accepted.
>>   
>> My first question to you is: have you signed the OCA? Also, unless
>> you've done so already, reading http://openjdk.java.net/contribute/ is a
>> good start for starting to contribute to OpenJDK.
>>   
>> However, supporting a new compiler, without at the same time breaking an
>> older one, can sometimes be tricky business. This means that you might
>> need to iterate your patch a number of times, until it's suitable for
>> inclusion. I don't want to scare you away, just be realistic up front
>> that it might require some more work from your part (and our!). Also,
>> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
>> SP4, so I know what I'm talking about...)
>>   
>>  From what you write, I think you should try           to separate the
>> freetype-src default directory from the compiler upgrade settings. The
>> former might be easier to start with, as it's less likely to be
>> disruptive for anything else.
>>   
>> Also, at this point, I think it would be helpful for me to be able to
>> have an initial look at the patches. You need to be an OpenJDK Author to
>> be able to access the OpenJDK infrastructure, so unfortunately that is
>> not available to you. :-( For a first peek, the patches can be provided
>> just about any way (but attachments to this list is unfortunately not
>> allowed). For a final, proper, code review they need to reside on our
>> infrastructure, but at that point I can help with fixing that.
>>   
>> /Magnus



From timo.kinnunen at gmail.com  Wed Dec 16 16:29:56 2015
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 16 Dec 2015 17:29:56 +0100
Subject: Building jdk9 on Windows x64 and Visual Studio
	2015Communityedition
In-Reply-To: <56718440.2070501@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
	<56718440.2070501@oracle.com>
Message-ID: <56719184.07bd1c0a.a9450.ffffcaa1@mx.google.com>

Hi, 

OVERFLOW is defined as the value ?3?, meaning ?overflow range error?. It is one of types of floating point exceptions that when detected can be passed to matherr, and used within the passed in exception struct.




-- 
Have a nice day, 
Timo

Sent from Mail for Windows 10


From: Kumar Srinivasan
Sent: Wednesday, December 16, 2015 16:39
To: Magnus Ihse Bursie; Timo Kinnunen
Cc: build-dev
Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015Communityedition

Hello,

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html

You are undefining Windows math.h OVERFLOW, what is it defined
as ? With you redefining this, will it cause problems for users of
this API, likely to affect JNI apps.

Probably need to redefine the pack200 OVERFLOW constant to
something else, probably PACK200_OVERFLOW to prevent namespace
collisions.

Kumar

On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>> Hi,
>>   
>> I have signed the OCA and emailed a scan according the instructions. I separated the freetype changes into a separate batch as suggested. I have shared the patch files on OneDrive, they are my Public folder. Here?s the link to the folder: https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>   
>> The OneDrive folder should contain these 4 files:
>>   
>> freetype_JDK9.patch
>> vs2015_JDK9.patch
>> vs2015_JDK9_hotspot.patch
>> vs2015_JDK9_jdk.patch
>>   
>> The first two target the root repository, the other two are for hotspot and jdk repositories, respectively.
>>   
>> I rebased the patches on JDK9 tip today. I           ran ?make images? and fixed a couple of new errors that have appeared since the previous version. A couple of the changes I had made were also not needed any more.
>>   
>> Please have a look!
> Hi Timo,
>
> I'm sorry for the long delay.
>
> I have created JDK-8145548 for the freetype fix. I'm sponsoring this fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>
> The vs2015 changes are more complicated since they touch multiple places in the code. Also, your patch had started bitrotting slightly during my long response time. I'm trying to fix it up, and will post a review when I have sorted everything out. I will verify that the change does not break any of our supported platforms, but I'd like you to verify that the patch still works on VS2015. When I publish the webrev, there will be a download link to the patch file.
>
> Also, this patch touches both hotspot code and multiple jdk modules, so it will need to be reviewed by other groups as well, besides the build team.
>
> /Magnus
>
>>   
>>   
>>   
>>   
>>   
>>   
>> Sent from Mail for Windows 10
>>   
>>   
>>
>> From: Magnus Ihse Bursie
>> Sent: Friday, October 23, 2015 17:13
>> To: timo.kinnunen at gmail.com;build-dev
>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 Communityedition
>>   
>>   
>> On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>> Hi,
>>>
>>> I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete.
>>>
>>> I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes.
>>>
>>> The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes.
>>>
>>> The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?.
>>>
>>> Would you be willing to incorporate these? How should I proceed with this?
>>   
>> Hi Timo,
>>   
>> First of all, I apologize that you have not recieved any response for
>> far too long. :-(
>>   
>> Thank you for your interest in helping to improve OpenJDK!
>>   
>> In general, a patch to allow compilation on           VS 2015 Community edition
>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>> patch and help you work with getting it accepted.
>>   
>> My first question to you is: have you signed the OCA? Also, unless
>> you've done so already, reading http://openjdk.java.net/contribute/ is a
>> good start for starting to contribute to OpenJDK.
>>   
>> However, supporting a new compiler, without at the same time breaking an
>> older one, can sometimes be tricky business. This means that you might
>> need to iterate your patch a number of times, until it's suitable for
>> inclusion. I don't want to scare you away, just be realistic up front
>> that it might require some more work from your part (and our!). Also,
>> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
>> SP4, so I know what I'm talking about...)
>>   
>>  From what you write, I think you should try           to separate the
>> freetype-src default directory from the compiler upgrade settings. The
>> former might be easier to start with, as it's less likely to be
>> disruptive for anything else.
>>   
>> Also, at this point, I think it would be helpful for me to be able to
>> have an initial look at the patches. You need to be an OpenJDK Author to
>> be able to access the OpenJDK infrastructure, so unfortunately that is
>> not available to you. :-( For a first peek, the patches can be provided
>> just about any way (but attachments to this list is unfortunately not
>> allowed). For a final, proper, code review they need to reside on our
>> infrastructure, but at that point I can help with fixing that.
>>   
>> /Magnus




From martinrb at google.com  Wed Dec 16 18:37:58 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Dec 2015 10:37:58 -0800
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <56717057.2000701@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
	<56701566.6080508@oracle.com>
	<CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>
	<56717057.2000701@oracle.com>
Message-ID: <CA+kOe08RfbUnB=U0VJ854ZZWfLQpN9E2ngz+_iBTdCdPvbFABA@mail.gmail.com>

On Wed, Dec 16, 2015 at 6:08 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2015-12-15 19:38, Martin Buchholz wrote:

> Are you talking about JDK-6515172? I was thinking on how to implement a
> proper check in the configure script, where calling separate process are not
> so unorthodox after all. ;-)

Thanks all for pointing me at JDK-6515172.  Calling nproc in the
configure script seems crazy to me - what can you tell from the
result?

Instead, use standard autoconf macros like

AC_CONFIG_HEADERS([sched.h])
AC_CHECK_FUNC(sched_getaffinity)


From magnus.ihse.bursie at oracle.com  Wed Dec 16 20:18:34 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2015 21:18:34 +0100
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <56718440.2070501@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
	<56718440.2070501@oracle.com>
Message-ID: <5671C71A.3060404@oracle.com>

On 2015-12-16 16:33, Kumar Srinivasan wrote:
> Hello,
>
> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html 
>
>
> You are undefining Windows math.h OVERFLOW, what is it defined
> as ? With you redefining this, will it cause problems for users of
> this API, likely to affect JNI apps.
>
> Probably need to redefine the pack200 OVERFLOW constant to
> something else, probably PACK200_OVERFLOW to prevent namespace
> collisions.

I agree, this is a better solution. I've updated the webrev with this 
solution (although I used the name PSIZE_OVERFLOW to align with PSIZE_MAX).

http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02

/Magnus


>
> Kumar
>
> On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>>> Hi,
>>>   I have signed the OCA and emailed a scan according the 
>>> instructions. I separated the freetype changes into a separate batch 
>>> as suggested. I have shared the patch files on OneDrive, they are my 
>>> Public folder. Here?s the link to the folder: 
>>> https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>>   The OneDrive folder should contain these 4 files:
>>>   freetype_JDK9.patch
>>> vs2015_JDK9.patch
>>> vs2015_JDK9_hotspot.patch
>>> vs2015_JDK9_jdk.patch
>>>   The first two target the root repository, the other two are for 
>>> hotspot and jdk repositories, respectively.
>>>   I rebased the patches on JDK9 tip today. I           ran ?make 
>>> images? and fixed a couple of new errors that have appeared since 
>>> the previous version. A couple of the changes I had made were also 
>>> not needed any more.
>>>   Please have a look!
>> Hi Timo,
>>
>> I'm sorry for the long delay.
>>
>> I have created JDK-8145548 for the freetype fix. I'm sponsoring this 
>> fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>>
>> The vs2015 changes are more complicated since they touch multiple 
>> places in the code. Also, your patch had started bitrotting slightly 
>> during my long response time. I'm trying to fix it up, and will post 
>> a review when I have sorted everything out. I will verify that the 
>> change does not break any of our supported platforms, but I'd like 
>> you to verify that the patch still works on VS2015. When I publish 
>> the webrev, there will be a download link to the patch file.
>>
>> Also, this patch touches both hotspot code and multiple jdk modules, 
>> so it will need to be reviewed by other groups as well, besides the 
>> build team.
>>
>> /Magnus
>>
>>>             Sent from Mail for Windows 10
>>>
>>> From: Magnus Ihse Bursie
>>> Sent: Friday, October 23, 2015 17:13
>>> To: timo.kinnunen at gmail.com;build-dev
>>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 
>>> Communityedition
>>>     On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>>> Hi,
>>>>
>>>> I?ve been going over the Windows build of the whole JDK for a while 
>>>> with VS 2015 and now I have patches that allow the build to complete.
>>>>
>>>> I?ve made changes in the root repository as well as in hotspot and 
>>>> jdk repositories. The changes fall broadly in three categories: 
>>>> enabling the v140 toolchain and improving freetype compilation, 
>>>> adding casts to where pointers are truncated and miscellaneous 
>>>> small-scale code changes.
>>>>
>>>> The patch to the root repository streamlines handling of freetype 
>>>> by implementing a default source directory at $HOME/freetype under 
>>>> Cygwin. It is checked during configure and used for compiling if 
>>>> ?--with-freetype-src? is not specified. A help message giving the 
>>>> unpacking command with the correct directory is also included. This 
>>>> patch is about 90 lines without counting generated-configure.sh 
>>>> changes.
>>>>
>>>> The patches to jdk and hotspot contain native code changes only and 
>>>> no changes to make-files. These are about 580 and 290 lines, 
>>>> respectively. All patches are generated with ?hg diff -g?.
>>>>
>>>> Would you be willing to incorporate these? How should I proceed 
>>>> with this?
>>>   Hi Timo,
>>>   First of all, I apologize that you have not recieved any response for
>>> far too long. :-(
>>>   Thank you for your interest in helping to improve OpenJDK!
>>>   In general, a patch to allow compilation on           VS 2015 
>>> Community edition
>>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>>> patch and help you work with getting it accepted.
>>>   My first question to you is: have you signed the OCA? Also, unless
>>> you've done so already, reading http://openjdk.java.net/contribute/ 
>>> is a
>>> good start for starting to contribute to OpenJDK.
>>>   However, supporting a new compiler, without at the same time 
>>> breaking an
>>> older one, can sometimes be tricky business. This means that you might
>>> need to iterate your patch a number of times, until it's suitable for
>>> inclusion. I don't want to scare you away, just be realistic up front
>>> that it might require some more work from your part (and our!). Also,
>>> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
>>> SP4, so I know what I'm talking about...)
>>>    From what you write, I think you should try           to separate 
>>> the
>>> freetype-src default directory from the compiler upgrade settings. The
>>> former might be easier to start with, as it's less likely to be
>>> disruptive for anything else.
>>>   Also, at this point, I think it would be helpful for me to be able to
>>> have an initial look at the patches. You need to be an OpenJDK 
>>> Author to
>>> be able to access the OpenJDK infrastructure, so unfortunately that is
>>> not available to you. :-( For a first peek, the patches can be provided
>>> just about any way (but attachments to this list is unfortunately not
>>> allowed). For a final, proper, code review they need to reside on our
>>> infrastructure, but at that point I can help with fixing that.
>>>   /Magnus
>



From erik.joelsson at oracle.com  Wed Dec 16 21:34:03 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Dec 2015 22:34:03 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
Message-ID: <5671D8CB.8080500@oracle.com>

Hello,

Please review this quick fix for the build issue introduced in Hotspot 
by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true 
when building Hotspot fastdebug, you essentially get a slowdebug build. 
For an explanation of why, see comment in bug. This behavior is of 
course also a bug, but not something I will address in this quick fix.

What happened in JDK-8036003 was that a new configure API for 
controlling debug symbols was introduced. The two main settings of this 
new parameter, --with-native-debug-symbols, that we use internally at 
Oracle are "external" and "zipped". It was important to us that the 
behavior of these did not change with JDK-8036003, but exactly that did 
happen, because both of these settings now cause DEBUG_BINARIES=true to 
be set. This variable has never been set by configure before and because 
of the above weird behavior in the Hotspot makefiles, we are having 
problems.

My proposed quick fix is to not set DEBUG_BINARIES=true for "external" 
or "zipped". It can remain true for "internal" since Oracle never builds 
it that way, and I understand those that requested this new configure 
parameter were setting DEBUG_BINARIES=true as a workaround before this 
anyway, so they should be fine with the broken fastdebug behavior for a 
while more. I will file a follow up bug to properly clean up this mess, 
but it will take some more time.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/

/Erik


From erik.joelsson at oracle.com  Wed Dec 16 21:35:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Dec 2015 22:35:06 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5671D8CB.8080500@oracle.com>
References: <5671D8CB.8080500@oracle.com>
Message-ID: <5671D90A.5020208@oracle.com>

One more thing, where should this fix be pushed? Do you need it urgently 
in hs-rt?

/Erik

On 2015-12-16 22:34, Erik Joelsson wrote:
> Hello,
>
> Please review this quick fix for the build issue introduced in Hotspot 
> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true 
> when building Hotspot fastdebug, you essentially get a slowdebug 
> build. For an explanation of why, see comment in bug. This behavior is 
> of course also a bug, but not something I will address in this quick fix.
>
> What happened in JDK-8036003 was that a new configure API for 
> controlling debug symbols was introduced. The two main settings of 
> this new parameter, --with-native-debug-symbols, that we use 
> internally at Oracle are "external" and "zipped". It was important to 
> us that the behavior of these did not change with JDK-8036003, but 
> exactly that did happen, because both of these settings now cause 
> DEBUG_BINARIES=true to be set. This variable has never been set by 
> configure before and because of the above weird behavior in the 
> Hotspot makefiles, we are having problems.
>
> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" 
> or "zipped". It can remain true for "internal" since Oracle never 
> builds it that way, and I understand those that requested this new 
> configure parameter were setting DEBUG_BINARIES=true as a workaround 
> before this anyway, so they should be fine with the broken fastdebug 
> behavior for a while more. I will file a follow up bug to properly 
> clean up this mess, but it will take some more time.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>
> /Erik



From erik.joelsson at oracle.com  Wed Dec 16 21:36:36 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 16 Dec 2015 22:36:36 +0100
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <CA+kOe08RfbUnB=U0VJ854ZZWfLQpN9E2ngz+_iBTdCdPvbFABA@mail.gmail.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
	<56701566.6080508@oracle.com>
	<CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>
	<56717057.2000701@oracle.com>
	<CA+kOe08RfbUnB=U0VJ854ZZWfLQpN9E2ngz+_iBTdCdPvbFABA@mail.gmail.com>
Message-ID: <5671D964.7000406@oracle.com>

We want to find a suitable default value for the make -j flag.

/Erik

On 2015-12-16 19:37, Martin Buchholz wrote:
> On Wed, Dec 16, 2015 at 6:08 AM, Magnus Ihse Bursie
> <magnus.ihse.bursie at oracle.com> wrote:
>> On 2015-12-15 19:38, Martin Buchholz wrote:
>> Are you talking about JDK-6515172? I was thinking on how to implement a
>> proper check in the configure script, where calling separate process are not
>> so unorthodox after all. ;-)
> Thanks all for pointing me at JDK-6515172.  Calling nproc in the
> configure script seems crazy to me - what can you tell from the
> result?
>
> Instead, use standard autoconf macros like
>
> AC_CONFIG_HEADERS([sched.h])
> AC_CHECK_FUNC(sched_getaffinity)



From magnus.ihse.bursie at oracle.com  Wed Dec 16 21:38:15 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2015 22:38:15 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5671D8CB.8080500@oracle.com>
References: <5671D8CB.8080500@oracle.com>
Message-ID: <5671D9C7.1030608@oracle.com>

On 2015-12-16 22:34, Erik Joelsson wrote:
> Hello,
>
> Please review this quick fix for the build issue introduced in Hotspot 
> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true 
> when building Hotspot fastdebug, you essentially get a slowdebug 
> build. For an explanation of why, see comment in bug. This behavior is 
> of course also a bug, but not something I will address in this quick fix.
>
> What happened in JDK-8036003 was that a new configure API for 
> controlling debug symbols was introduced. The two main settings of 
> this new parameter, --with-native-debug-symbols, that we use 
> internally at Oracle are "external" and "zipped". It was important to 
> us that the behavior of these did not change with JDK-8036003, but 
> exactly that did happen, because both of these settings now cause 
> DEBUG_BINARIES=true to be set. This variable has never been set by 
> configure before and because of the above weird behavior in the 
> Hotspot makefiles, we are having problems.
>
> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" 
> or "zipped". It can remain true for "internal" since Oracle never 
> builds it that way, and I understand those that requested this new 
> configure parameter were setting DEBUG_BINARIES=true as a workaround 
> before this anyway, so they should be fine with the broken fastdebug 
> behavior for a while more. I will file a follow up bug to properly 
> clean up this mess, but it will take some more time.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/

Looks good to me.

/Magnus


From martinrb at google.com  Wed Dec 16 21:41:17 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Dec 2015 13:41:17 -0800
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <5671D964.7000406@oracle.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
	<56701566.6080508@oracle.com>
	<CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>
	<56717057.2000701@oracle.com>
	<CA+kOe08RfbUnB=U0VJ854ZZWfLQpN9E2ngz+_iBTdCdPvbFABA@mail.gmail.com>
	<5671D964.7000406@oracle.com>
Message-ID: <CA+kOe0-kYE_nPqRHfr0pO9inNMszJcUkHjmH0pmPUkH6pY+-pQ@mail.gmail.com>

We can fix both JDK-6515172 and JDK-8144312 by doing the autconf
detection of how to count the number of allowed processors, then
actually measuring what's available during the build, and also fixing
the hotspot implemementation of Runtime.availableProcessors.


From igor.ignatyev at oracle.com  Wed Dec 16 22:09:54 2015
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 17 Dec 2015 01:09:54 +0300
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for
	HotSpot build 
Message-ID: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>

> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/
11 lines changed: 4 ins; 0 del; 7 mod; 

Hi,

could you please review the fix for 8144695[1]?

8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly.
the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined.

[1] https://bugs.openjdk.java.net/browse/JDK-8144695
[2] https://bugs.openjdk.java.net/browse/JDK-8141543

Thanks,
? Igor 




From igor.ignatyev at oracle.com  Wed Dec 16 22:54:38 2015
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 17 Dec 2015 01:54:38 +0300
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work
	for HotSpot build 
In-Reply-To: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
References: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
Message-ID: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>

as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc.
here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/

and diff comparing to the prev. iteration:

> diff -r fe04b6ccb21a make/solaris/makefiles/adlc.make
> --- a/make/solaris/makefiles/adlc.make	Thu Dec 17 00:50:42 2015 +0300
> +++ b/make/solaris/makefiles/adlc.make	Thu Dec 17 01:47:39 2015 +0300
> @@ -77,7 +77,7 @@
>    WARNINGS_ARE_ERRORS ?= -w -xwe
>  endif
>  
> -CFLAGS_WARN = WARNINGS_ARE_ERRORS
> +CFLAGS_WARN = $(WARNINGS_ARE_ERRORS)
>  
>  # When using compiler version 5.13 (Solaris Studio 12.4), calls to explicitly
>  # instantiated template functions trigger this warning when +w is active.

? Igor

> On Dec 17, 2015, at 1:09 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
>> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/
> 11 lines changed: 4 ins; 0 del; 7 mod; 
> 
> Hi,
> 
> could you please review the fix for 8144695[1]?
> 
> 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly.
> the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8144695
> [2] https://bugs.openjdk.java.net/browse/JDK-8141543
> 
> Thanks,
> ? Igor 
> 
> 



From magnus.ihse.bursie at oracle.com  Wed Dec 16 23:09:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Dec 2015 00:09:57 +0100
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work
	for HotSpot build
In-Reply-To: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
References: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
	<5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
Message-ID: <5671EF45.4090807@oracle.com>

On 2015-12-16 23:54, Igor Ignatyev wrote:
> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc.
> here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/
>
> and diff comparing to the prev. iteration:
>
>> diff -r fe04b6ccb21a make/solaris/makefiles/adlc.make
>> --- a/make/solaris/makefiles/adlc.make	Thu Dec 17 00:50:42 2015 +0300
>> +++ b/make/solaris/makefiles/adlc.make	Thu Dec 17 01:47:39 2015 +0300
>> @@ -77,7 +77,7 @@
>>     WARNINGS_ARE_ERRORS ?= -w -xwe
>>   endif
>>   
>> -CFLAGS_WARN = WARNINGS_ARE_ERRORS
>> +CFLAGS_WARN = $(WARNINGS_ARE_ERRORS)
>>   
>>   # When using compiler version 5.13 (Solaris Studio 12.4), calls to explicitly
>>   # instantiated template functions trigger this warning when +w is active.
Have you tested that this achieves the correct thing, i.e. if introduce 
a warning in a file, you can still build successfully on all platforms 
with --disable-warnings-as-errors?

/Magnus

> ? Igor
>
>> On Dec 17, 2015, at 1:09 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>
>>> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/
>> 11 lines changed: 4 ins; 0 del; 7 mod;
>>
>> Hi,
>>
>> could you please review the fix for 8144695[1]?
>>
>> 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly.
>> the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8144695
>> [2] https://bugs.openjdk.java.net/browse/JDK-8141543
>>
>> Thanks,
>> ? Igor
>>
>>



From kim.barrett at oracle.com  Wed Dec 16 23:10:46 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 16 Dec 2015 18:10:46 -0500
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work
	for HotSpot build 
In-Reply-To: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
References: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
	<5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
Message-ID: <D7DD0D77-222E-492A-A131-A4BD9362A217@oracle.com>

On Dec 16, 2015, at 5:54 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc.
> here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/

I wonder why the value for WARNINGS_ARE_ERRORS isn't obtained from the
configure-provided variable CFLAGS_WARNINGS_ARE_ERRORS?
E.g. something like

  WARNINGS_ARE_ERRORS ?= $(CFLAGS_WARNINGS_ARE_ERRORS)

There may be a good reason for that, and thinking about it is probably
better done as a separate RFE.  Doing so might simplify things by
allowing the assignment to be moved to some higher level common point.
[The bsd conditionalization on $(COMPILER_WARNINGS_FATAL) might make
that hard.  Where does that variable come from?  I haven't looked for
anything similar elsewhere.]

------------------------------------------------------------------------------ 
make/solaris/makefiles/adlc.make 
  77   WARNINGS_ARE_ERRORS ?= -w -xwe

I'm pretty sure "-w" is wrong here, and should be removed.  And it's
not clear why this assignment should be conditional on the compiler
version.

------------------------------------------------------------------------------



From igor.ignatyev at oracle.com  Wed Dec 16 23:14:44 2015
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 17 Dec 2015 02:14:44 +0300
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work
	for HotSpot build
In-Reply-To: <5671EF45.4090807@oracle.com>
References: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
	<5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
	<5671EF45.4090807@oracle.com>
Message-ID: <DB056A0D-0D65-4E61-A342-8105939C9018@oracle.com>


> On Dec 17, 2015, at 2:09 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> On 2015-12-16 23:54, Igor Ignatyev wrote:
>> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc.
>> here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/
>> 
>> and diff comparing to the prev. iteration:
>> 
>>> diff -r fe04b6ccb21a make/solaris/makefiles/adlc.make
>>> --- a/make/solaris/makefiles/adlc.make	Thu Dec 17 00:50:42 2015 +0300
>>> +++ b/make/solaris/makefiles/adlc.make	Thu Dec 17 01:47:39 2015 +0300
>>> @@ -77,7 +77,7 @@
>>>    WARNINGS_ARE_ERRORS ?= -w -xwe
>>>  endif
>>>  -CFLAGS_WARN = WARNINGS_ARE_ERRORS
>>> +CFLAGS_WARN = $(WARNINGS_ARE_ERRORS)
>>>    # When using compiler version 5.13 (Solaris Studio 12.4), calls to explicitly
>>>  # instantiated template functions trigger this warning when +w is active.
> Have you tested that this achieves the correct thing, i.e. if introduce a warning in a file, you can still build successfully on all platforms with --disable-warnings-as-errors?
not on all platforms, but I checked that it fixes the problem from the description:
>  sh ./configure --disable-warnings-as-errors --enable-native-coverage --enable-debug 
> make all 
> ... 
> /home/dmitry/work/bugs/disable_warnings_as_errors/jdk9-hs-rt/hotspot/src/share/vm/gc/shared/genCollectedHeap.cpp: In function ?ScratchBlock* removeSmallestScratch(ScratchBlock**)?: 
> /home/dmitry/work/bugs/disable_warnings_as_errors/jdk9-hs-rt/hotspot/src/share/vm/gc/shared/genCollectedHeap.cpp:1032:33: error: ?smallest_ptr? may be used uninitialized in this function [-Werror=maybe-uninitialized] 
>    *smallest_ptr = smallest->next; 
>                                  ^ 
> cc1plus: all warnings being treated as errors 
> make[8]: *** [genCollectedHeap.o] Error 1 

will double check other platforms.

? Igor
> 
> /Magnus
> 
>> ? Igor
>> 
>>> On Dec 17, 2015, at 1:09 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>>> http://cr.openjdk.java.net/~iignatyev/8144695/webrev.00/
>>> 11 lines changed: 4 ins; 0 del; 7 mod;
>>> 
>>> Hi,
>>> 
>>> could you please review the fix for 8144695[1]?
>>> 
>>> 8141543[1] propagated --disable-warnings-as-errors to hotspot build by setting WARNINGS_ARE_ERRORS to empty line. however in hotspot makefiles there are places where this variable is set explicitly.
>>> the fix changes = operator to ?= operator and updates adlc.make to use WARNINGS_ARE_ERRORS if it?s defined.
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8144695
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8141543
>>> 
>>> Thanks,
>>> ? Igor
>>> 
>>> 
> 



From david.holmes at oracle.com  Thu Dec 17 00:40:14 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 17 Dec 2015 10:40:14 +1000
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5671D90A.5020208@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
Message-ID: <5672046E.5@oracle.com>

On 17/12/2015 7:35 AM, Erik Joelsson wrote:
> One more thing, where should this fix be pushed? Do you need it urgently
> in hs-rt?

It is urgently needed in both the hs-rt and hs-comp repos as it affects 
nightly testing and JPRT. If Alejandro agrees I suggest pushing to 
jdk9/hs and it can then be pulled down to the team repos.

With regard to the fix ... previously DEBUG_BINARIES was never set in 
spec.gmk and so was never externally introduced into the hotspot build 
this way. So why not simply change the name of the variable so that it 
has no affect on the hotspot part of the build?

Thanks,
David

> /Erik
>
> On 2015-12-16 22:34, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this quick fix for the build issue introduced in Hotspot
>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
>> when building Hotspot fastdebug, you essentially get a slowdebug
>> build. For an explanation of why, see comment in bug. This behavior is
>> of course also a bug, but not something I will address in this quick fix.
>>
>> What happened in JDK-8036003 was that a new configure API for
>> controlling debug symbols was introduced. The two main settings of
>> this new parameter, --with-native-debug-symbols, that we use
>> internally at Oracle are "external" and "zipped". It was important to
>> us that the behavior of these did not change with JDK-8036003, but
>> exactly that did happen, because both of these settings now cause
>> DEBUG_BINARIES=true to be set. This variable has never been set by
>> configure before and because of the above weird behavior in the
>> Hotspot makefiles, we are having problems.
>>
>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
>> or "zipped". It can remain true for "internal" since Oracle never
>> builds it that way, and I understand those that requested this new
>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>> before this anyway, so they should be fine with the broken fastdebug
>> behavior for a while more. I will file a follow up bug to properly
>> clean up this mess, but it will take some more time.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>
>> /Erik
>


From alejandro.murillo at oracle.com  Thu Dec 17 02:14:17 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 16 Dec 2015 19:14:17 -0700
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5672046E.5@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com>
Message-ID: <56721A79.3080205@oracle.com>


On 12/16/2015 5:40 PM, David Holmes wrote:
> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>> One more thing, where should this fix be pushed? Do you need it urgently
>> in hs-rt?
>
> It is urgently needed in both the hs-rt and hs-comp repos as it 
> affects nightly testing and JPRT. If Alejandro agrees I suggest 
> pushing to jdk9/hs and it can then be pulled down to the team repos.
Fine with me.
It will go through PIT this weekend
Alejandro

>
> With regard to the fix ... previously DEBUG_BINARIES was never set in 
> spec.gmk and so was never externally introduced into the hotspot build 
> this way. So why not simply change the name of the variable so that it 
> has no affect on the hotspot part of the build?
>
> Thanks,
> David
>
>> /Erik
>>
>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this quick fix for the build issue introduced in Hotspot
>>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>> build. For an explanation of why, see comment in bug. This behavior is
>>> of course also a bug, but not something I will address in this quick 
>>> fix.
>>>
>>> What happened in JDK-8036003 was that a new configure API for
>>> controlling debug symbols was introduced. The two main settings of
>>> this new parameter, --with-native-debug-symbols, that we use
>>> internally at Oracle are "external" and "zipped". It was important to
>>> us that the behavior of these did not change with JDK-8036003, but
>>> exactly that did happen, because both of these settings now cause
>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>> configure before and because of the above weird behavior in the
>>> Hotspot makefiles, we are having problems.
>>>
>>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
>>> or "zipped". It can remain true for "internal" since Oracle never
>>> builds it that way, and I understand those that requested this new
>>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>>> before this anyway, so they should be fine with the broken fastdebug
>>> behavior for a while more. I will file a follow up bug to properly
>>> clean up this mess, but it will take some more time.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>
>>> /Erik
>>

-- 
Alejandro



From thomas.stuefe at gmail.com  Thu Dec 17 06:49:58 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 17 Dec 2015 07:49:58 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5671D8CB.8080500@oracle.com>
References: <5671D8CB.8080500@oracle.com>
Message-ID: <CAA-vtUxCU4eCbg69M6B4hpsrCpxaisVbLn3f8GBsCYykBtVtvg@mail.gmail.com>

Hi Eric,

short question, are other platforms beside Linux affected or is this
Linux-specific (I saw you said Windows x64 showed no regression)?

Reason I ask is, we just changed the default for AIX to "internal" because
this is the only configuration we support and the build was broken
after  JDK-8036003
(see  https://bugs.openjdk.java.net/browse/JDK-8145560)

Kind Regards, Thomas


On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello,
>
> Please review this quick fix for the build issue introduced in Hotspot by
> JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when
> building Hotspot fastdebug, you essentially get a slowdebug build. For an
> explanation of why, see comment in bug. This behavior is of course also a
> bug, but not something I will address in this quick fix.
>
> What happened in JDK-8036003 was that a new configure API for controlling
> debug symbols was introduced. The two main settings of this new parameter,
> --with-native-debug-symbols, that we use internally at Oracle are
> "external" and "zipped". It was important to us that the behavior of these
> did not change with JDK-8036003, but exactly that did happen, because both
> of these settings now cause DEBUG_BINARIES=true to be set. This variable
> has never been set by configure before and because of the above weird
> behavior in the Hotspot makefiles, we are having problems.
>
> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or
> "zipped". It can remain true for "internal" since Oracle never builds it
> that way, and I understand those that requested this new configure
> parameter were setting DEBUG_BINARIES=true as a workaround before this
> anyway, so they should be fine with the broken fastdebug behavior for a
> while more. I will file a follow up bug to properly clean up this mess, but
> it will take some more time.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>
> /Erik
>


From erik.joelsson at oracle.com  Thu Dec 17 07:54:53 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Dec 2015 08:54:53 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5672046E.5@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com>
Message-ID: <56726A4D.5050600@oracle.com>



On 2015-12-17 01:40, David Holmes wrote:
> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>> One more thing, where should this fix be pushed? Do you need it urgently
>> in hs-rt?
>
> It is urgently needed in both the hs-rt and hs-comp repos as it 
> affects nightly testing and JPRT. If Alejandro agrees I suggest 
> pushing to jdk9/hs and it can then be pulled down to the team repos.
>
Will do.
> With regard to the fix ... previously DEBUG_BINARIES was never set in 
> spec.gmk and so was never externally introduced into the hotspot build 
> this way. So why not simply change the name of the variable so that it 
> has no affect on the hotspot part of the build?
>
Well, we don't want it affecting the jdk part of the build either at 
this point. This patch aims to restore the "external" and "zipped" 
settings to exactly what they were before the patch, as was promised.

We will followup with a more complete fix.

/Erik
> Thanks,
> David
>
>> /Erik
>>
>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>> Hello,
>>>
>>> Please review this quick fix for the build issue introduced in Hotspot
>>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>> build. For an explanation of why, see comment in bug. This behavior is
>>> of course also a bug, but not something I will address in this quick 
>>> fix.
>>>
>>> What happened in JDK-8036003 was that a new configure API for
>>> controlling debug symbols was introduced. The two main settings of
>>> this new parameter, --with-native-debug-symbols, that we use
>>> internally at Oracle are "external" and "zipped". It was important to
>>> us that the behavior of these did not change with JDK-8036003, but
>>> exactly that did happen, because both of these settings now cause
>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>> configure before and because of the above weird behavior in the
>>> Hotspot makefiles, we are having problems.
>>>
>>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
>>> or "zipped". It can remain true for "internal" since Oracle never
>>> builds it that way, and I understand those that requested this new
>>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>>> before this anyway, so they should be fine with the broken fastdebug
>>> behavior for a while more. I will file a follow up bug to properly
>>> clean up this mess, but it will take some more time.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>
>>> /Erik
>>



From erik.joelsson at oracle.com  Thu Dec 17 07:58:32 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Dec 2015 08:58:32 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <CAA-vtUxCU4eCbg69M6B4hpsrCpxaisVbLn3f8GBsCYykBtVtvg@mail.gmail.com>
References: <5671D8CB.8080500@oracle.com>
	<CAA-vtUxCU4eCbg69M6B4hpsrCpxaisVbLn3f8GBsCYykBtVtvg@mail.gmail.com>
Message-ID: <56726B28.7040002@oracle.com>

I only got a bug report for Linux and can't test AIX. A quick look at 
the makefiles for AIX, I think you are probably fine. At least the weird 
construct in the Linux makefiles is not there to mess things up.

/Erik

On 2015-12-17 07:49, Thomas St?fe wrote:
> Hi Eric,
>
> short question, are other platforms beside Linux affected or is this 
> Linux-specific (I saw you said Windows x64 showed no regression)?
>
> Reason I ask is, we just changed the default for AIX to "internal" 
> because this is the only configuration we support and the build was 
> broken after JDK-8036003 (see 
> https://bugs.openjdk.java.net/browse/JDK-8145560)
>
> Kind Regards, Thomas
>
>
> On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson 
> <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>
>     Hello,
>
>     Please review this quick fix for the build issue introduced in
>     Hotspot by JDK-8036003. The short story is that if you set
>     DEBUG_BINARIES=true when building Hotspot fastdebug, you
>     essentially get a slowdebug build. For an explanation of why, see
>     comment in bug. This behavior is of course also a bug, but not
>     something I will address in this quick fix.
>
>     What happened in JDK-8036003 was that a new configure API for
>     controlling debug symbols was introduced. The two main settings of
>     this new parameter, --with-native-debug-symbols, that we use
>     internally at Oracle are "external" and "zipped". It was important
>     to us that the behavior of these did not change with JDK-8036003,
>     but exactly that did happen, because both of these settings now
>     cause DEBUG_BINARIES=true to be set. This variable has never been
>     set by configure before and because of the above weird behavior in
>     the Hotspot makefiles, we are having problems.
>
>     My proposed quick fix is to not set DEBUG_BINARIES=true for
>     "external" or "zipped". It can remain true for "internal" since
>     Oracle never builds it that way, and I understand those that
>     requested this new configure parameter were setting
>     DEBUG_BINARIES=true as a workaround before this anyway, so they
>     should be fine with the broken fastdebug behavior for a while
>     more. I will file a follow up bug to properly clean up this mess,
>     but it will take some more time.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>     Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>     <http://cr.openjdk.java.net/%7Eerikj/8145564/webrev.01/>
>
>     /Erik
>
>



From thomas.stuefe at gmail.com  Thu Dec 17 08:03:56 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 17 Dec 2015 09:03:56 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56726B28.7040002@oracle.com>
References: <5671D8CB.8080500@oracle.com>
	<CAA-vtUxCU4eCbg69M6B4hpsrCpxaisVbLn3f8GBsCYykBtVtvg@mail.gmail.com>
	<56726B28.7040002@oracle.com>
Message-ID: <CAA-vtUyCXk-LQuTh1-4vgfz0KE5-va9xxrxA9Hp5W39Br7RraA@mail.gmail.com>

Thank you, Eric!

On Thu, Dec 17, 2015 at 8:58 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> I only got a bug report for Linux and can't test AIX. A quick look at the
> makefiles for AIX, I think you are probably fine. At least the weird
> construct in the Linux makefiles is not there to mess things up.
>
> /Erik
>
>
> On 2015-12-17 07:49, Thomas St?fe wrote:
>
> Hi Eric,
>
> short question, are other platforms beside Linux affected or is this
> Linux-specific (I saw you said Windows x64 showed no regression)?
>
> Reason I ask is, we just changed the default for AIX to "internal" because
> this is the only configuration we support and the build was broken after  JDK-8036003
> (see   <https://bugs.openjdk.java.net/browse/JDK-8145560>
> https://bugs.openjdk.java.net/browse/JDK-8145560)
>
> Kind Regards, Thomas
>
>
> On Wed, Dec 16, 2015 at 10:34 PM, Erik Joelsson <erik.joelsson at oracle.com>
> wrote:
>
>> Hello,
>>
>> Please review this quick fix for the build issue introduced in Hotspot by
>> JDK-8036003. The short story is that if you set DEBUG_BINARIES=true when
>> building Hotspot fastdebug, you essentially get a slowdebug build. For an
>> explanation of why, see comment in bug. This behavior is of course also a
>> bug, but not something I will address in this quick fix.
>>
>> What happened in JDK-8036003 was that a new configure API for controlling
>> debug symbols was introduced. The two main settings of this new parameter,
>> --with-native-debug-symbols, that we use internally at Oracle are
>> "external" and "zipped". It was important to us that the behavior of these
>> did not change with JDK-8036003, but exactly that did happen, because both
>> of these settings now cause DEBUG_BINARIES=true to be set. This variable
>> has never been set by configure before and because of the above weird
>> behavior in the Hotspot makefiles, we are having problems.
>>
>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external" or
>> "zipped". It can remain true for "internal" since Oracle never builds it
>> that way, and I understand those that requested this new configure
>> parameter were setting DEBUG_BINARIES=true as a workaround before this
>> anyway, so they should be fine with the broken fastdebug behavior for a
>> while more. I will file a follow up bug to properly clean up this mess, but
>> it will take some more time.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>
>> /Erik
>>
>
>
>


From david.holmes at oracle.com  Thu Dec 17 08:08:53 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 17 Dec 2015 18:08:53 +1000
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56726A4D.5050600@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
Message-ID: <56726D95.20103@oracle.com>

On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>
>
> On 2015-12-17 01:40, David Holmes wrote:
>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>> One more thing, where should this fix be pushed? Do you need it urgently
>>> in hs-rt?
>>
>> It is urgently needed in both the hs-rt and hs-comp repos as it
>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>
> Will do.
>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>> spec.gmk and so was never externally introduced into the hotspot build
>> this way. So why not simply change the name of the variable so that it
>> has no affect on the hotspot part of the build?
>>
> Well, we don't want it affecting the jdk part of the build either at
> this point. This patch aims to restore the "external" and "zipped"
> settings to exactly what they were before the patch, as was promised.

I had not inferred from any of this that what was being done via 
NativeCompilation.gmk was in any way a problem. I would have expected 
any problems there to be readily seen before this was reviewed and 
pushed. So I'm a bit confused about this.

I'm tempted to say rollback the whole thing rather than hack at it.

And apologies as I'm just about to go offline for a few hours at least.

David
-----



> We will followup with a more complete fix.
>
> /Erik
>> Thanks,
>> David
>>
>>> /Erik
>>>
>>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> Please review this quick fix for the build issue introduced in Hotspot
>>>> by JDK-8036003. The short story is that if you set DEBUG_BINARIES=true
>>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>>> build. For an explanation of why, see comment in bug. This behavior is
>>>> of course also a bug, but not something I will address in this quick
>>>> fix.
>>>>
>>>> What happened in JDK-8036003 was that a new configure API for
>>>> controlling debug symbols was introduced. The two main settings of
>>>> this new parameter, --with-native-debug-symbols, that we use
>>>> internally at Oracle are "external" and "zipped". It was important to
>>>> us that the behavior of these did not change with JDK-8036003, but
>>>> exactly that did happen, because both of these settings now cause
>>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>>> configure before and because of the above weird behavior in the
>>>> Hotspot makefiles, we are having problems.
>>>>
>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for "external"
>>>> or "zipped". It can remain true for "internal" since Oracle never
>>>> builds it that way, and I understand those that requested this new
>>>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>>>> before this anyway, so they should be fine with the broken fastdebug
>>>> behavior for a while more. I will file a follow up bug to properly
>>>> clean up this mess, but it will take some more time.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>>
>>>> /Erik
>>>
>


From magnus.ihse.bursie at oracle.com  Thu Dec 17 08:18:41 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Dec 2015 09:18:41 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56726D95.20103@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com>
Message-ID: <56726FE1.6020906@oracle.com>

On 2015-12-17 09:08, David Holmes wrote:
> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>
>>
>> On 2015-12-17 01:40, David Holmes wrote:
>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>> One more thing, where should this fix be pushed? Do you need it 
>>>> urgently
>>>> in hs-rt?
>>>
>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>
>> Will do.
>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>> spec.gmk and so was never externally introduced into the hotspot build
>>> this way. So why not simply change the name of the variable so that it
>>> has no affect on the hotspot part of the build?
>>>
>> Well, we don't want it affecting the jdk part of the build either at
>> this point. This patch aims to restore the "external" and "zipped"
>> settings to exactly what they were before the patch, as was promised.
>
> I had not inferred from any of this that what was being done via 
> NativeCompilation.gmk was in any way a problem. I would have expected 
> any problems there to be readily seen before this was reviewed and 
> pushed. So I'm a bit confused about this.

The changes in NativeCompilation.gmk looked perfectly fine. They turned 
out to trigger a bug (or, at the very least, very unsuspected behavior) 
which was deeply hidden in the hotspot linux makefiles, where setting 
DEBUG_BINARIES did indeed enable the -g flag, but also, as a side 
effect, turned fastdebug builds into slowdebug builds. This was not 
something that we could possibly forsee.

>
> I'm tempted to say rollback the whole thing rather than hack at it.

I don't think there is any compelling reason to rollback the whole 
change. The basic idea is sound. However, we do need to work on how to 
handle the debug symbols "under the hood". This deficit has been known 
for a long time to me and Erik but we have not spent any time on it. 
This change brought the problems up to daylight, and I think that's a 
good thing.

I've started working on JDK-8145596, which will provide a proper 
solution to how we handle debug symbols. It is based on JDK-8036003.

/Magnus


>
> And apologies as I'm just about to go offline for a few hours at least.
>
> David
> -----
>
>
>
>> We will followup with a more complete fix.
>>
>> /Erik
>>> Thanks,
>>> David
>>>
>>>> /Erik
>>>>
>>>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this quick fix for the build issue introduced in 
>>>>> Hotspot
>>>>> by JDK-8036003. The short story is that if you set 
>>>>> DEBUG_BINARIES=true
>>>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>>>> build. For an explanation of why, see comment in bug. This 
>>>>> behavior is
>>>>> of course also a bug, but not something I will address in this quick
>>>>> fix.
>>>>>
>>>>> What happened in JDK-8036003 was that a new configure API for
>>>>> controlling debug symbols was introduced. The two main settings of
>>>>> this new parameter, --with-native-debug-symbols, that we use
>>>>> internally at Oracle are "external" and "zipped". It was important to
>>>>> us that the behavior of these did not change with JDK-8036003, but
>>>>> exactly that did happen, because both of these settings now cause
>>>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>>>> configure before and because of the above weird behavior in the
>>>>> Hotspot makefiles, we are having problems.
>>>>>
>>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for 
>>>>> "external"
>>>>> or "zipped". It can remain true for "internal" since Oracle never
>>>>> builds it that way, and I understand those that requested this new
>>>>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>>>>> before this anyway, so they should be fine with the broken fastdebug
>>>>> behavior for a while more. I will file a follow up bug to properly
>>>>> clean up this mess, but it will take some more time.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>>>
>>>>> /Erik
>>>>
>>



From erik.joelsson at oracle.com  Thu Dec 17 09:24:13 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Dec 2015 10:24:13 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56726D95.20103@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com>
Message-ID: <56727F3D.7090600@oracle.com>



On 2015-12-17 09:08, David Holmes wrote:
> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>
>>
>> On 2015-12-17 01:40, David Holmes wrote:
>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>> One more thing, where should this fix be pushed? Do you need it 
>>>> urgently
>>>> in hs-rt?
>>>
>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>
>> Will do.
>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>> spec.gmk and so was never externally introduced into the hotspot build
>>> this way. So why not simply change the name of the variable so that it
>>> has no affect on the hotspot part of the build?
>>>
>> Well, we don't want it affecting the jdk part of the build either at
>> this point. This patch aims to restore the "external" and "zipped"
>> settings to exactly what they were before the patch, as was promised.
>
> I had not inferred from any of this that what was being done via 
> NativeCompilation.gmk was in any way a problem. I would have expected 
> any problems there to be readily seen before this was reviewed and 
> pushed. So I'm a bit confused about this.
>
I didn't follow this particular review closely as Magnus was on it and 
so I had missed the NativeCompilation part. It's true that it is very 
unlikely to be part of the problem described in this bug, but I still 
feel that the safest action at this point is to restore the behavior of 
"external" and "zipped" to what they used to be. Magnus is working on a 
complete fix where debug symbols will be enabled for everything in 
NativeCompilation.
> I'm tempted to say rollback the whole thing rather than hack at it.
>
Rolling back will be much more work for me than submitting this patch. 
There are two changes already that depend on this change. I also don't 
dislike the idea of the new configure parameter.
> And apologies as I'm just about to go offline for a few hours at least.
>
I hope you won't object to me pushing this with just ihse as reviewer. I 
feel this is rather a priority to get fixed.

/Erik


From gary.adams at oracle.com  Thu Dec 17 13:19:17 2015
From: gary.adams at oracle.com (Gary Adams)
Date: Thu, 17 Dec 2015 08:19:17 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <566AE88C.3040701@oracle.com>
References: <566AE88C.3040701@oracle.com>
Message-ID: <5672B655.5030200@oracle.com>

I've revised the original webrev based on some feedback received.
    - reverted white space only changes
    - proper copyrights on the new files
    - some hotspot files contained previously removed code

   Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.

On 12/11/15 10:15, Gary Adams wrote:
> Here's the initial upload of changes that provides support for the ios 
> and android ports
> for the mobile/dev repos. While there have been some preliminary 
> reviews of the code,
> there is still more work required before we will look for more 
> thorough reviews
> and an integration to mobile/jdk9 repos.
>
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
>   Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/
>
>
> Here's a simple configure script to generate a ios-x86_64 build for use
> with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)
>
> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
>
> bash ../../configure \
>     --openjdk-target=x86_64-macos-ios \
>     --with-boot-jdk=$JAVA_HOME \
>     --disable-warnings-as-errors \
>     --disable-headful \
>     --enable-static-build=yes \
>     --with-jvm-variants=minimal1
>
>
> Also, tested with i586-macos-ios target for 32 bit
> with a locally built --with-freetype 2.6.2.



From igor.ignatyev at oracle.com  Thu Dec 17 13:22:28 2015
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 17 Dec 2015 16:22:28 +0300
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work
	for HotSpot build 
In-Reply-To: <D7DD0D77-222E-492A-A131-A4BD9362A217@oracle.com>
References: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
	<5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
	<D7DD0D77-222E-492A-A131-A4BD9362A217@oracle.com>
Message-ID: <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com>


> On Dec 17, 2015, at 2:10 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> On Dec 16, 2015, at 5:54 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>> 
>> as Mikael V correctly pointed out, there is missed $( ) in solaris/adlc.
>> here is the new webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.01/
> 
> I wonder why the value for WARNINGS_ARE_ERRORS isn't obtained from the
> configure-provided variable CFLAGS_WARNINGS_ARE_ERRORS?
> E.g. something like
> 
>  WARNINGS_ARE_ERRORS ?= $(CFLAGS_WARNINGS_ARE_ERRORS)
> 
> There may be a good reason for that, and thinking about it is probably
> better done as a separate RFE.  Doing so might simplify things by
> allowing the assignment to be moved to some higher level common point.
> [The bsd conditionalization on $(COMPILER_WARNINGS_FATAL) might make
> that hard.  Where does that variable come from?  I haven't looked for
> anything similar elsewhere.]
> 
> ------------------------------------------------------------------------------ 
> make/solaris/makefiles/adlc.make 
>  77   WARNINGS_ARE_ERRORS ?= -w -xwe
> 
> I'm pretty sure "-w" is wrong here, and should be removed.
you are right, I made a typo, it was ?+w? before. the new webrev : http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/

>  And it's
> not clear why this assignment should be conditional on the compiler
> version.
it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, excerpt from Chris?s evaluation:

> Since some of the errors are in system headers we can only disable the "+w -errwarn" on SS11 and below.




From magnus.ihse.bursie at oracle.com  Thu Dec 17 13:43:40 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Dec 2015 14:43:40 +0100
Subject: RFR: JDK-8145596 Enable debug symbols for all libraries
Message-ID: <5672BC0C.2070307@oracle.com>

For historical reasons, the FDS (Full Debug Symbols) project only 
enabled debug symbols for a few select libraries, since this was 
difficult to achieve in the old build. Also, the FDS project never 
enabled debug symbols for macosx on the JDK libraries.

With the new build system, debug symbols come for free for all 
libraries, and we actually have to do extra work to keep them out. :-&

We should just stop doing that. It hurts no-one to have proper debug 
information for all libraries, it might come in helpful, and just doing 
it everywhere would simplify build logic.

This is mainly a build change, but I'm cc:ing the component teams just 
in case.

This patch leverages JDK-8036003, but provides a cleaner implementation 
of this logic in the makefiles. Instead of the vague 
ENABLE_DEBUG_SYMBOLS, I have introduced three clearly defined variables:

COMPILE_WITH_DEBUG_SYMBOLS
COPY_DEBUG_SYMBOLS
ZIP_EXTERNAL_DEBUG_SYMBOLS

The various settings of --with-native-debug-symbols turns these 
variables on/off depending on what we want to achieve, and the makefiles 
check these variables to determine what compiler flags to use, whether 
to run objcopy (or similar) and whether to zip the extracted symbols, 
respectively.

A fourth variable (STRIP_DEBUG_SYMBOLS) is needed to fully complement 
this, but the way we handle stripping is complex in it's own right, and 
I've saved that for a separate patch.

Note that this patch intentionally does not affect the Hotspot build 
system. The variables for the hotspot build is kept unchanged. When the 
new build-infra based hotspot build system arrives, the functionality 
introduced in this patch will be automatically used. Until then, I 
prefer not to mess any more than necessary with the hotspot makefiles.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145596
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8145596-fix-native-debug-symbols-properly/webrev.01

/Magnus


From erik.joelsson at oracle.com  Thu Dec 17 13:59:49 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Dec 2015 14:59:49 +0100
Subject: RFR: JDK-8145670: New Solaris devkits are missing gobjcopy
Message-ID: <5672BFD5.5010401@oracle.com>

Hello,

Please review this minor update to the Solaris devkit which adds 
gobjcopy. New devkits have been built using this and are being deployed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8145670
Webrev: http://cr.openjdk.java.net/~erikj/8145670/webrev.01/

/Erik


From magnus.ihse.bursie at oracle.com  Thu Dec 17 14:20:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Dec 2015 15:20:57 +0100
Subject: RFR: JDK-8145670: New Solaris devkits are missing gobjcopy
In-Reply-To: <5672BFD5.5010401@oracle.com>
References: <5672BFD5.5010401@oracle.com>
Message-ID: <5672C4C9.2070203@oracle.com>

On 2015-12-17 14:59, Erik Joelsson wrote:
> Hello,
>
> Please review this minor update to the Solaris devkit which adds 
> gobjcopy. New devkits have been built using this and are being deployed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145670
> Webrev: http://cr.openjdk.java.net/~erikj/8145670/webrev.01/
>
> /Erik
Looks good to me.

/Magnus



From erik.joelsson at oracle.com  Thu Dec 17 14:54:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 17 Dec 2015 15:54:06 +0100
Subject: RFR: JDK-8145596 Enable debug symbols for all libraries
In-Reply-To: <5672BC0C.2070307@oracle.com>
References: <5672BC0C.2070307@oracle.com>
Message-ID: <5672CC8E.5030004@oracle.com>

Looks good to me.

Note that this patch will conflict with the quick fix I did in jdk9/hs, 
so you will need to either wait for my patch, push in a forest that has 
my patch, or make sure the integrator can handle it correctly.

/Erik

On 2015-12-17 14:43, Magnus Ihse Bursie wrote:
> For historical reasons, the FDS (Full Debug Symbols) project only 
> enabled debug symbols for a few select libraries, since this was 
> difficult to achieve in the old build. Also, the FDS project never 
> enabled debug symbols for macosx on the JDK libraries.
>
> With the new build system, debug symbols come for free for all 
> libraries, and we actually have to do extra work to keep them out. :-&
>
> We should just stop doing that. It hurts no-one to have proper debug 
> information for all libraries, it might come in helpful, and just 
> doing it everywhere would simplify build logic.
>
> This is mainly a build change, but I'm cc:ing the component teams just 
> in case.
>
> This patch leverages JDK-8036003, but provides a cleaner 
> implementation of this logic in the makefiles. Instead of the vague 
> ENABLE_DEBUG_SYMBOLS, I have introduced three clearly defined variables:
>
> COMPILE_WITH_DEBUG_SYMBOLS
> COPY_DEBUG_SYMBOLS
> ZIP_EXTERNAL_DEBUG_SYMBOLS
>
> The various settings of --with-native-debug-symbols turns these 
> variables on/off depending on what we want to achieve, and the 
> makefiles check these variables to determine what compiler flags to 
> use, whether to run objcopy (or similar) and whether to zip the 
> extracted symbols, respectively.
>
> A fourth variable (STRIP_DEBUG_SYMBOLS) is needed to fully complement 
> this, but the way we handle stripping is complex in it's own right, 
> and I've saved that for a separate patch.
>
> Note that this patch intentionally does not affect the Hotspot build 
> system. The variables for the hotspot build is kept unchanged. When 
> the new build-infra based hotspot build system arrives, the 
> functionality introduced in this patch will be automatically used. 
> Until then, I prefer not to mess any more than necessary with the 
> hotspot makefiles.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145596
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8145596-fix-native-debug-symbols-properly/webrev.01
>
> /Magnus



From daniel.daugherty at oracle.com  Thu Dec 17 15:58:17 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 17 Dec 2015 08:58:17 -0700
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56727F3D.7090600@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com>
Message-ID: <5672DB99.3070403@oracle.com>

DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only
affects Linux (IIRC). Basically, many years ago someone got tired of
trying to figure out how to get completely debuggable HotSpot build
on Linux and this big hammer was dropped in. I could chase down who
and when, but I don't think that really matters...

When I did FDS a few years back, I was asked to not break the semantics
of DEBUG_BINARIES and so the big hammer was left in. Solaris is my
primary dev platform and DEBUG_BINARIES doesn't work there so I didn't
mind leaving in DEBUG_BINARIES for the Linux folks...

Fast forward to today... I don't think the entire patch needs to be
backed out. Not touching DEBUG_BINARIES via configure is a "good idea"
(TM) because it is such a big hammer. I do recommend trying to deprecate
the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite...

I'm very much looking forward to a cleaner HotSpot build...

Dan


On 12/17/15 2:24 AM, Erik Joelsson wrote:
>
>
> On 2015-12-17 09:08, David Holmes wrote:
>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>
>>>
>>> On 2015-12-17 01:40, David Holmes wrote:
>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>>> One more thing, where should this fix be pushed? Do you need it 
>>>>> urgently
>>>>> in hs-rt?
>>>>
>>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>>
>>> Will do.
>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>>> spec.gmk and so was never externally introduced into the hotspot build
>>>> this way. So why not simply change the name of the variable so that it
>>>> has no affect on the hotspot part of the build?
>>>>
>>> Well, we don't want it affecting the jdk part of the build either at
>>> this point. This patch aims to restore the "external" and "zipped"
>>> settings to exactly what they were before the patch, as was promised.
>>
>> I had not inferred from any of this that what was being done via 
>> NativeCompilation.gmk was in any way a problem. I would have expected 
>> any problems there to be readily seen before this was reviewed and 
>> pushed. So I'm a bit confused about this.
>>
> I didn't follow this particular review closely as Magnus was on it and 
> so I had missed the NativeCompilation part. It's true that it is very 
> unlikely to be part of the problem described in this bug, but I still 
> feel that the safest action at this point is to restore the behavior 
> of "external" and "zipped" to what they used to be. Magnus is working 
> on a complete fix where debug symbols will be enabled for everything 
> in NativeCompilation.
>> I'm tempted to say rollback the whole thing rather than hack at it.
>>
> Rolling back will be much more work for me than submitting this patch. 
> There are two changes already that depend on this change. I also don't 
> dislike the idea of the new configure parameter.
>> And apologies as I'm just about to go offline for a few hours at least.
>>
> I hope you won't object to me pushing this with just ihse as reviewer. 
> I feel this is rather a priority to get fixed.
>
> /Erik



From magnus.ihse.bursie at oracle.com  Thu Dec 17 16:09:27 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Dec 2015 17:09:27 +0100
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <5672B655.5030200@oracle.com>
References: <566AE88C.3040701@oracle.com> <5672B655.5030200@oracle.com>
Message-ID: <5672DE37.1040801@oracle.com>

On 2015-12-17 14:19, Gary Adams wrote:
> I've revised the original webrev based on some feedback received.
>    - reverted white space only changes
>    - proper copyrights on the new files
>    - some hotspot files contained previously removed code
>
>   Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/
>
> Planning to push this first batch tomorrow.

Hi Gary,

There seems to be multiple merge/diff errors in this patch. I'm seeing 
several location where this patch contains changes that is part of 
other, recently pushed change sets. This makes it hard to fully 
understand what changes you are contributing in this patch, to speak 
nothing of the merge problems that are likely to arise if this patch 
were pushed as it is.

I found several other issues as well. I'm sorry I have not been able to 
review this code before. It's a quite massive patch. If you want to 
commit the patch as-is in the mobile/dev forest and then fix my comments 
later before pushing further to mobile/jdk9, it's ok for me. I 
understand that it's tricky to manage a patch of this size. (But I think 
it's better to fix issues now, if you ask me...)

I'll start with something that you and Erik already has discussed: how 
to express tests for logic that is common to ios and macosx. There are 
places in the patch right now that I'm still not happy with.

First of all, I don't think you need to be shy of testing for macosx or 
ios. It's a bit more to write, but it's very clear to the reader, and 
code is read more often than written.

Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. It's 
a bit strange, since it changes the meaning of the OS_ENV (previously it 
was only used to differentiate between cygwin and msys in Windows), but 
I think it could be a reasonable modification. This means that you can 
test if OPENJDK_TARGET_OS_ENV == macosx to cover both the case of macosx 
and ios. Let's just assume that you need to know what you're doing when 
looking at OS_ENV. So this could be an alternative to a lot of "if 
target == macosx or target == ios", if you don't want to type that 
everywhere. For android it seems less of a point of setting OS_ENV. Or 
do you think you could unify android/linux code by this?

Third, I'm not really fond of the TOOLCHAIN_NAME variable. The concept 
is fine, but the variable name is not (I know you didn't invent this).  
We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME sounds like just a 
variant of that. Perhaps resusing the fluffy and unspecified ENV and 
call it TOOLCHAIN_ENV instead? I thought of TOOLCHAIN_VENDOR, but then 
again I'd assume that it'd be "apple", and I think we gain clarity by 
calling Xcode "xcode" and not "apple".

So, to the specifics:
basics.m4: It's not really true that this is build os rather than target 
os. In fact, the whole block is a mix of target and build dependent 
stuff. For instance, xattr depends on build platform but dsymutil 
depends on target os. I suggest you change to target == macosx || ios.

boot-jdk.m4: At the end looks like merge error.

flags.m4: Why delete CPPFLAGS for SYSROOTS?

I think that if you set only LEGACY_EXTRA_CFLAGS and not EXTRA_CFLAGS, 
you will only pass this to Hotspot and not the jdk libraries. But 
honestly, the flag handling is mysterious even to me so I can't say for 
sure. But you might want to double-check this.

BUILD_CC check looks like merge error.

lib-bundled.m4:
Out choice to use system zlib has nothing to do with xcode. It's a 
target os decision.

lib-freetype.m4: OTOH, I'd say that this is indeed a build-os decision :-)

lib-std.m4: This test is only valid for gcc. We are currently not using 
gcc, only clang, for macosx builds. Are you really using gcc for ios 
builds? Otherwise, just leave it as it is.

spec.gmk.in:
Looks like mostly (only?) merge problems here. Or have you added something?

toolchain.m4: See discussion above on TOOLCHAIN_NAME. It looks like 
there are lot of merge errors here.

CompileJavaModules.gmk: Merge errrors galore. I can't really tell what 
are your changes in here.

Images.gmk: Care to elaborate? I don't understand anything.

Main.gmk, JavaCompilation.gmk, Modules.gmk: Merge errors. What is your 
changes in these files? I can't review this.

MakeBase.gmk: just wanted to let you know that I approve of the change 
to build os. :-) I'd appreciate if you could fix the whitespace mistake 
as well (space after the comma is missing).

SetupJavaCompilers.gmk: merge errors? For the GENERATE_JAVA5_BYTECODE, 
please use space after comma. (I know we didn't do that everywhere 
originally, but new code should adhere to the styleguide.)

jdk/make/CompileDemos.gmk: Merge erros. The new android ifdef should 
have proper whitespace (space after comma, the if block indented two 
spaces).

jdk/make/Import.gmk: Looks like the block after the two ifneq 
($(OPENJDK_TARGET_OS), ios) has not been indented. (Or is it a problem 
with the webrev?) Also, the android ifdef is weirdly indented, looks 
like you tried to cram it in with just a single space indent.

jdk/make/gensrc/GensrcCharsetMapping.gmk, 
jdk/make/gensrc/Gensrc-jdk.jdi.gmk, 
jdk/make/gendata/Gendata-java.base.gmk: indentation in if blocks is missing.

jdk/make/launcher/Launcher-java.base.gmk and other launcher make files: 
I thought you and Erik agreed to remove this?

jdk/make/lib/CoreLibraries.gmk: Why remove ARFLAGS? On macosx, we put 
the -framework options in LIBS rather than LDFLAGS (the latter is only 
used to change the behavior of the linker, not determine what to link 
with.)

jdk/make/lib/Awt2dLibraries.gmk:  LIBAWT_EXFILES += initIDs.c 
awt/image/cvutils/img_colors.c should not depend on build os. That's a 
target os decision. The same goes for the LIBSPLASHSCREEN_DIRS changes. 
Also, the whole file seems to be excluded on ios so why these changes at 
all? (And, if that ifdef really is correct, you need to indent the whole 
file as well.) And the same goes for -framework into LIBS not LDFLAGS 
(but only if it's really used on ios).

jdk/make/lib/Lib-java.base.gmk: I'm not sure what's happening here. Can 
you elaborate?

jdk/make/lib/Lib-java.prefs.gmk, jdk/make/lib/Lib-java.instrument.gmk: 
indentation seems wrong, it should be two spaces.

jdk/make/lib/Lib-jdk.jdwp.agent.gmk: Why the LIBDIR stuff?

jdk/make/lib/Lib-jdk.management.gmk, jdk/make/lib/Lib-jdk.sctp.gmk: 
Indentation, indentation...

jdk/make/lib/LibCommon.gmk: Why the strange order in the android case?

jdk/make/lib/SoundLibraries.gmk: indentation (last if block, the rest 
looks fine)

jdk/src/java.base/share/tools/jproject/ios/frameworks/*...: I'm not sure 
this is the correct location. We've never had a "share/tools" directory 
before in a module. They are needed to building the JavaLauncher static 
library on ios, right? I think they should reside with the source code, 
then, in jdk/src/java.base/ios/native/JavaLauncher. (but see below about 
the name).

jdk/src/java.base/ios/native/JavaLauncher: Directories should only use 
lower case. Normally, we prefix libraries with "lib" in the native 
directory, directories without "lib" are supposed to be programs. Now 
this is a static library and we haven't had many of these before, but 
libjli is static (or can be) and still have the lib prefix, so I'd argue 
that thisshould be jdk/src/java.base/ios/native/libjavalauncher instead.

make/lib/JavaLauncher.gmk: For consistency (and to clarify that this is 
libraries, not launchers), it should be named JavaLauncherLibraries.gmk. 
The android part creates a jar. This should not be done in the native 
phase, but in the Java phase. OCLDVK_OUTPUTDIR  is defined but not used. 
It's a bit sad to commit new code with WARNINGS_AS_ERRORS_clang := 
false. :-( Can't you fix the warnings instead?

---

This was what I could find right now. I have not looked at hotspot build 
changes, nor any source code changes.

/Magnus


From bob.vandette at oracle.com  Thu Dec 17 16:48:29 2015
From: bob.vandette at oracle.com (Bob Vandette)
Date: Thu, 17 Dec 2015 11:48:29 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <5672B655.5030200@oracle.com>
References: <566AE88C.3040701@oracle.com> <5672B655.5030200@oracle.com>
Message-ID: <55377E64-D94A-4819-9665-F05A3F972C8F@oracle.com>

1. In make/bsd/makefiles/vm.make

You commented out the libffi logic that we?ll need to Zero iOS ARM.  I guess we could uncomment this
with the push to add this support.

2. hotspot/src/share/vm/runtime/java.cpp

You shouldn?t need this change.  dll_lookup does the right thing
for static builds now.

661 #ifndef STATIC_BUILD

 662   void *lib_handle = os::native_java_library();

 663   func = CAST_TO_FN_PTR(jdk_version_info_fn_t,

 664      os::dll_lookup(lib_handle, "JDK_GetVersionInfo0"));

 665 #else
 666   extern jdk_version_info_fn_t  JDK_GetVersionInfo0;
 667   func = CAST_TO_FN_PTR(jdk_version_info_fn_t,
 668      &JDK_GetVersionInfo0);
 669 #endif


3. jdk/src/java.base/unix/native/libnio/ch/Net.c

Can you check to see that all of these changes are really necessary?

Bob.



> On Dec 17, 2015, at 8:19 AM, Gary Adams <gary.adams at oracle.com> wrote:
> 
> I've revised the original webrev based on some feedback received.
>   - reverted white space only changes
>   - proper copyrights on the new files
>   - some hotspot files contained previously removed code
> 
>  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/
> 
> Planning to push this first batch tomorrow.
> 
> On 12/11/15 10:15, Gary Adams wrote:
>> Here's the initial upload of changes that provides support for the ios and android ports
>> for the mobile/dev repos. While there have been some preliminary reviews of the code,
>> there is still more work required before we will look for more thorough reviews
>> and an integration to mobile/jdk9 repos.
>> 
>>  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
>>  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/
>> 
>> 
>> Here's a simple configure script to generate a ios-x86_64 build for use
>> with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)
>> 
>> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
>> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
>> 
>> bash ../../configure \
>>    --openjdk-target=x86_64-macos-ios \
>>    --with-boot-jdk=$JAVA_HOME \
>>    --disable-warnings-as-errors \
>>    --disable-headful \
>>    --enable-static-build=yes \
>>    --with-jvm-variants=minimal1
>> 
>> 
>> Also, tested with i586-macos-ios target for 32 bit
>> with a locally built --with-freetype 2.6.2.
> 



From kumar.x.srinivasan at oracle.com  Thu Dec 17 17:28:35 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 17 Dec 2015 09:28:35 -0800
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <5671C71A.3060404@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
	<56718440.2070501@oracle.com> <5671C71A.3060404@oracle.com>
Message-ID: <5672F0C3.9010104@oracle.com>

I am good with this change!.

I would like the rest of the component teams to weigh in on the others.

Thanks
Kumar

On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:
> On 2015-12-16 16:33, Kumar Srinivasan wrote:
>> Hello,
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html 
>>
>>
>> You are undefining Windows math.h OVERFLOW, what is it defined
>> as ? With you redefining this, will it cause problems for users of
>> this API, likely to affect JNI apps.
>>
>> Probably need to redefine the pack200 OVERFLOW constant to
>> something else, probably PACK200_OVERFLOW to prevent namespace
>> collisions.
>
> I agree, this is a better solution. I've updated the webrev with this 
> solution (although I used the name PSIZE_OVERFLOW to align with 
> PSIZE_MAX).
>
> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02 
>
>
> /Magnus
>
>
>>
>> Kumar
>>
>> On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>>>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>>>> Hi,
>>>>   I have signed the OCA and emailed a scan according the 
>>>> instructions. I separated the freetype changes into a separate 
>>>> batch as suggested. I have shared the patch files on OneDrive, they 
>>>> are my Public folder. Here?s the link to the folder: 
>>>> https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>>>   The OneDrive folder should contain these 4 files:
>>>>   freetype_JDK9.patch
>>>> vs2015_JDK9.patch
>>>> vs2015_JDK9_hotspot.patch
>>>> vs2015_JDK9_jdk.patch
>>>>   The first two target the root repository, the other two are for 
>>>> hotspot and jdk repositories, respectively.
>>>>   I rebased the patches on JDK9 tip today. I           ran ?make 
>>>> images? and fixed a couple of new errors that have appeared since 
>>>> the previous version. A couple of the changes I had made were also 
>>>> not needed any more.
>>>>   Please have a look!
>>> Hi Timo,
>>>
>>> I'm sorry for the long delay.
>>>
>>> I have created JDK-8145548 for the freetype fix. I'm sponsoring this 
>>> fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>>>
>>> The vs2015 changes are more complicated since they touch multiple 
>>> places in the code. Also, your patch had started bitrotting slightly 
>>> during my long response time. I'm trying to fix it up, and will post 
>>> a review when I have sorted everything out. I will verify that the 
>>> change does not break any of our supported platforms, but I'd like 
>>> you to verify that the patch still works on VS2015. When I publish 
>>> the webrev, there will be a download link to the patch file.
>>>
>>> Also, this patch touches both hotspot code and multiple jdk modules, 
>>> so it will need to be reviewed by other groups as well, besides the 
>>> build team.
>>>
>>> /Magnus
>>>
>>>>             Sent from Mail for Windows 10
>>>>
>>>> From: Magnus Ihse Bursie
>>>> Sent: Friday, October 23, 2015 17:13
>>>> To: timo.kinnunen at gmail.com;build-dev
>>>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015 
>>>> Communityedition
>>>>     On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>>>> Hi,
>>>>>
>>>>> I?ve been going over the Windows build of the whole JDK for a 
>>>>> while with VS 2015 and now I have patches that allow the build to 
>>>>> complete.
>>>>>
>>>>> I?ve made changes in the root repository as well as in hotspot and 
>>>>> jdk repositories. The changes fall broadly in three categories: 
>>>>> enabling the v140 toolchain and improving freetype compilation, 
>>>>> adding casts to where pointers are truncated and miscellaneous 
>>>>> small-scale code changes.
>>>>>
>>>>> The patch to the root repository streamlines handling of freetype 
>>>>> by implementing a default source directory at $HOME/freetype under 
>>>>> Cygwin. It is checked during configure and used for compiling if 
>>>>> ?--with-freetype-src? is not specified. A help message giving the 
>>>>> unpacking command with the correct directory is also included. 
>>>>> This patch is about 90 lines without counting 
>>>>> generated-configure.sh changes.
>>>>>
>>>>> The patches to jdk and hotspot contain native code changes only 
>>>>> and no changes to make-files. These are about 580 and 290 lines, 
>>>>> respectively. All patches are generated with ?hg diff -g?.
>>>>>
>>>>> Would you be willing to incorporate these? How should I proceed 
>>>>> with this?
>>>>   Hi Timo,
>>>>   First of all, I apologize that you have not recieved any response 
>>>> for
>>>> far too long. :-(
>>>>   Thank you for your interest in helping to improve OpenJDK!
>>>>   In general, a patch to allow compilation on           VS 2015 
>>>> Community edition
>>>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>>>> patch and help you work with getting it accepted.
>>>>   My first question to you is: have you signed the OCA? Also, unless
>>>> you've done so already, reading http://openjdk.java.net/contribute/ 
>>>> is a
>>>> good start for starting to contribute to OpenJDK.
>>>>   However, supporting a new compiler, without at the same time 
>>>> breaking an
>>>> older one, can sometimes be tricky business. This means that you might
>>>> need to iterate your patch a number of times, until it's suitable for
>>>> inclusion. I don't want to scare you away, just be realistic up front
>>>> that it might require some more work from your part (and our!). Also,
>>>> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
>>>> SP4, so I know what I'm talking about...)
>>>>    From what you write, I think you should try           to 
>>>> separate the
>>>> freetype-src default directory from the compiler upgrade settings. The
>>>> former might be easier to start with, as it's less likely to be
>>>> disruptive for anything else.
>>>>   Also, at this point, I think it would be helpful for me to be 
>>>> able to
>>>> have an initial look at the patches. You need to be an OpenJDK 
>>>> Author to
>>>> be able to access the OpenJDK infrastructure, so unfortunately that is
>>>> not available to you. :-( For a first peek, the patches can be 
>>>> provided
>>>> just about any way (but attachments to this list is unfortunately not
>>>> allowed). For a final, proper, code review they need to reside on our
>>>> infrastructure, but at that point I can help with fixing that.
>>>>   /Magnus
>>
>



From gary.adams at oracle.com  Thu Dec 17 19:40:06 2015
From: gary.adams at oracle.com (Gary Adams)
Date: Thu, 17 Dec 2015 14:40:06 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <5672DE37.1040801@oracle.com>
References: <566AE88C.3040701@oracle.com> <5672B655.5030200@oracle.com>
	<5672DE37.1040801@oracle.com>
Message-ID: <56730F96.8000803@oracle.com>

On 12/17/15 11:09, Magnus Ihse Bursie wrote:
> On 2015-12-17 14:19, Gary Adams wrote:
>> I've revised the original webrev based on some feedback received.
>>    - reverted white space only changes
>>    - proper copyrights on the new files
>>    - some hotspot files contained previously removed code
>>
>>   Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/
>>
>> Planning to push this first batch tomorrow.
>
> Hi Gary,
>
> There seems to be multiple merge/diff errors in this patch. I'm seeing 
> several location where this patch contains changes that is part of 
> other, recently pushed change sets. This makes it hard to fully 
> understand what changes you are contributing in this patch, to speak 
> nothing of the merge problems that are likely to arise if this patch 
> were pushed as it is.
My bad. In getting the workspace to build I had diff'ed the files 
against the latest jdk9-dev sources
and pulled in changes that were ahead of the recently cloned mobile/dev 
repos.
The next merge will bring in those updates. mobile/dev is cloned from 
jdk9-b94 and latest jdk9/dev
is at jdk9-9+b96.

>
> I found several other issues as well. I'm sorry I have not been able 
> to review this code before. It's a quite massive patch. If you want to 
> commit the patch as-is in the mobile/dev forest and then fix my 
> comments later before pushing further to mobile/jdk9, it's ok for me. 
> I understand that it's tricky to manage a patch of this size. (But I 
> think it's better to fix issues now, if you ask me...)
I'd like to do any simple cleanups before the initial push. We know 
there will be more pushes coming, so I'm not opposed to partial solutions
being put back at this time.
>
> I'll start with something that you and Erik already has discussed: how 
> to express tests for logic that is common to ios and macosx. There are 
> places in the patch right now that I'm still not happy with.
>
> First of all, I don't think you need to be shy of testing for macosx 
> or ios. It's a bit more to write, but it's very clear to the reader, 
> and code is read more often than written.
I am uncomfortable with all the places platform specific changes need to 
be made.
There isn't an easy way to express platform A is like platform B with 
the following
differences.

>
> Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. 
> It's a bit strange, since it changes the meaning of the OS_ENV 
> (previously it was only used to differentiate between cygwin and msys 
> in Windows), but I think it could be a reasonable modification. This 
> means that you can test if OPENJDK_TARGET_OS_ENV == macosx to cover 
> both the case of macosx and ios. Let's just assume that you need to 
> know what you're doing when looking at OS_ENV. So this could be an 
> alternative to a lot of "if target == macosx or target == ios", if you 
> don't want to type that everywhere. For android it seems less of a 
> point of setting OS_ENV. Or do you think you could unify android/linux 
> code by this?
I thought previously we were told not to use OPENJDK_TARGET_OS_ENV and I 
asked at that time for "documentation".
>
> Third, I'm not really fond of the TOOLCHAIN_NAME variable. The concept 
> is fine, but the variable name is not (I know you didn't invent 
> this).  We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME sounds 
> like just a variant of that. Perhaps resusing the fluffy and 
> unspecified ENV and call it TOOLCHAIN_ENV instead? I thought of 
> TOOLCHAIN_VENDOR, but then again I'd assume that it'd be "apple", and 
> I think we gain clarity by calling Xcode "xcode" and not "apple".

I'd be glad to use a different name or value for the flag, just let me know.

This is a change we could defer til the mobile/dev to mobile/jdk9 
integration.
At this time I'm mostly interested to know that we've used it in the 
right places.
e.g. prior to discovery of boot-jdk and xcode we used BUILD_OS macosx, 
after
that we use toolchain xcode check, for native flags and libraries we 
still check TARGET_OS
for macosx or ios when not xcode specific.
>
> So, to the specifics:
> basics.m4: It's not really true that this is build os rather than 
> target os. In fact, the whole block is a mix of target and build 
> dependent stuff. For instance, xattr depends on build platform but 
> dsymutil depends on target os. I suggest you change to target == 
> macosx || ios.
Will do.
>
> boot-jdk.m4: At the end looks like merge error.
Will fix.
We had the big java fix in ejdk8u and it recently cam back in jdk9
recent builds.

>
> flags.m4: Why delete CPPFLAGS for SYSROOTS?
SYSROOT does not belong on CPPFLAGS.
We needed the fix for the ios builds.

>
> I think that if you set only LEGACY_EXTRA_CFLAGS and not EXTRA_CFLAGS, 
> you will only pass this to Hotspot and not the jdk libraries. But 
> honestly, the flag handling is mysterious even to me so I can't say 
> for sure. But you might want to double-check this.
Not sure about this comment. We have working ios and android builds from 
the flags
that are currently being set. Several fingers over several years have 
touched these
files, so the original intent may not be clear.
>
> BUILD_CC check looks like merge error.
Will fix.

>
> lib-bundled.m4:
> Out choice to use system zlib has nothing to do with xcode. It's a 
> target os decision.
Will fix.
>
> lib-freetype.m4: OTOH, I'd say that this is indeed a build-os decision 
> :-)
Will fix.
>
> lib-std.m4: This test is only valid for gcc. We are currently not 
> using gcc, only clang, for macosx builds. Are you really using gcc for 
> ios builds? Otherwise, just leave it as it is.
Only changed it because it was flagged as
should be changed if we switched from xcode clang to
gcc based toolchain in the future.

Will revert/fix.

>
> spec.gmk.in:
> Looks like mostly (only?) merge problems here. Or have you added 
> something?
Will roll back the sjava related changes, but keep
the ":=" fix on mac osx version.

>
> toolchain.m4: See discussion above on TOOLCHAIN_NAME. It looks like 
> there are lot of merge errors here.

Will recheck.
>
> CompileJavaModules.gmk: Merge errrors galore. I can't really tell what 
> are your changes in here.
Will fix
>
> Images.gmk: Care to elaborate? I don't understand anything.
ios builds do not build any command line executables.
It is the wrong target to build a dependency when the jlmage is
the result of the recipe.

  # Use this file inside the image as target for make rule
-JIMAGE_TARGET_FILE := bin/java$(EXE_SUFFIX)
+JIMAGE_TARGET_FILE := lib/modules/bootmodules.jimage

>
> Main.gmk, JavaCompilation.gmk, Modules.gmk: Merge errors. What is your 
> changes in these files? I can't review this.
>
> MakeBase.gmk: just wanted to let you know that I approve of the change 
> to build os. :-) I'd appreciate if you could fix the whitespace 
> mistake as well (space after the comma is missing).
Fixed.
(Sure would be nice if there was tool to do the makefile whitespace 
checking.)

>
> SetupJavaCompilers.gmk: merge errors? For the GENERATE_JAVA5_BYTECODE, 
> please use space after comma. (I know we didn't do that everywhere 
> originally, but new code should adhere to the styleguide.)
Fixed.
I assume it's OK to fix the other missing space-after-comma.

>
> jdk/make/CompileDemos.gmk: Merge erros. The new android ifdef should 
> have proper whitespace (space after comma, the if block indented two 
> spaces).
Fixed.
>
> jdk/make/Import.gmk: Looks like the block after the two ifneq 
> ($(OPENJDK_TARGET_OS), ios) has not been indented. (Or is it a problem 
> with the webrev?) Also, the android ifdef is weirdly indented, looks 
> like you tried to cram it in with just a single space indent.
Fixed.
>
> jdk/make/gensrc/GensrcCharsetMapping.gmk, 
> jdk/make/gensrc/Gensrc-jdk.jdi.gmk, 
> jdk/make/gendata/Gendata-java.base.gmk: indentation in if blocks is 
> missing.
Fixed.
>
> jdk/make/launcher/Launcher-java.base.gmk and other launcher make 
> files: I thought you and Erik agreed to remove this?
The addition of new configure options will be handled in subsequent pushes.

This is one of the places where new features need to be developed
to be ready for a mobile/jdk9 push, but should not block getting basic ios
functionality into the open repos.

>
> jdk/make/lib/CoreLibraries.gmk: Why remove ARFLAGS? On macosx, we put 
> the -framework options in LIBS rather than LDFLAGS (the latter is only 
> used to change the behavior of the linker, not determine what to link 
> with.)
We ran into conflicts with the use of ARFLAGS  and AR_OUTPUT_OPTION in 
NativeCompilation.gmk.
It does not appear that both could be set and build properly.

     # Generating a static library, ie object file archive.
     $$($1_TARGET): $$($1_EXPECTED_OBJS) $$($1_RES) $$($1_VARDEPS_FILE)
     $(ECHO) $(LOG_INFO) "Archiving $$($1_STATIC_LIBRARY)"
     $(call LogFailures, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_link.log, 
$$($1_SAFE_NAME)_link, \
         $$($1_AR) $$($1_ARFLAGS) $(AR_OUT_OPTION)$$($1_TARGET) 
$$($1_EXPECTED_OBJS) \
             $$($1_RES))

There are also ARFLAGS references in hotspot/bsd/makefiles that may need 
unification
when the hotspot new build is set up.

>
> jdk/make/lib/Awt2dLibraries.gmk:  LIBAWT_EXFILES += initIDs.c 
> awt/image/cvutils/img_colors.c should not depend on build os. That's a 
> target os decision. The same goes for the LIBSPLASHSCREEN_DIRS 
> changes. Also, the whole file seems to be excluded on ios so why these 
> changes at all? (And, if that ifdef really is correct, you need to 
> indent the whole file as well.) And the same goes for -framework into 
> LIBS not LDFLAGS (but only if it's really used on ios).
Unfortunately our android developer retired, so I'm not totally up to 
date on the selective files being excluded.
I'm assuming they did not compile on the target platform and were simply 
excluded. The mobile platforms
are intend as headless compact2 only.  I'm pretty sure the whole file 
ios exclusion was done after some
number of attempts to get the library to compile.

This is a another place we expect to fix later with a proper working of 
headless builds.

I'll fix the LIBS reference to framework before the initial push.

>
> jdk/make/lib/Lib-java.base.gmk: I'm not sure what's happening here. 
> Can you elaborate?
On ios there is no libjli. The app container is not allowed to fork/exec 
new processes.
That is why a separate JavaLauncher interface is provided to ease the 
startup of a VM in the current process.

The other logic in the selection of symbol file to use is based on the 
VM actually
being built. e.g. minimal, client, server vm. The static macosx build 
only supported
server vm. We deplot mobile with minimal vm, but still maintain client 
vm for testing purposes.


>
> jdk/make/lib/Lib-java.prefs.gmk, jdk/make/lib/Lib-java.instrument.gmk: 
> indentation seems wrong, it should be two spaces.
Fixed.
>
> jdk/make/lib/Lib-jdk.jdwp.agent.gmk: Why the LIBDIR stuff?
There is still a remnant of arch specific directories in the build system.

Here's the relevant setting from platform.m4

   # This is the name of the cpu (but using i386 and amd64 instead of
   # x86 and x86_64, respectively), preceeded by a /, to be used when
   # locating libraries. On macosx, it's empty, though.
OPENJDK_TARGET_CPU_LIBDIR="/$OPENJDK_TARGET_CPU_LEGACY_LIB"
   if test "x$OPENJDK_TARGET_OS" = xmacosx; then
     OPENJDK_TARGET_CPU_LIBDIR=""
   fi
   AC_SUBST(OPENJDK_TARGET_CPU_LIBDIR)

Ideally, the build system would allow us to cross compile
multiple targets in a single pass.
     macosx build system
         ios-x86
         ios-x86_64
         ios-arm
         ios-aarch64

     then roll up universal static libraries with lipo.

Since we do not have that capability we build 4 separate bundles
and our users are combining 4 platform bundles and rolling their own
universal libraries.
>
> jdk/make/lib/Lib-jdk.management.gmk, jdk/make/lib/Lib-jdk.sctp.gmk: 
> Indentation, indentation...
Fixed.
(Wish there was a tool that could fix the whitespace.)
>
> jdk/make/lib/LibCommon.gmk: Why the strange order in the android case?
I read the android diff to mean use the "linux" native code when 
TARGET_OS is android.

+ifeq ($(OPENJDK_TARGET_OS), android)
+FindSrcDirsForLib = \
+  $(call uniq, $(wildcard \
+      $(JDK_TOPDIR)/src/$(strip $1)/*linux*/native/lib$(strip $2) \
+      $(JDK_TOPDIR)/src/$(strip $1)/$(OPENJDK_TARGET_OS_TYPE)/native/lib$(strip $2) \
+      $(JDK_TOPDIR)/src/$(strip $1)/share/native/lib$(strip $2)))
...
+else
+FindSrcDirsForLib = \
+  $(call uniq, $(wildcard \
+      $(JDK_TOPDIR)/src/$(strip $1)/$*(OPENJDK_TARGET_OS)*/native/lib$(strip $2) \
+      $(JDK_TOPDIR)/src/$(strip $1)/$(OPENJDK_TARGET_OS_TYPE)/native/lib$(strip $2) \
+      $(JDK_TOPDIR)/src/$(strip $1)/share/native/lib$(strip $2)))
+endif

Will fix the indents there.

>
> jdk/make/lib/SoundLibraries.gmk: indentation (last if block, the rest 
> looks fine)
Fixed.
>
> jdk/src/java.base/share/tools/jproject/ios/frameworks/*...: I'm not 
> sure this is the correct location. We've never had a "share/tools" 
> directory before in a module. They are needed to building the 
> JavaLauncher static library on ios, right? I think they should reside 
> with the source code, then, in 
> jdk/src/java.base/ios/native/JavaLauncher. (but see below about the 
> name).
Will fix. We just recently stopped using xcodebuild to create a proper 
framework.

>
> jdk/src/java.base/ios/native/JavaLauncher: Directories should only use 
> lower case. Normally, we prefix libraries with "lib" in the native 
> directory, directories without "lib" are supposed to be programs. Now 
> this is a static library and we haven't had many of these before, but 
> libjli is static (or can be) and still have the lib prefix, so I'd 
> argue that thisshould be jdk/src/java.base/ios/native/libjavalauncher 
> instead.
Not just a library.
Our deliverable artifact is a framework on ios.

The include file and static library are packaged so they can drop
into an Xcode project and all the proper connections are made.
This is the native component that will launch the VM in the current process.

>
> make/lib/JavaLauncher.gmk: For consistency (and to clarify that this 
> is libraries, not launchers), it should be named 
> JavaLauncherLibraries.gmk. The android part creates a jar. This should 
> not be done in the native phase, but in the Java phase. 
> OCLDVK_OUTPUTDIR  is defined but not used. It's a bit sad to commit 
> new code with WARNINGS_AS_ERRORS_clang := false. :-( Can't you fix the 
> warnings instead?
Even though we compile a Java 5 byte code jar file, it will be processed 
via dex before it is actually linked into an android executable.
This is the native side that will launch a Java VM within the current 
process.

We called in JavaLauncher because it was a replacement for libjli.

I'll investigate the unused OCLDVK_OUTPUTDIR and the WARNINGS_AS_ERRORS.
There is probably some shared linux code that does not compile cleanly 
with the android toolchain.
>
> ---
>
> This was what I could find right now. I have not looked at hotspot 
> build changes, nor any source code changes.

Thanks I appreciate all these comments.
My hope is that we will have much smaller reviewable changesets
going forward.
>
> /Magnus



From kim.barrett at oracle.com  Thu Dec 17 20:30:17 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 17 Dec 2015 15:30:17 -0500
Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work
	for HotSpot build 
In-Reply-To: <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com>
References: <A8867D3F-EF43-4021-87E7-DCEF1FCCB950@oracle.com>
	<5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com>
	<D7DD0D77-222E-492A-A131-A4BD9362A217@oracle.com>
	<5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com>
Message-ID: <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com>

On Dec 17, 2015, at 8:22 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> 
>> On Dec 17, 2015, at 2:10 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> make/solaris/makefiles/adlc.make 
>> 77   WARNINGS_ARE_ERRORS ?= -w -xwe
>> 
>> I'm pretty sure "-w" is wrong here, and should be removed.
> you are right, I made a typo, it was ?+w? before. the new webrev : http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/
> 
>> And it's
>> not clear why this assignment should be conditional on the compiler
>> version.
> it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, excerpt from Chris?s evaluation:
> 
>> Since some of the errors are in system headers we can only disable the "+w -errwarn" on SS11 and below.

"+w" has nothing to do with warnings being errors; it just turns on
more warnings.  So it shouldn't be in WARNINGS_ARE_ERRORS.

CFLAGS_WARN is (according to various comments) supposed to hold
options to enable/disable warnings, so "+w" there was reasonable,
while -errwarn should not have been there by that definition.

The conditionalization disables additional warnings and "warnings are
errors" for older compilers that I think we're no longer using for
jdk9.  Are we allowed to retire support for such?

The conditionalization may only be needed for "+w", though without
testing on a no longer officially supported version of the compiler
that would be hard to prove.



From david.holmes at oracle.com  Thu Dec 17 21:24:43 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Dec 2015 07:24:43 +1000
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56726FE1.6020906@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com> <56726FE1.6020906@oracle.com>
Message-ID: <5673281B.8000800@oracle.com>

On 17/12/2015 6:18 PM, Magnus Ihse Bursie wrote:
> On 2015-12-17 09:08, David Holmes wrote:
>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>
>>>
>>> On 2015-12-17 01:40, David Holmes wrote:
>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>>> One more thing, where should this fix be pushed? Do you need it
>>>>> urgently
>>>>> in hs-rt?
>>>>
>>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>>
>>> Will do.
>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>>> spec.gmk and so was never externally introduced into the hotspot build
>>>> this way. So why not simply change the name of the variable so that it
>>>> has no affect on the hotspot part of the build?
>>>>
>>> Well, we don't want it affecting the jdk part of the build either at
>>> this point. This patch aims to restore the "external" and "zipped"
>>> settings to exactly what they were before the patch, as was promised.
>>
>> I had not inferred from any of this that what was being done via
>> NativeCompilation.gmk was in any way a problem. I would have expected
>> any problems there to be readily seen before this was reviewed and
>> pushed. So I'm a bit confused about this.
>
> The changes in NativeCompilation.gmk looked perfectly fine. They turned
> out to trigger a bug (or, at the very least, very unsuspected behavior)
> which was deeply hidden in the hotspot linux makefiles, where setting
> DEBUG_BINARIES did indeed enable the -g flag, but also, as a side
> effect, turned fastdebug builds into slowdebug builds. This was not
> something that we could possibly forsee.

That was my understanding too - that this was simply a side-effect on 
hotspot, hence my suggestion to rename the variable. But Erik then said 
this was also not working correctly for the JDK side - which means the 
problem is far worse.

David
-----


>>
>> I'm tempted to say rollback the whole thing rather than hack at it.
>
> I don't think there is any compelling reason to rollback the whole
> change. The basic idea is sound. However, we do need to work on how to
> handle the debug symbols "under the hood". This deficit has been known
> for a long time to me and Erik but we have not spent any time on it.
> This change brought the problems up to daylight, and I think that's a
> good thing.
>
> I've started working on JDK-8145596, which will provide a proper
> solution to how we handle debug symbols. It is based on JDK-8036003.
>
> /Magnus
>
>
>>
>> And apologies as I'm just about to go offline for a few hours at least.
>>
>> David
>> -----
>>
>>
>>
>>> We will followup with a more complete fix.
>>>
>>> /Erik
>>>> Thanks,
>>>> David
>>>>
>>>>> /Erik
>>>>>
>>>>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this quick fix for the build issue introduced in
>>>>>> Hotspot
>>>>>> by JDK-8036003. The short story is that if you set
>>>>>> DEBUG_BINARIES=true
>>>>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>>>>> build. For an explanation of why, see comment in bug. This
>>>>>> behavior is
>>>>>> of course also a bug, but not something I will address in this quick
>>>>>> fix.
>>>>>>
>>>>>> What happened in JDK-8036003 was that a new configure API for
>>>>>> controlling debug symbols was introduced. The two main settings of
>>>>>> this new parameter, --with-native-debug-symbols, that we use
>>>>>> internally at Oracle are "external" and "zipped". It was important to
>>>>>> us that the behavior of these did not change with JDK-8036003, but
>>>>>> exactly that did happen, because both of these settings now cause
>>>>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>>>>> configure before and because of the above weird behavior in the
>>>>>> Hotspot makefiles, we are having problems.
>>>>>>
>>>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for
>>>>>> "external"
>>>>>> or "zipped". It can remain true for "internal" since Oracle never
>>>>>> builds it that way, and I understand those that requested this new
>>>>>> configure parameter were setting DEBUG_BINARIES=true as a workaround
>>>>>> before this anyway, so they should be fine with the broken fastdebug
>>>>>> behavior for a while more. I will file a follow up bug to properly
>>>>>> clean up this mess, but it will take some more time.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>>>>
>>>>>> /Erik
>>>>>
>>>
>


From david.holmes at oracle.com  Thu Dec 17 21:32:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Dec 2015 07:32:00 +1000
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <56727F3D.7090600@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com>
Message-ID: <567329D0.8010303@oracle.com>

On 17/12/2015 7:24 PM, Erik Joelsson wrote:
> On 2015-12-17 09:08, David Holmes wrote:
>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>
>>>
>>> On 2015-12-17 01:40, David Holmes wrote:
>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>>> One more thing, where should this fix be pushed? Do you need it
>>>>> urgently
>>>>> in hs-rt?
>>>>
>>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>>
>>> Will do.
>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>>> spec.gmk and so was never externally introduced into the hotspot build
>>>> this way. So why not simply change the name of the variable so that it
>>>> has no affect on the hotspot part of the build?
>>>>
>>> Well, we don't want it affecting the jdk part of the build either at
>>> this point. This patch aims to restore the "external" and "zipped"
>>> settings to exactly what they were before the patch, as was promised.
>>
>> I had not inferred from any of this that what was being done via
>> NativeCompilation.gmk was in any way a problem. I would have expected
>> any problems there to be readily seen before this was reviewed and
>> pushed. So I'm a bit confused about this.
>>
> I didn't follow this particular review closely as Magnus was on it and
> so I had missed the NativeCompilation part. It's true that it is very
> unlikely to be part of the problem described in this bug, but I still
> feel that the safest action at this point is to restore the behavior of
> "external" and "zipped" to what they used to be.

My concern is recognizing that these adjustments do in fact restore the 
old behaviour. From the hotspot side it seemed cleaner to avoid the 
breakage by using a different variable name.

> Magnus is working on a
> complete fix where debug symbols will be enabled for everything in
> NativeCompilation.
>> I'm tempted to say rollback the whole thing rather than hack at it.
>>
> Rolling back will be much more work for me than submitting this patch.
> There are two changes already that depend on this change. I also don't
> dislike the idea of the new configure parameter.

Rolling back the new configure parameters and then reinstating them 
again would also not win us any friends as it would be very disruptive. 
As others have noted the way we introduce and remove configure 
parameters needs to be looked at. I was mainly concerned that the 
out-of-the-box default behaviour was unchanged.

>> And apologies as I'm just about to go offline for a few hours at least.
>>
> I hope you won't object to me pushing this with just ihse as reviewer. I
> feel this is rather a priority to get fixed.

Sure. I had verified that DEBUG_BINARIES is only ever tested against 
"true" so setting it to false should be as effective as not setting it 
at all.

I'll follow up separately to see where this was pushed and whether we 
need to pull it into anywhere else urgently.

Thanks,
David

> /Erik


From david.holmes at oracle.com  Thu Dec 17 21:33:41 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Dec 2015 07:33:41 +1000
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5672DB99.3070403@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com>
	<5672DB99.3070403@oracle.com>
Message-ID: <56732A35.5030505@oracle.com>

On 18/12/2015 1:58 AM, Daniel D. Daugherty wrote:
> DEBUG_BINARIES is one of those "hidden" HotSpot big hammers that only
> affects Linux (IIRC). Basically, many years ago someone got tired of
> trying to figure out how to get completely debuggable HotSpot build
> on Linux and this big hammer was dropped in. I could chase down who
> and when, but I don't think that really matters...

Unfortunately it also got "cloned" into BSD and AIX ports.

Thanks for the additional info.

David
-----

> When I did FDS a few years back, I was asked to not break the semantics
> of DEBUG_BINARIES and so the big hammer was left in. Solaris is my
> primary dev platform and DEBUG_BINARIES doesn't work there so I didn't
> mind leaving in DEBUG_BINARIES for the Linux folks...
>
> Fast forward to today... I don't think the entire patch needs to be
> backed out. Not touching DEBUG_BINARIES via configure is a "good idea"
> (TM) because it is such a big hammer. I do recommend trying to deprecate
> the DEBUG_BINARIES setting in the big HotSpot Makefile rewrite...
>
> I'm very much looking forward to a cleaner HotSpot build...
>
> Dan
>
>
> On 12/17/15 2:24 AM, Erik Joelsson wrote:
>>
>>
>> On 2015-12-17 09:08, David Holmes wrote:
>>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>>
>>>>
>>>> On 2015-12-17 01:40, David Holmes wrote:
>>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>>>> One more thing, where should this fix be pushed? Do you need it
>>>>>> urgently
>>>>>> in hs-rt?
>>>>>
>>>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>>>
>>>> Will do.
>>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>>>> spec.gmk and so was never externally introduced into the hotspot build
>>>>> this way. So why not simply change the name of the variable so that it
>>>>> has no affect on the hotspot part of the build?
>>>>>
>>>> Well, we don't want it affecting the jdk part of the build either at
>>>> this point. This patch aims to restore the "external" and "zipped"
>>>> settings to exactly what they were before the patch, as was promised.
>>>
>>> I had not inferred from any of this that what was being done via
>>> NativeCompilation.gmk was in any way a problem. I would have expected
>>> any problems there to be readily seen before this was reviewed and
>>> pushed. So I'm a bit confused about this.
>>>
>> I didn't follow this particular review closely as Magnus was on it and
>> so I had missed the NativeCompilation part. It's true that it is very
>> unlikely to be part of the problem described in this bug, but I still
>> feel that the safest action at this point is to restore the behavior
>> of "external" and "zipped" to what they used to be. Magnus is working
>> on a complete fix where debug symbols will be enabled for everything
>> in NativeCompilation.
>>> I'm tempted to say rollback the whole thing rather than hack at it.
>>>
>> Rolling back will be much more work for me than submitting this patch.
>> There are two changes already that depend on this change. I also don't
>> dislike the idea of the new configure parameter.
>>> And apologies as I'm just about to go offline for a few hours at least.
>>>
>> I hope you won't object to me pushing this with just ihse as reviewer.
>> I feel this is rather a priority to get fixed.
>>
>> /Erik
>


From david.holmes at oracle.com  Fri Dec 18 04:11:08 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Dec 2015 14:11:08 +1000
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <5672F0C3.9010104@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
	<56718440.2070501@oracle.com> <5671C71A.3060404@oracle.com>
	<5672F0C3.9010104@oracle.com>
Message-ID: <5673875C.2000803@oracle.com>

On 18/12/2015 3:28 AM, Kumar Srinivasan wrote:
> I am good with this change!.
>
> I would like the rest of the component teams to weigh in on the others.

This needs to be sent to all the affected component teams, or even 
better split into three pieces: build, hotspot and JDK libs, and then sent.

Hotspot changes looked okay to me - though the need for casts in various 
places was unpleasant - we may want neater ways to deal with that.

Thanks,
David

> Thanks
> Kumar
>
> On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:
>> On 2015-12-16 16:33, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html
>>>
>>>
>>> You are undefining Windows math.h OVERFLOW, what is it defined
>>> as ? With you redefining this, will it cause problems for users of
>>> this API, likely to affect JNI apps.
>>>
>>> Probably need to redefine the pack200 OVERFLOW constant to
>>> something else, probably PACK200_OVERFLOW to prevent namespace
>>> collisions.
>>
>> I agree, this is a better solution. I've updated the webrev with this
>> solution (although I used the name PSIZE_OVERFLOW to align with
>> PSIZE_MAX).
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02
>>
>>
>> /Magnus
>>
>>
>>>
>>> Kumar
>>>
>>> On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>>>>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>>>>> Hi,
>>>>>   I have signed the OCA and emailed a scan according the
>>>>> instructions. I separated the freetype changes into a separate
>>>>> batch as suggested. I have shared the patch files on OneDrive, they
>>>>> are my Public folder. Here?s the link to the folder:
>>>>> https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>>>>   The OneDrive folder should contain these 4 files:
>>>>>   freetype_JDK9.patch
>>>>> vs2015_JDK9.patch
>>>>> vs2015_JDK9_hotspot.patch
>>>>> vs2015_JDK9_jdk.patch
>>>>>   The first two target the root repository, the other two are for
>>>>> hotspot and jdk repositories, respectively.
>>>>>   I rebased the patches on JDK9 tip today. I           ran ?make
>>>>> images? and fixed a couple of new errors that have appeared since
>>>>> the previous version. A couple of the changes I had made were also
>>>>> not needed any more.
>>>>>   Please have a look!
>>>> Hi Timo,
>>>>
>>>> I'm sorry for the long delay.
>>>>
>>>> I have created JDK-8145548 for the freetype fix. I'm sponsoring this
>>>> fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>>>>
>>>> The vs2015 changes are more complicated since they touch multiple
>>>> places in the code. Also, your patch had started bitrotting slightly
>>>> during my long response time. I'm trying to fix it up, and will post
>>>> a review when I have sorted everything out. I will verify that the
>>>> change does not break any of our supported platforms, but I'd like
>>>> you to verify that the patch still works on VS2015. When I publish
>>>> the webrev, there will be a download link to the patch file.
>>>>
>>>> Also, this patch touches both hotspot code and multiple jdk modules,
>>>> so it will need to be reviewed by other groups as well, besides the
>>>> build team.
>>>>
>>>> /Magnus
>>>>
>>>>>             Sent from Mail for Windows 10
>>>>>
>>>>> From: Magnus Ihse Bursie
>>>>> Sent: Friday, October 23, 2015 17:13
>>>>> To: timo.kinnunen at gmail.com;build-dev
>>>>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015
>>>>> Communityedition
>>>>>     On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I?ve been going over the Windows build of the whole JDK for a
>>>>>> while with VS 2015 and now I have patches that allow the build to
>>>>>> complete.
>>>>>>
>>>>>> I?ve made changes in the root repository as well as in hotspot and
>>>>>> jdk repositories. The changes fall broadly in three categories:
>>>>>> enabling the v140 toolchain and improving freetype compilation,
>>>>>> adding casts to where pointers are truncated and miscellaneous
>>>>>> small-scale code changes.
>>>>>>
>>>>>> The patch to the root repository streamlines handling of freetype
>>>>>> by implementing a default source directory at $HOME/freetype under
>>>>>> Cygwin. It is checked during configure and used for compiling if
>>>>>> ?--with-freetype-src? is not specified. A help message giving the
>>>>>> unpacking command with the correct directory is also included.
>>>>>> This patch is about 90 lines without counting
>>>>>> generated-configure.sh changes.
>>>>>>
>>>>>> The patches to jdk and hotspot contain native code changes only
>>>>>> and no changes to make-files. These are about 580 and 290 lines,
>>>>>> respectively. All patches are generated with ?hg diff -g?.
>>>>>>
>>>>>> Would you be willing to incorporate these? How should I proceed
>>>>>> with this?
>>>>>   Hi Timo,
>>>>>   First of all, I apologize that you have not recieved any response
>>>>> for
>>>>> far too long. :-(
>>>>>   Thank you for your interest in helping to improve OpenJDK!
>>>>>   In general, a patch to allow compilation on           VS 2015
>>>>> Community edition
>>>>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>>>>> patch and help you work with getting it accepted.
>>>>>   My first question to you is: have you signed the OCA? Also, unless
>>>>> you've done so already, reading http://openjdk.java.net/contribute/
>>>>> is a
>>>>> good start for starting to contribute to OpenJDK.
>>>>>   However, supporting a new compiler, without at the same time
>>>>> breaking an
>>>>> older one, can sometimes be tricky business. This means that you might
>>>>> need to iterate your patch a number of times, until it's suitable for
>>>>> inclusion. I don't want to scare you away, just be realistic up front
>>>>> that it might require some more work from your part (and our!). Also,
>>>>> (FYI, we have recently upgraded the compilers used at Oracle to VS2013
>>>>> SP4, so I know what I'm talking about...)
>>>>>    From what you write, I think you should try           to
>>>>> separate the
>>>>> freetype-src default directory from the compiler upgrade settings. The
>>>>> former might be easier to start with, as it's less likely to be
>>>>> disruptive for anything else.
>>>>>   Also, at this point, I think it would be helpful for me to be
>>>>> able to
>>>>> have an initial look at the patches. You need to be an OpenJDK
>>>>> Author to
>>>>> be able to access the OpenJDK infrastructure, so unfortunately that is
>>>>> not available to you. :-( For a first peek, the patches can be
>>>>> provided
>>>>> just about any way (but attachments to this list is unfortunately not
>>>>> allowed). For a final, proper, code review they need to reside on our
>>>>> infrastructure, but at that point I can help with fixing that.
>>>>>   /Magnus
>>>
>>
>


From david.holmes at oracle.com  Fri Dec 18 06:34:07 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Dec 2015 16:34:07 +1000
Subject: RFR: JDK-8144312: Remove limitations on the default number of
	jobs in the build
In-Reply-To: <CA+kOe0-kYE_nPqRHfr0pO9inNMszJcUkHjmH0pmPUkH6pY+-pQ@mail.gmail.com>
References: <565D6E93.8000603@oracle.com>
	<CA+kOe0-vmtFk06MUbRT_M6Sa0GSrq2hqrGssqJ3BxSwjNwCZVQ@mail.gmail.com>
	<565FA4ED.8080904@oracle.com> <566ACCA9.7060904@oracle.com>
	<566ACDE9.20901@oracle.com> <566ED91D.1030701@oracle.com>
	<CA+kOe0_o7=HbbdHohhGOEv95mBzk9=tdWS5Dp0bvGD5JO+cZ-Q@mail.gmail.com>
	<56701566.6080508@oracle.com>
	<CA+kOe09wYuu7BBhovAqF9PMo9-ux3Pcsd2sB+TpP4zDwzxcyTQ@mail.gmail.com>
	<56717057.2000701@oracle.com>
	<CA+kOe08RfbUnB=U0VJ854ZZWfLQpN9E2ngz+_iBTdCdPvbFABA@mail.gmail.com>
	<5671D964.7000406@oracle.com>
	<CA+kOe0-kYE_nPqRHfr0pO9inNMszJcUkHjmH0pmPUkH6pY+-pQ@mail.gmail.com>
Message-ID: <5673A8DF.8050400@oracle.com>

On 17/12/2015 7:41 AM, Martin Buchholz wrote:
> We can fix both JDK-6515172 and JDK-8144312 by doing the autconf
> detection of how to count the number of allowed processors, then
> actually measuring what's available during the build, and also fixing
> the hotspot implemementation of Runtime.availableProcessors.

We don't need any autoconf involvement for 6515172 (which I referred to 
a couple of days ago). Let's not muddy the waters. Autosizing the build 
parallelism is tricky enough.

David



From magnus.ihse.bursie at oracle.com  Fri Dec 18 12:37:53 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Dec 2015 13:37:53 +0100
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <5673875C.2000803@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
	<56718440.2070501@oracle.com> <5671C71A.3060404@oracle.com>
	<5672F0C3.9010104@oracle.com> <5673875C.2000803@oracle.com>
Message-ID: <5673FE21.9040203@oracle.com>

On 2015-12-18 05:11, David Holmes wrote:
> On 18/12/2015 3:28 AM, Kumar Srinivasan wrote:
>> I am good with this change!.
>>
>> I would like the rest of the component teams to weigh in on the others.
>
> This needs to be sent to all the affected component teams, or even 
> better split into three pieces: build, hotspot and JDK libs, and then 
> sent.

I sent the RFR (in another thread) to awt-dev 
<awt-dev at openjdk.java.net>, hotspot-dev <hotspot-dev at openjdk.java.net>, 
core-libs-dev <core-libs-dev at openjdk.java.net>. I thought that was 
enough. Do you suggest any more mailing lists?

/Magnus

>
> Hotspot changes looked okay to me - though the need for casts in 
> various places was unpleasant - we may want neater ways to deal with 
> that.
>
>
> Thanks,
> David
>
>> Thanks
>> Kumar
>>
>> On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:
>>> On 2015-12-16 16:33, Kumar Srinivasan wrote:
>>>> Hello,
>>>>
>>>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html 
>>>>
>>>>
>>>>
>>>> You are undefining Windows math.h OVERFLOW, what is it defined
>>>> as ? With you redefining this, will it cause problems for users of
>>>> this API, likely to affect JNI apps.
>>>>
>>>> Probably need to redefine the pack200 OVERFLOW constant to
>>>> something else, probably PACK200_OVERFLOW to prevent namespace
>>>> collisions.
>>>
>>> I agree, this is a better solution. I've updated the webrev with this
>>> solution (although I used the name PSIZE_OVERFLOW to align with
>>> PSIZE_MAX).
>>>
>>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02 
>>>
>>>
>>>
>>> /Magnus
>>>
>>>
>>>>
>>>> Kumar
>>>>
>>>> On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>>>>>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>>>>>> Hi,
>>>>>>   I have signed the OCA and emailed a scan according the
>>>>>> instructions. I separated the freetype changes into a separate
>>>>>> batch as suggested. I have shared the patch files on OneDrive, they
>>>>>> are my Public folder. Here?s the link to the folder:
>>>>>> https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>>>>>   The OneDrive folder should contain these 4 files:
>>>>>>   freetype_JDK9.patch
>>>>>> vs2015_JDK9.patch
>>>>>> vs2015_JDK9_hotspot.patch
>>>>>> vs2015_JDK9_jdk.patch
>>>>>>   The first two target the root repository, the other two are for
>>>>>> hotspot and jdk repositories, respectively.
>>>>>>   I rebased the patches on JDK9 tip today. I ran ?make
>>>>>> images? and fixed a couple of new errors that have appeared since
>>>>>> the previous version. A couple of the changes I had made were also
>>>>>> not needed any more.
>>>>>>   Please have a look!
>>>>> Hi Timo,
>>>>>
>>>>> I'm sorry for the long delay.
>>>>>
>>>>> I have created JDK-8145548 for the freetype fix. I'm sponsoring this
>>>>> fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>>>>>
>>>>> The vs2015 changes are more complicated since they touch multiple
>>>>> places in the code. Also, your patch had started bitrotting slightly
>>>>> during my long response time. I'm trying to fix it up, and will post
>>>>> a review when I have sorted everything out. I will verify that the
>>>>> change does not break any of our supported platforms, but I'd like
>>>>> you to verify that the patch still works on VS2015. When I publish
>>>>> the webrev, there will be a download link to the patch file.
>>>>>
>>>>> Also, this patch touches both hotspot code and multiple jdk modules,
>>>>> so it will need to be reviewed by other groups as well, besides the
>>>>> build team.
>>>>>
>>>>> /Magnus
>>>>>
>>>>>>             Sent from Mail for Windows 10
>>>>>>
>>>>>> From: Magnus Ihse Bursie
>>>>>> Sent: Friday, October 23, 2015 17:13
>>>>>> To: timo.kinnunen at gmail.com;build-dev
>>>>>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015
>>>>>> Communityedition
>>>>>>     On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I?ve been going over the Windows build of the whole JDK for a
>>>>>>> while with VS 2015 and now I have patches that allow the build to
>>>>>>> complete.
>>>>>>>
>>>>>>> I?ve made changes in the root repository as well as in hotspot and
>>>>>>> jdk repositories. The changes fall broadly in three categories:
>>>>>>> enabling the v140 toolchain and improving freetype compilation,
>>>>>>> adding casts to where pointers are truncated and miscellaneous
>>>>>>> small-scale code changes.
>>>>>>>
>>>>>>> The patch to the root repository streamlines handling of freetype
>>>>>>> by implementing a default source directory at $HOME/freetype under
>>>>>>> Cygwin. It is checked during configure and used for compiling if
>>>>>>> ?--with-freetype-src? is not specified. A help message giving the
>>>>>>> unpacking command with the correct directory is also included.
>>>>>>> This patch is about 90 lines without counting
>>>>>>> generated-configure.sh changes.
>>>>>>>
>>>>>>> The patches to jdk and hotspot contain native code changes only
>>>>>>> and no changes to make-files. These are about 580 and 290 lines,
>>>>>>> respectively. All patches are generated with ?hg diff -g?.
>>>>>>>
>>>>>>> Would you be willing to incorporate these? How should I proceed
>>>>>>> with this?
>>>>>>   Hi Timo,
>>>>>>   First of all, I apologize that you have not recieved any response
>>>>>> for
>>>>>> far too long. :-(
>>>>>>   Thank you for your interest in helping to improve OpenJDK!
>>>>>>   In general, a patch to allow compilation on VS 2015
>>>>>> Community edition
>>>>>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>>>>>> patch and help you work with getting it accepted.
>>>>>>   My first question to you is: have you signed the OCA? Also, unless
>>>>>> you've done so already, reading http://openjdk.java.net/contribute/
>>>>>> is a
>>>>>> good start for starting to contribute to OpenJDK.
>>>>>>   However, supporting a new compiler, without at the same time
>>>>>> breaking an
>>>>>> older one, can sometimes be tricky business. This means that you 
>>>>>> might
>>>>>> need to iterate your patch a number of times, until it's suitable 
>>>>>> for
>>>>>> inclusion. I don't want to scare you away, just be realistic up 
>>>>>> front
>>>>>> that it might require some more work from your part (and our!). 
>>>>>> Also,
>>>>>> (FYI, we have recently upgraded the compilers used at Oracle to 
>>>>>> VS2013
>>>>>> SP4, so I know what I'm talking about...)
>>>>>>    From what you write, I think you should try to
>>>>>> separate the
>>>>>> freetype-src default directory from the compiler upgrade 
>>>>>> settings. The
>>>>>> former might be easier to start with, as it's less likely to be
>>>>>> disruptive for anything else.
>>>>>>   Also, at this point, I think it would be helpful for me to be
>>>>>> able to
>>>>>> have an initial look at the patches. You need to be an OpenJDK
>>>>>> Author to
>>>>>> be able to access the OpenJDK infrastructure, so unfortunately 
>>>>>> that is
>>>>>> not available to you. :-( For a first peek, the patches can be
>>>>>> provided
>>>>>> just about any way (but attachments to this list is unfortunately 
>>>>>> not
>>>>>> allowed). For a final, proper, code review they need to reside on 
>>>>>> our
>>>>>> infrastructure, but at that point I can help with fixing that.
>>>>>>   /Magnus
>>>>
>>>
>>



From magnus.ihse.bursie at oracle.com  Fri Dec 18 12:40:21 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Dec 2015 13:40:21 +0100
Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community
	edition
In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
Message-ID: <5673FEB5.3080804@oracle.com>

On 2015-12-16 14:50, Magnus Ihse Bursie wrote:
> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition.
>
> This patch is provided by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.
>
> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well.
>
> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01
>
> /Magnus

Kumar had a reply to this which unfortunately ended up on a different 
thread on which the component teams were not cc'ed. Here are the 
relevant parts:

> On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:
> On 2015-12-16 16:33, Kumar Srinivasan wrote:
>> Hello,
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html 
>>
>>
>> You are undefining Windows math.h OVERFLOW, what is it defined
>> as ? With you redefining this, will it cause problems for users of
>> this API, likely to affect JNI apps.
>>
>> Probably need to redefine the pack200 OVERFLOW constant to
>> something else, probably PACK200_OVERFLOW to prevent namespace
>> collisions.
>
> I agree, this is a better solution. I've updated the webrev with this 
> solution (although I used the name PSIZE_OVERFLOW to align with 
> PSIZE_MAX).
>
> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02 
>
>
> /Magnus

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Dec 18 12:46:28 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Dec 2015 13:46:28 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <5673281B.8000800@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com> <56726FE1.6020906@oracle.com>
	<5673281B.8000800@oracle.com>
Message-ID: <56740024.40500@oracle.com>

On 2015-12-17 22:24, David Holmes wrote:
> On 17/12/2015 6:18 PM, Magnus Ihse Bursie wrote:
>> On 2015-12-17 09:08, David Holmes wrote:
>>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>>
>>>>
>>>> On 2015-12-17 01:40, David Holmes wrote:
>>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>>>> One more thing, where should this fix be pushed? Do you need it
>>>>>> urgently
>>>>>> in hs-rt?
>>>>>
>>>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>>>
>>>> Will do.
>>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>>>> spec.gmk and so was never externally introduced into the hotspot 
>>>>> build
>>>>> this way. So why not simply change the name of the variable so 
>>>>> that it
>>>>> has no affect on the hotspot part of the build?
>>>>>
>>>> Well, we don't want it affecting the jdk part of the build either at
>>>> this point. This patch aims to restore the "external" and "zipped"
>>>> settings to exactly what they were before the patch, as was promised.
>>>
>>> I had not inferred from any of this that what was being done via
>>> NativeCompilation.gmk was in any way a problem. I would have expected
>>> any problems there to be readily seen before this was reviewed and
>>> pushed. So I'm a bit confused about this.
>>
>> The changes in NativeCompilation.gmk looked perfectly fine. They turned
>> out to trigger a bug (or, at the very least, very unsuspected behavior)
>> which was deeply hidden in the hotspot linux makefiles, where setting
>> DEBUG_BINARIES did indeed enable the -g flag, but also, as a side
>> effect, turned fastdebug builds into slowdebug builds. This was not
>> something that we could possibly forsee.
>
> That was my understanding too - that this was simply a side-effect on 
> hotspot, hence my suggestion to rename the variable. But Erik then 
> said this was also not working correctly for the JDK side - which 
> means the problem is far worse.

JDK-8036003 introduced the the use of DEBUG_BINARIES in jdk code as 
well. So it "affects" jdk libraries as well, but not with the kind of 
performance regression. However, it did enable debug information were we 
didn't have it before in the Oracle builds. While I believe this is a 
good thing, it should be added under more controlled forms. Therefore we 
want to revert the effect of DEBUG_BINARIES for the kinds of build we do 
at Oracle (external/zipped), keep the effect added in JDK-8036003 for 
the new kind of builds the community requested (internal), and finally 
we want to enable debug symbols for all our jdk libraries as a separate 
change, JDK-8145596.

The only thing left to do is for the community to provide a fix to the 
problem that the newly added functionality of debug-symbols=internal 
means that hotspot in effect turns into a slowdebug build. Since the 
community regularly builds by setting DEBUG_BINARIES=true on the command 
line, it's not really a regression for them, but it's still a bug since 
they get unnecessarily slow builds. Either they need to provide a patch, 
or wait for the new hotspot build where this won't be a problem.

/Magnus


It was not "far worse", but

>
> David
> -----
>
>
>>>
>>> I'm tempted to say rollback the whole thing rather than hack at it.
>>
>> I don't think there is any compelling reason to rollback the whole
>> change. The basic idea is sound. However, we do need to work on how to
>> handle the debug symbols "under the hood". This deficit has been known
>> for a long time to me and Erik but we have not spent any time on it.
>> This change brought the problems up to daylight, and I think that's a
>> good thing.
>>
>> I've started working on JDK-8145596, which will provide a proper
>> solution to how we handle debug symbols. It is based on JDK-8036003.
>>
>> /Magnus
>>
>>
>>>
>>> And apologies as I'm just about to go offline for a few hours at least.
>>>
>>> David
>>> -----
>>>
>>>
>>>
>>>> We will followup with a more complete fix.
>>>>
>>>> /Erik
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2015-12-16 22:34, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review this quick fix for the build issue introduced in
>>>>>>> Hotspot
>>>>>>> by JDK-8036003. The short story is that if you set
>>>>>>> DEBUG_BINARIES=true
>>>>>>> when building Hotspot fastdebug, you essentially get a slowdebug
>>>>>>> build. For an explanation of why, see comment in bug. This
>>>>>>> behavior is
>>>>>>> of course also a bug, but not something I will address in this 
>>>>>>> quick
>>>>>>> fix.
>>>>>>>
>>>>>>> What happened in JDK-8036003 was that a new configure API for
>>>>>>> controlling debug symbols was introduced. The two main settings of
>>>>>>> this new parameter, --with-native-debug-symbols, that we use
>>>>>>> internally at Oracle are "external" and "zipped". It was 
>>>>>>> important to
>>>>>>> us that the behavior of these did not change with JDK-8036003, but
>>>>>>> exactly that did happen, because both of these settings now cause
>>>>>>> DEBUG_BINARIES=true to be set. This variable has never been set by
>>>>>>> configure before and because of the above weird behavior in the
>>>>>>> Hotspot makefiles, we are having problems.
>>>>>>>
>>>>>>> My proposed quick fix is to not set DEBUG_BINARIES=true for
>>>>>>> "external"
>>>>>>> or "zipped". It can remain true for "internal" since Oracle never
>>>>>>> builds it that way, and I understand those that requested this new
>>>>>>> configure parameter were setting DEBUG_BINARIES=true as a 
>>>>>>> workaround
>>>>>>> before this anyway, so they should be fine with the broken 
>>>>>>> fastdebug
>>>>>>> behavior for a while more. I will file a follow up bug to properly
>>>>>>> clean up this mess, but it will take some more time.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145564
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8145564/webrev.01/
>>>>>>>
>>>>>>> /Erik
>>>>>>
>>>>
>>



From magnus.ihse.bursie at oracle.com  Fri Dec 18 13:01:08 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Dec 2015 14:01:08 +0100
Subject: RFR: JDK-8145564: 8036003: startup regression on linux fastdebug
	builds
In-Reply-To: <567329D0.8010303@oracle.com>
References: <5671D8CB.8080500@oracle.com> <5671D90A.5020208@oracle.com>
	<5672046E.5@oracle.com> <56726A4D.5050600@oracle.com>
	<56726D95.20103@oracle.com> <56727F3D.7090600@oracle.com>
	<567329D0.8010303@oracle.com>
Message-ID: <56740394.30706@oracle.com>

On 2015-12-17 22:32, David Holmes wrote:
> On 17/12/2015 7:24 PM, Erik Joelsson wrote:
>> On 2015-12-17 09:08, David Holmes wrote:
>>> On 17/12/2015 5:54 PM, Erik Joelsson wrote:
>>>>
>>>>
>>>> On 2015-12-17 01:40, David Holmes wrote:
>>>>> On 17/12/2015 7:35 AM, Erik Joelsson wrote:
>>>>>> One more thing, where should this fix be pushed? Do you need it
>>>>>> urgently
>>>>>> in hs-rt?
>>>>>
>>>>> It is urgently needed in both the hs-rt and hs-comp repos as it
>>>>> affects nightly testing and JPRT. If Alejandro agrees I suggest
>>>>> pushing to jdk9/hs and it can then be pulled down to the team repos.
>>>>>
>>>> Will do.
>>>>> With regard to the fix ... previously DEBUG_BINARIES was never set in
>>>>> spec.gmk and so was never externally introduced into the hotspot 
>>>>> build
>>>>> this way. So why not simply change the name of the variable so 
>>>>> that it
>>>>> has no affect on the hotspot part of the build?
>>>>>
>>>> Well, we don't want it affecting the jdk part of the build either at
>>>> this point. This patch aims to restore the "external" and "zipped"
>>>> settings to exactly what they were before the patch, as was promised.
>>>
>>> I had not inferred from any of this that what was being done via
>>> NativeCompilation.gmk was in any way a problem. I would have expected
>>> any problems there to be readily seen before this was reviewed and
>>> pushed. So I'm a bit confused about this.
>>>
>> I didn't follow this particular review closely as Magnus was on it and
>> so I had missed the NativeCompilation part. It's true that it is very
>> unlikely to be part of the problem described in this bug, but I still
>> feel that the safest action at this point is to restore the behavior of
>> "external" and "zipped" to what they used to be.
>
> My concern is recognizing that these adjustments do in fact restore 
> the old behaviour. From the hotspot side it seemed cleaner to avoid 
> the breakage by using a different variable name.

I'm not sure about this talk about a different variable name? The 
*point* of the patch was *exactly* to set DEBUG_BINARIES=true for 
internal builds. The problem was that it also set it for 
external/zipped, which was incorrect. But neither the writer of the 
patch nor me (or any other reviewer) realized that this would have this 
"hammer" effect.


>
>> Magnus is working on a
>> complete fix where debug symbols will be enabled for everything in
>> NativeCompilation.
>>> I'm tempted to say rollback the whole thing rather than hack at it.
>>>
>> Rolling back will be much more work for me than submitting this patch.
>> There are two changes already that depend on this change. I also don't
>> dislike the idea of the new configure parameter.
>
> Rolling back the new configure parameters and then reinstating them 
> again would also not win us any friends as it would be very 
> disruptive. As others have noted the way we introduce and remove 
> configure parameters needs to be looked at.
This makes it sound like we're sloppy with configure arguments when we 
actually try hard not to be.

Normally, we don't have any problems with introducing new configure 
arguments. Most often, when we introduce a new argument, the behaviour 
falls back to the old behaviour as default if the argument is not 
specified. From time to time, we actually need to change the behaviour 
of configure, and this does not really apply. But then again, all 
modification somehow change behaviour regardless of if any options are 
changed, an all changes in behaviour breaks someones workflow 
(compulsory xkcd reference: https://xkcd.com/1172/).

In this case, not setting the new configure option resulted in the old 
default behaviour.

As for removing options, we are more conservative. We never remove 
options, we just deprecate them. (With a few exceptions, e.g. sometimes 
we have introduced temporary options which are clearly announced as 
such.) Our plan is to remove deprecated options once some time has 
passed (e.g. next major release) but, like the Java language itself, so 
far we have not actually removed any deprecated options. :-)

When we deprecate an option, we ignore the value it sets, but prints a 
warning stating that the option is deprecated. The configure call will 
not fail, though. The warning is repeated as the very last thing so it 
should be easy for the user to spot, like this:

The following warnings were produced. Repeated here for convenience:
WARNING: Option --with-override-jaxp is deprecated and will be ignored.

In some cases we've tried to write some "glue" to interpret old and 
deprecated options in terms of new. (I only think we've done this in the 
closed source). I don't really like it. It means a lot of tests, 
handling situations like what if both old and new are set, and they 
conflict? Or if both old and new are set and they do *not* conflict? 
What if the behaviour has changed slightly, so it does not really match? 
When should we stop helping the user to convert from the old to the new?

> I was mainly concerned that the out-of-the-box default behaviour was 
> unchanged.

The stated goal of the patch was that out of the box behaviour should 
have been unchanged. The patch was however incorrect, and this fact was 
not detected during testing of the patch (I only tested if it built ok, 
not that the resulting build did not degrade in performance) nor during 
code review. Such things happen, and then you need to fix them.

/Magnus

>
>>> And apologies as I'm just about to go offline for a few hours at least.
>>>
>> I hope you won't object to me pushing this with just ihse as reviewer. I
>> feel this is rather a priority to get fixed.
>
> Sure. I had verified that DEBUG_BINARIES is only ever tested against 
> "true" so setting it to false should be as effective as not setting it 
> at all.
>
> I'll follow up separately to see where this was pushed and whether we 
> need to pull it into anywhere else urgently.
>
> Thanks,
> David
>
>> /Erik



From david.holmes at oracle.com  Fri Dec 18 13:10:30 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Dec 2015 23:10:30 +1000
Subject: Building jdk9 on Windows x64 and Visual Studio 2015
	Communityedition
In-Reply-To: <5673FE21.9040203@oracle.com>
References: <56056e96.a558c20a.d796d.486a@mx.google.com>
	<562A4E85.9070004@oracle.com>
	<563b8c03.54571c0a.cc880.ffffac8a@mx.google.com>
	<BAD7DF44-7C99-42AC-8901-76B6438CD1E2@oracle.com>
	<56718440.2070501@oracle.com> <5671C71A.3060404@oracle.com>
	<5672F0C3.9010104@oracle.com> <5673875C.2000803@oracle.com>
	<5673FE21.9040203@oracle.com>
Message-ID: <567405C6.7000004@oracle.com>

On 18/12/2015 10:37 PM, Magnus Ihse Bursie wrote:
> On 2015-12-18 05:11, David Holmes wrote:
>> On 18/12/2015 3:28 AM, Kumar Srinivasan wrote:
>>> I am good with this change!.
>>>
>>> I would like the rest of the component teams to weigh in on the others.
>>
>> This needs to be sent to all the affected component teams, or even
>> better split into three pieces: build, hotspot and JDK libs, and then
>> sent.
>
> I sent the RFR (in another thread) to awt-dev
> <awt-dev at openjdk.java.net>, hotspot-dev <hotspot-dev at openjdk.java.net>,
> core-libs-dev <core-libs-dev at openjdk.java.net>. I thought that was
> enough. Do you suggest any more mailing lists?

Sorry didn't see that mail till much later - my mail is sorted by subject :)

Cheers,
David

> /Magnus
>
>>
>> Hotspot changes looked okay to me - though the need for casts in
>> various places was unpleasant - we may want neater ways to deal with
>> that.
>>
>>
>> Thanks,
>> David
>>
>>> Thanks
>>> Kumar
>>>
>>> On 12/16/2015 12:18 PM, Magnus Ihse Bursie wrote:
>>>> On 2015-12-16 16:33, Kumar Srinivasan wrote:
>>>>> Hello,
>>>>>
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01/jdk/src/jdk.pack200/share/native/common-unpack/utils.h.udiff.html
>>>>>
>>>>>
>>>>>
>>>>> You are undefining Windows math.h OVERFLOW, what is it defined
>>>>> as ? With you redefining this, will it cause problems for users of
>>>>> this API, likely to affect JNI apps.
>>>>>
>>>>> Probably need to redefine the pack200 OVERFLOW constant to
>>>>> something else, probably PACK200_OVERFLOW to prevent namespace
>>>>> collisions.
>>>>
>>>> I agree, this is a better solution. I've updated the webrev with this
>>>> solution (although I used the name PSIZE_OVERFLOW to align with
>>>> PSIZE_MAX).
>>>>
>>>> http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.02
>>>>
>>>>
>>>>
>>>> /Magnus
>>>>
>>>>
>>>>>
>>>>> Kumar
>>>>>
>>>>> On 12/16/2015 5:35 AM, Magnus Ihse Bursie wrote:
>>>>>>> On 2015-11-05 18:03, Timo Kinnunen wrote:
>>>>>>> Hi,
>>>>>>>   I have signed the OCA and emailed a scan according the
>>>>>>> instructions. I separated the freetype changes into a separate
>>>>>>> batch as suggested. I have shared the patch files on OneDrive, they
>>>>>>> are my Public folder. Here?s the link to the folder:
>>>>>>> https://onedrive.live.com/redir?resid=a243a3e0b2aaacfa%21107
>>>>>>>   The OneDrive folder should contain these 4 files:
>>>>>>>   freetype_JDK9.patch
>>>>>>> vs2015_JDK9.patch
>>>>>>> vs2015_JDK9_hotspot.patch
>>>>>>> vs2015_JDK9_jdk.patch
>>>>>>>   The first two target the root repository, the other two are for
>>>>>>> hotspot and jdk repositories, respectively.
>>>>>>>   I rebased the patches on JDK9 tip today. I ran ?make
>>>>>>> images? and fixed a couple of new errors that have appeared since
>>>>>>> the previous version. A couple of the changes I had made were also
>>>>>>> not needed any more.
>>>>>>>   Please have a look!
>>>>>> Hi Timo,
>>>>>>
>>>>>> I'm sorry for the long delay.
>>>>>>
>>>>>> I have created JDK-8145548 for the freetype fix. I'm sponsoring this
>>>>>> fix. I'll send out a proper review on cr.openjdk.java.net shortly.
>>>>>>
>>>>>> The vs2015 changes are more complicated since they touch multiple
>>>>>> places in the code. Also, your patch had started bitrotting slightly
>>>>>> during my long response time. I'm trying to fix it up, and will post
>>>>>> a review when I have sorted everything out. I will verify that the
>>>>>> change does not break any of our supported platforms, but I'd like
>>>>>> you to verify that the patch still works on VS2015. When I publish
>>>>>> the webrev, there will be a download link to the patch file.
>>>>>>
>>>>>> Also, this patch touches both hotspot code and multiple jdk modules,
>>>>>> so it will need to be reviewed by other groups as well, besides the
>>>>>> build team.
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>>             Sent from Mail for Windows 10
>>>>>>>
>>>>>>> From: Magnus Ihse Bursie
>>>>>>> Sent: Friday, October 23, 2015 17:13
>>>>>>> To: timo.kinnunen at gmail.com;build-dev
>>>>>>> Subject: Re: Building jdk9 on Windows x64 and Visual Studio 2015
>>>>>>> Communityedition
>>>>>>>     On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I?ve been going over the Windows build of the whole JDK for a
>>>>>>>> while with VS 2015 and now I have patches that allow the build to
>>>>>>>> complete.
>>>>>>>>
>>>>>>>> I?ve made changes in the root repository as well as in hotspot and
>>>>>>>> jdk repositories. The changes fall broadly in three categories:
>>>>>>>> enabling the v140 toolchain and improving freetype compilation,
>>>>>>>> adding casts to where pointers are truncated and miscellaneous
>>>>>>>> small-scale code changes.
>>>>>>>>
>>>>>>>> The patch to the root repository streamlines handling of freetype
>>>>>>>> by implementing a default source directory at $HOME/freetype under
>>>>>>>> Cygwin. It is checked during configure and used for compiling if
>>>>>>>> ?--with-freetype-src? is not specified. A help message giving the
>>>>>>>> unpacking command with the correct directory is also included.
>>>>>>>> This patch is about 90 lines without counting
>>>>>>>> generated-configure.sh changes.
>>>>>>>>
>>>>>>>> The patches to jdk and hotspot contain native code changes only
>>>>>>>> and no changes to make-files. These are about 580 and 290 lines,
>>>>>>>> respectively. All patches are generated with ?hg diff -g?.
>>>>>>>>
>>>>>>>> Would you be willing to incorporate these? How should I proceed
>>>>>>>> with this?
>>>>>>>   Hi Timo,
>>>>>>>   First of all, I apologize that you have not recieved any response
>>>>>>> for
>>>>>>> far too long. :-(
>>>>>>>   Thank you for your interest in helping to improve OpenJDK!
>>>>>>>   In general, a patch to allow compilation on VS 2015
>>>>>>> Community edition
>>>>>>> sounds like a good edition to OpenJDK. I am willing to sponsor this
>>>>>>> patch and help you work with getting it accepted.
>>>>>>>   My first question to you is: have you signed the OCA? Also, unless
>>>>>>> you've done so already, reading http://openjdk.java.net/contribute/
>>>>>>> is a
>>>>>>> good start for starting to contribute to OpenJDK.
>>>>>>>   However, supporting a new compiler, without at the same time
>>>>>>> breaking an
>>>>>>> older one, can sometimes be tricky business. This means that you
>>>>>>> might
>>>>>>> need to iterate your patch a number of times, until it's suitable
>>>>>>> for
>>>>>>> inclusion. I don't want to scare you away, just be realistic up
>>>>>>> front
>>>>>>> that it might require some more work from your part (and our!).
>>>>>>> Also,
>>>>>>> (FYI, we have recently upgraded the compilers used at Oracle to
>>>>>>> VS2013
>>>>>>> SP4, so I know what I'm talking about...)
>>>>>>>    From what you write, I think you should try to
>>>>>>> separate the
>>>>>>> freetype-src default directory from the compiler upgrade
>>>>>>> settings. The
>>>>>>> former might be easier to start with, as it's less likely to be
>>>>>>> disruptive for anything else.
>>>>>>>   Also, at this point, I think it would be helpful for me to be
>>>>>>> able to
>>>>>>> have an initial look at the patches. You need to be an OpenJDK
>>>>>>> Author to
>>>>>>> be able to access the OpenJDK infrastructure, so unfortunately
>>>>>>> that is
>>>>>>> not available to you. :-( For a first peek, the patches can be
>>>>>>> provided
>>>>>>> just about any way (but attachments to this list is unfortunately
>>>>>>> not
>>>>>>> allowed). For a final, proper, code review they need to reside on
>>>>>>> our
>>>>>>> infrastructure, but at that point I can help with fixing that.
>>>>>>>   /Magnus
>>>>>
>>>>
>>>
>


From boaznahum at gmail.com  Fri Dec 18 13:16:50 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Fri, 18 Dec 2015 13:16:50 +0000
Subject: Build failure on windows 'freetypeScaler.c'
Message-ID: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>

Hi

Lately, I have this error:

f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
: error C2220: warning treated as error - no 'object' file generated
f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
: warning C4101: 'stream' : unreferenced local variable

I comment out:

static void freeNativeResources(JNIEnv *env, FTScalerInfo* scalerInfo) {
//    void *stream;


And now it works.

Thx
Boaz


From magnus.ihse.bursie at oracle.com  Fri Dec 18 13:28:38 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Dec 2015 14:28:38 +0100
Subject: Build failure on windows 'freetypeScaler.c'
In-Reply-To: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
References: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
Message-ID: <56740A06.1070803@oracle.com>

On 2015-12-18 14:16, Boaz Nahum wrote:
> Hi
>
> Lately, I have this error:
>
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> : error C2220: warning treated as error - no 'object' file generated
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> : warning C4101: 'stream' : unreferenced local variable
>
> I comment out:
>
> static void freeNativeResources(JNIEnv *env, FTScalerInfo* scalerInfo) {

This is a know problem which is fixed by JDK-8139803.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Dec 18 13:35:19 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Dec 2015 14:35:19 +0100
Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe
In-Reply-To: <CA+kOe08k4S5vejaLeMHghG6HkgAokEUubHHbgROvoiDUq-N2BQ@mail.gmail.com>
References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com>
	<56704076.8050203@Oracle.com>
	<CA+kOe08k4S5vejaLeMHghG6HkgAokEUubHHbgROvoiDUq-N2BQ@mail.gmail.com>
Message-ID: <56740B97.5000901@oracle.com>

On 2015-12-15 18:25, Martin Buchholz wrote:
> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
> affects interoperability between translation units.  It would be good
> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but
> that would be a big job.  So traditionally the JDK has instead used
> the functions made available via _LARGEFILE64_SOURCE.  But that is
> also a JDK-wide job now, because every call to plain stat in the
> source code is broken on 32-bit systems with 64-bit inodes, which are
> becoming more common.
>
> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job
> for build-dev, not core-libs-dev.

If I understand things correctly, then setting _FILE_OFFSET_BITS=64 
would mean two things:
1) Just pass this additional define to all C files being compiled (a 
build change)
2) Update all calls to file operating functions to make sure the proper 
64-bit types are used (changes in source code).

The change for 1) is a trivial one liner, while getting 2) correct is a 
serious undertaking in the source code. Such a change must be done by 
the component teams, not the build team. With that said, I think it is a 
reasonable change and I'll support it as much as I can. But as the 
division of labour is done here, it's not the work of the build team to 
go and make heavy modifications to the product source code.

/Magnus

>
>
>
>
> On Tue, Dec 15, 2015 at 8:31 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi Yvom,
>>
>> Minor comments:
>>
>> src/java.base/share/native/libjava/RandomAccessFile.c:
>>   - "length fail" might be clearer as "GetLength failed"
>>
>> src/java.base/unix/native/libjava/io_util_md.c:
>>
>>   - Please add a comment before the define of FILE_OFFSET_BITS to indicate
>> where it is used and why it is there.
>>   - BTW, are there any unintended side effects?
>>     Perhaps a different issue but perhaps 64 bit offsets should be used
>> everywhere
>>
>> src/java.base/windows/native/libjava/io_util_md.c
>>   - Line 592: Using INVALID_HANDLE_VALUE is better than -1 and is used
>> elsewhere in the file
>>     BTW, Testing for invalid handle might be unnecessary since the call to
>> GetFileSizeEx will fail
>>     if it is invalid, yielding the same result.
>>
>> Roger
>>
>>
>> On 12/10/2015 5:52 AM, vyom wrote:
>>> Hi All,
>>>
>>> Please review my changes for below bug.
>>>
>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe
>>>
>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/
>>> <http://cr.openjdk.java.net/%7Evtewari/4823133/webrev0.0/>
>>>
>>> This change ensure that  length() does not temporarily changes the file
>>> pointer and it will make sure that there is no race
>>> condition in case of multi thread uses.
>>>
>>> Thanks,
>>> Vyom
>>>
>>>
>>>
>>>



From weijun.wang at oracle.com  Fri Dec 18 14:11:23 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 18 Dec 2015 22:11:23 +0800
Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community
	edition
In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
Message-ID: <57E1C404-21A6-41F7-87EF-881EDD3830C1@oracle.com>

Hi Vinnie

I take a look and it includes a change for src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the Java_sun_security_mscapi_KeyStore_getKeyLength() function.

It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the java side. Is the function useless now?

Thanks
Max

> On Dec 16, 2015, at 9:50 PM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. 
> 
> This patch is provided by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.
> 
> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well.
> 
> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01
> 
> /Magnus



From maurizio.cimadamore at oracle.com  Fri Dec 18 18:26:44 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 18 Dec 2015 18:26:44 +0000
Subject: Build failure on windows 'freetypeScaler.c'
In-Reply-To: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
References: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
Message-ID: <56744FE4.4030404@oracle.com>

Fix pushed

Maurizio

On 18/12/15 13:16, Boaz Nahum wrote:
> Hi
>
> Lately, I have this error:
>
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> : error C2220: warning treated as error - no 'object' file generated
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> : warning C4101: 'stream' : unreferenced local variable
>
> I comment out:
>
> static void freeNativeResources(JNIEnv *env, FTScalerInfo* scalerInfo) {
> //    void *stream;
>
>
> And now it works.
>
> Thx
> Boaz



From gary.adams at oracle.com  Fri Dec 18 18:46:59 2015
From: gary.adams at oracle.com (Gary Adams)
Date: Fri, 18 Dec 2015 13:46:59 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <5673FD5C.2040302@oracle.com>
References: <566AE88C.3040701@oracle.com> <5672B655.5030200@oracle.com>
	<5672DE37.1040801@oracle.com> <56730F96.8000803@oracle.com>
	<5673FD5C.2040302@oracle.com>
Message-ID: <567454A3.9000206@oracle.com>

On 12/18/15 07:34, Magnus Ihse Bursie wrote:
> On 2015-12-17 20:40, Gary Adams wrote:
>> On 12/17/15 11:09, Magnus Ihse Bursie wrote:
>>> On 2015-12-17 14:19, Gary Adams wrote:
>>>> I've revised the original webrev based on some feedback received.
>>>>    - reverted white space only changes
>>>>    - proper copyrights on the new files
>>>>    - some hotspot files contained previously removed code
>>>>
>>>>   Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/
>>>>
>>>> Planning to push this first batch tomorrow.
>>>
>>> Hi Gary,
>>>
>>> There seems to be multiple merge/diff errors in this patch. I'm 
>>> seeing several location where this patch contains changes that is 
>>> part of other, recently pushed change sets. This makes it hard to 
>>> fully understand what changes you are contributing in this patch, to 
>>> speak nothing of the merge problems that are likely to arise if this 
>>> patch were pushed as it is.
>> My bad. In getting the workspace to build I had diff'ed the files 
>> against the latest jdk9-dev sources
>> and pulled in changes that were ahead of the recently cloned 
>> mobile/dev repos.
>> The next merge will bring in those updates. mobile/dev is cloned from 
>> jdk9-b94 and latest jdk9/dev
>> is at jdk9-9+b96.
While reverting the code that had newer functionality than it should,
I found the issue that dragged me down the rabbit hole. The change
to use JAVA_JAVAC in the SetupCompilers logic was a thread that
unraveled into more code than I should have touched.  I'll double
check on the next resync to make sure everything is OK.
>>
>>>
>>> I found several other issues as well. I'm sorry I have not been able 
>>> to review this code before. It's a quite massive patch. If you want 
>>> to commit the patch as-is in the mobile/dev forest and then fix my 
>>> comments later before pushing further to mobile/jdk9, it's ok for 
>>> me. I understand that it's tricky to manage a patch of this size. 
>>> (But I think it's better to fix issues now, if you ask me...)
>> I'd like to do any simple cleanups before the initial push. We know 
>> there will be more pushes coming, so I'm not opposed to partial solutions
>> being put back at this time.
>>>
>>> I'll start with something that you and Erik already has discussed: 
>>> how to express tests for logic that is common to ios and macosx. 
>>> There are places in the patch right now that I'm still not happy with.
>>>
>>> First of all, I don't think you need to be shy of testing for macosx 
>>> or ios. It's a bit more to write, but it's very clear to the reader, 
>>> and code is read more often than written.
>> I am uncomfortable with all the places platform specific changes need 
>> to be made.
>> There isn't an easy way to express platform A is like platform B with 
>> the following
>> differences.
>
> I agree. Platforms are alike and different in very amorphous ways. 
> We've tried to capture some of this using the concept of "os type" 
> (that is, to group unix-like operating systems) and "os env" (to 
> differentiate the unix-emulation layers on windows). It works sort-of, 
> but it's not perfect. For instance, in some respects macosx is indeed 
> "unix", but in many other (GUI etc), it's different. We could of 
> course try to create some kind of category "unix-except-macosx" for 
> that, but in the end I don't think having 
> src/java.base/unix-but-not-macosx/ would fly. :-)
>
> So this is a tricky problem, and I believe it can only be "solved" in 
> terms of getting a "best effort" solution for the platforms and 
> combinations we currently support. When that support matrix changes 
> too much (as with mobile), we might have to revise our model. Let's 
> keep an open discussion on the best way to solve this for mobile. For 
> now, though, I think the best way is to try and use the current 
> framework as far as possible. Then we will learn what the actual 
> limitations are and where they need to be fixed.
OK
>
>>>
>>> Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. 
>>> It's a bit strange, since it changes the meaning of the OS_ENV 
>>> (previously it was only used to differentiate between cygwin and 
>>> msys in Windows), but I think it could be a reasonable modification. 
>>> This means that you can test if OPENJDK_TARGET_OS_ENV == macosx to 
>>> cover both the case of macosx and ios. Let's just assume that you 
>>> need to know what you're doing when looking at OS_ENV. So this could 
>>> be an alternative to a lot of "if target == macosx or target == 
>>> ios", if you don't want to type that everywhere. For android it 
>>> seems less of a point of setting OS_ENV. Or do you think you could 
>>> unify android/linux code by this?
>> I thought previously we were told not to use OPENJDK_TARGET_OS_ENV 
>> and I asked at that time for "documentation".
>
> You probably were. :) And it is perhaps best that you don't. :-) In 
> any way, I don't see any references to the OS_ENV in this code anyway, 
> so given that, you should remove this.

Removed OS_ENV settings for both andrioid and ios from platform.m4.
>
> What I think you need is, as I understand it, rather to express some 
> "os kind", that is, saying that android is "a kind of" linux and ios 
> is "a kind of" macosx, so that  at times android behaves as linux, but 
> at times it behaves differently, etc. I thought maybe OS_ENV could use 
> that role, but perhaps it's best not to mess around with it.
>
>
>>>
>>> Third, I'm not really fond of the TOOLCHAIN_NAME variable. The 
>>> concept is fine, but the variable name is not (I know you didn't 
>>> invent this).  We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME 
>>> sounds like just a variant of that. Perhaps resusing the fluffy and 
>>> unspecified ENV and call it TOOLCHAIN_ENV instead? I thought of 
>>> TOOLCHAIN_VENDOR, but then again I'd assume that it'd be "apple", 
>>> and I think we gain clarity by calling Xcode "xcode" and not "apple".
>>
>> I'd be glad to use a different name or value for the flag, just let 
>> me know.
>>
>> This is a change we could defer til the mobile/dev to mobile/jdk9 
>> integration.
>> At this time I'm mostly interested to know that we've used it in the 
>> right places.
>> e.g. prior to discovery of boot-jdk and xcode we used BUILD_OS 
>> macosx, after
>> that we use toolchain xcode check, for native flags and libraries we 
>> still check TARGET_OS
>> for macosx or ios when not xcode specific.
>
> Fair enough. Use TOOLCHAIN_NAME for now, and we'll make a 
> search/replace for it later on if we agree on a better name. I think 
> your usage of the xcode check was good, except where I noted otherwise 
> in my review.
>
>
>>>
>>> So, to the specifics:
>>> basics.m4: It's not really true that this is build os rather than 
>>> target os. In fact, the whole block is a mix of target and build 
>>> dependent stuff. For instance, xattr depends on build platform but 
>>> dsymutil depends on target os. I suggest you change to target == 
>>> macosx || ios.
>> Will do.
>>>
>>> boot-jdk.m4: At the end looks like merge error.
>> Will fix.
>> We had the big java fix in ejdk8u and it recently cam back in jdk9
>> recent builds.
>>
>>>
>>> flags.m4: Why delete CPPFLAGS for SYSROOTS?
>> SYSROOT does not belong on CPPFLAGS.
>> We needed the fix for the ios builds.
> Hm...
>
> First of all, I'm not even sure where we're using CPPFLAGS. It's 
> probably in a few special cases. Do you remember where you got 
> problems with the CPPFLAGS and sysroot? But even the preprocessor 
> needs to know the path to the system header files to be able to 
> function correctly, yes? So I still can't really see why this should 
> be deleted.
>
> Are you using it to create build tools, i.e. tools that should run 
> during the build process on the build platform when cross compiling? 
> If so, you probably need a BUILD_CPP, which we might be lacking at the 
> moment.

The original configure processing validates the flag settings.
If CPP flags include the target platform sysroot there are errors
in the compile and execute tests. It's not set up well for cross
compilation checks. In the early stages it just wants to ensure
it has a command that accepts flags. e.g. build cc and ld

>
>>
>>>
>>> I think that if you set only LEGACY_EXTRA_CFLAGS and not 
>>> EXTRA_CFLAGS, you will only pass this to Hotspot and not the jdk 
>>> libraries. But honestly, the flag handling is mysterious even to me 
>>> so I can't say for sure. But you might want to double-check this.
>> Not sure about this comment. We have working ios and android builds 
>> from the flags
>> that are currently being set. Several fingers over several years have 
>> touched these
>> files, so the original intent may not be clear.
>
> If it works for you I'm happy. :-) I'm just a bit surprised that it 
> does. But it also goes to show that we desperately need to rework the 
> flag handling, it's grown almost impossible to comprehend.
:-)

>
>
>>>
>>> BUILD_CC check looks like merge error.
>> Will fix.
>>
>>>
>>> lib-bundled.m4:
>>> Out choice to use system zlib has nothing to do with xcode. It's a 
>>> target os decision.
>> Will fix.
>>>
>>> lib-freetype.m4: OTOH, I'd say that this is indeed a build-os 
>>> decision :-)
>> Will fix.
>>>
>>> lib-std.m4: This test is only valid for gcc. We are currently not 
>>> using gcc, only clang, for macosx builds. Are you really using gcc 
>>> for ios builds? Otherwise, just leave it as it is.
>> Only changed it because it was flagged as
>> should be changed if we switched from xcode clang to
>> gcc based toolchain in the future.
>>
>> Will revert/fix.
>>
>>>
>>> spec.gmk.in:
>>> Looks like mostly (only?) merge problems here. Or have you added 
>>> something?
>> Will roll back the sjava related changes, but keep
>> the ":=" fix on mac osx version.
> Aha, there were your change. I missed it.
>>
>>>
>>> toolchain.m4: See discussion above on TOOLCHAIN_NAME. It looks like 
>>> there are lot of merge errors here.
>>
>> Will recheck.
>>>
>>> CompileJavaModules.gmk: Merge errrors galore. I can't really tell 
>>> what are your changes in here.
>> Will fix
>>>
>>> Images.gmk: Care to elaborate? I don't understand anything.
>> ios builds do not build any command line executables.
>> It is the wrong target to build a dependency when the jlmage is
>> the result of the recipe.
>>   # Use this file inside the image as target for make rule
>> -JIMAGE_TARGET_FILE := bin/java$(EXE_SUFFIX)
>> +JIMAGE_TARGET_FILE := lib/modules/bootmodules.jimage
>
> Right! *duh* I didn't read the comment above, I just noted that you 
> did a non-platform specific change and reacted to that. In fact, 
> checking for the jimage almost seems more natural even if it weren't 
> for your requirements. :)
>
>>>
>>> Main.gmk, JavaCompilation.gmk, Modules.gmk: Merge errors. What is 
>>> your changes in these files? I can't review this.
>>>
>>> MakeBase.gmk: just wanted to let you know that I approve of the 
>>> change to build os. :-) I'd appreciate if you could fix the 
>>> whitespace mistake as well (space after the comma is missing).
>> Fixed.
>> (Sure would be nice if there was tool to do the makefile whitespace 
>> checking.)
>
> Indeed it would be. If you know of one, let me know. :-)
>
> On a slightly more serious note: I've done some research on code 
> formatting tools for makefiles, but that's more or less non-existent. 
> I think it's a combination of having a small target audience and an 
> archaic and difficult syntax. So we've realized that we need to be 
> vigilant and learn to fix the whitespace ourself manually, to keep the 
> files from creeping back into an unreadable mess.

The best tool I've found so far is the flymake-mode in emacs.
One of the difficulties debugging with the current recipe generation 
approach
in the makefiles, is you never have a "final form makefile" that you can 
examine
for debugging purposes. I had a number of "makefile syntax errors - 
missing separator"
that I tried to track down looking for a recipe missing tabs (typical 
error case), but
was actually a missing double-dollar in the two level Setup recipe 
processing.
If we had a "show me the makefile you think you are processing", it 
might have been
a quicker identification of the premature comma expansion error.
>
>>
>>>
>>> SetupJavaCompilers.gmk: merge errors? For the 
>>> GENERATE_JAVA5_BYTECODE, please use space after comma. (I know we 
>>> didn't do that everywhere originally, but new code should adhere to 
>>> the styleguide.)
>> Fixed.
>> I assume it's OK to fix the other missing space-after-comma.
> Yes.
>
>>
>>>
>>> jdk/make/CompileDemos.gmk: Merge erros. The new android ifdef should 
>>> have proper whitespace (space after comma, the if block indented two 
>>> spaces).
>> Fixed.
>>>
>>> jdk/make/Import.gmk: Looks like the block after the two ifneq 
>>> ($(OPENJDK_TARGET_OS), ios) has not been indented. (Or is it a 
>>> problem with the webrev?) Also, the android ifdef is weirdly 
>>> indented, looks like you tried to cram it in with just a single 
>>> space indent.
>> Fixed.
>>>
>>> jdk/make/gensrc/GensrcCharsetMapping.gmk, 
>>> jdk/make/gensrc/Gensrc-jdk.jdi.gmk, 
>>> jdk/make/gendata/Gendata-java.base.gmk: indentation in if blocks is 
>>> missing.
>> Fixed.
>>>
>>> jdk/make/launcher/Launcher-java.base.gmk and other launcher make 
>>> files: I thought you and Erik agreed to remove this?
>> The addition of new configure options will be handled in subsequent 
>> pushes.
>>
>> This is one of the places where new features need to be developed
>> to be ready for a mobile/jdk9 push, but should not block getting 
>> basic ios
>> functionality into the open repos.
> Ok.
>
>>
>>>
>>> jdk/make/lib/CoreLibraries.gmk: Why remove ARFLAGS? On macosx, we 
>>> put the -framework options in LIBS rather than LDFLAGS (the latter 
>>> is only used to change the behavior of the linker, not determine 
>>> what to link with.)
>> We ran into conflicts with the use of ARFLAGS  and AR_OUTPUT_OPTION 
>> in NativeCompilation.gmk.
>> It does not appear that both could be set and build properly.
>>
>>     # Generating a static library, ie object file archive.
>>     $$($1_TARGET): $$($1_EXPECTED_OBJS) $$($1_RES) $$($1_VARDEPS_FILE)
>>     $(ECHO) $(LOG_INFO) "Archiving $$($1_STATIC_LIBRARY)"
>>     $(call LogFailures, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_link.log, 
>> $$($1_SAFE_NAME)_link, \
>>         $$($1_AR) $$($1_ARFLAGS) $(AR_OUT_OPTION)$$($1_TARGET) 
>> $$($1_EXPECTED_OBJS) \
>>             $$($1_RES))
>>
>> There are also ARFLAGS references in hotspot/bsd/makefiles that may 
>> need unification
>> when the hotspot new build is set up.
>
> I see. We have not exercised the static library builds that much. Our 
> code certainly looks suspect. I see that on macosx we have ARFLAGS:=-r 
> and AR_OUT_OPTION "rcs ". That doesn't seem right. In fact, even for 
> all unix platforms, the "rcs" is more reasonably thought of as flags 
> than an output option. The ar command does not need an option to 
> specify the output file (unlike on windows).
>
> But I still don't understand your change. You are deleting it for the 
> case of NOT building on macosx. This means that e.g. linux and windows 
> builds will not get ARFLAGS, and this is a regression for those 
> platforms. I can only assume you did this to handle the ios case. If 
> so, I suggest the quick fix is to set ARFLAGS to "" for ios in 
> flags.m4, and then we'll have to clean up this logic properly instead.
>
Here's the fullset of ARFLAGS and AR_OUT_OPTION references

make/common/NativeCompilation.gmk:279:#   ARFLAGS the archiver flags to 
be used
make/common/NativeCompilation.gmk:758:    $1_VARDEPS := $$($1_AR) 
$$($1_ARFLAGS) $$($1_LIBS) \
make/common/NativeCompilation.gmk:767:        $$($1_AR) $$($1_ARFLAGS) 
$(AR_OUT_OPTION)$$($1_TARGET) $$($1_EXPECTED_OBJS) \

The creations of the static library is using the passed in ARFLAGS and 
the global AR_OUT_OPTION.

common/autoconf/flags.m4:133:    ARFLAGS="-r"
common/autoconf/flags.m4:135:    ARFLAGS="-X64"
common/autoconf/flags.m4:138:    ARFLAGS="-nologo -NODEFAULTLIB:MSVCRT"
common/autoconf/flags.m4:140:    ARFLAGS=""
common/autoconf/flags.m4:142:  AC_SUBST(ARFLAGS)
common/autoconf/flags.m4:164:    AR_OUT_OPTION=-out:
common/autoconf/flags.m4:174:    AR_OUT_OPTION='rcs$(SPACE)'
common/autoconf/flags.m4:179:  AC_SUBST(AR_OUT_OPTION)

Platform specific flags are designated for ARFLAGS  macosx, aix, windows
AR_OUTPUT is set for microsoft and non-microsoft.

I can change the ARFLAGS for macosx and ios to "" in flags.m4
or could define AR_OUT_OPTION to "" for macosx and ios ....

common/autoconf/spec.gmk.in:308:AR_OUT_OPTION:=@AR_OUT_OPTION@
common/autoconf/spec.gmk.in:394:ARFLAGS:=@ARFLAGS@

jdk/make/lib/CoreLibraries.gmk:52:      ARFLAGS := $(ARFLAGS), \
jdk/make/lib/CoreLibraries.gmk:408:      ARFLAGS := $(ARFLAGS), \
jdk/make/lib/CoreLibraries.gmk:450:      ARFLAGS := $(ARFLAGS), \

These are the requests for static library builds of libfdlibm and a 
static libjli (aix)

Restore the places that were passing ARFLAGS into NativeCompilation ...

hotspot/make/bsd/makefiles/jsig.make:67:    $(QUIETLY) $(AR) $(ARFLAGS) 
$@ $(JSIG).o
hotspot/make/bsd/makefiles/rules.make:43:LINK_LIB.CC      = $(AR) $(ARFLAGS)

And change the hotspot uses of ARFLAGS to add AR_OUT_OPTION.

Currently we only support full static builds on macosx and ios.

>
>>
>>>
>>> jdk/make/lib/Awt2dLibraries.gmk:  LIBAWT_EXFILES += initIDs.c 
>>> awt/image/cvutils/img_colors.c should not depend on build os. That's 
>>> a target os decision. The same goes for the LIBSPLASHSCREEN_DIRS 
>>> changes. Also, the whole file seems to be excluded on ios so why 
>>> these changes at all? (And, if that ifdef really is correct, you 
>>> need to indent the whole file as well.) And the same goes for 
>>> -framework into LIBS not LDFLAGS (but only if it's really used on ios).
>> Unfortunately our android developer retired, so I'm not totally up to 
>> date on the selective files being excluded.
>> I'm assuming they did not compile on the target platform and were 
>> simply excluded. The mobile platforms
>> are intend as headless compact2 only.  I'm pretty sure the whole file 
>> ios exclusion was done after some
>> number of attempts to get the library to compile.
>
> The android changes looks fine to me.
>
> However, if the long term goal is to actually skip this for ios, then 
> the only change that is needed is the global if target-os != ios, and 
> all other ios/macosx changes could be reverted.
I'll save this change for the cleanup when new switches are available.

>
> Is java.desktop not included in the compact2 profile? And the problem 
> here is that even when building a subset of the modules, we still 
> start by compiling all modules, so you need it not to break during 
> compilation. Arrghh... I think we need to speed up getting a solution 
> were we only compile what's actually needed, so you don't have to mess 
> around with code that's not being used.
Yes, please.
I would like to build for java.compact2 and have only the required 
modules and dependent libraries built.

>
>>
>> This is a another place we expect to fix later with a proper working 
>> of headless builds.
>>
>> I'll fix the LIBS reference to framework before the initial push.
>>
>>>
>>> jdk/make/lib/Lib-java.base.gmk: I'm not sure what's happening here. 
>>> Can you elaborate?
>> On ios there is no libjli. The app container is not allowed to 
>> fork/exec new processes.
>> That is why a separate JavaLauncher interface is provided to ease the 
>> startup of a VM in the current process.
>>
>> The other logic in the selection of symbol file to use is based on 
>> the VM actually
>> being built. e.g. minimal, client, server vm. The static macosx build 
>> only supported
>> server vm. We deplot mobile with minimal vm, but still maintain 
>> client vm for testing purposes.
> And the chained "else ifeq" is since you assume that you only have a 
> single variant, but you still want to put the symbols file in the 
> corresponding directory name? If it's a requirement to build only with 
> a single variant when doing static builds, maybe we should enforce 
> that in configure? Otherwise this code will break if someone builds 
> with --with-jvm-variants=server,client.
Multiple variants are OK.
If there are differences in the exported vm symbol lists,
it will select the smaller vm symbol set for the jdk compiled launchers.
Specifying an exported symbols list for scode clang has two effects.
First it ensures object files are pulled in from the static library and 
second
promotes the visibility of those symbols so they are visible to dlsym
lookups from the current executable. This allows for very minimal changes
in the runtime code between static and shared libraries being used.

For ios the deliverable is the static library and associated symbol list.
The end user decides what is include or excluded from their executable.
e.g only one vm could be included in a staticly linked application.
>
>>
>>
>>>
>>> jdk/make/lib/Lib-java.prefs.gmk, 
>>> jdk/make/lib/Lib-java.instrument.gmk: indentation seems wrong, it 
>>> should be two spaces.
>> Fixed.
>>>
>>> jdk/make/lib/Lib-jdk.jdwp.agent.gmk: Why the LIBDIR stuff?
>> There is still a remnant of arch specific directories in the build 
>> system.
>>
>> Here's the relevant setting from platform.m4
>>
>>   # This is the name of the cpu (but using i386 and amd64 instead of
>>   # x86 and x86_64, respectively), preceeded by a /, to be used when
>>   # locating libraries. On macosx, it's empty, though.
>> OPENJDK_TARGET_CPU_LIBDIR="/$OPENJDK_TARGET_CPU_LEGACY_LIB"
>>   if test "x$OPENJDK_TARGET_OS" = xmacosx; then
>>     OPENJDK_TARGET_CPU_LIBDIR=""
>>   fi
>>   AC_SUBST(OPENJDK_TARGET_CPU_LIBDIR)
>>
> I see. So the static build worked by chance on macosx but not on 
> android. Argh. There is a bug JDK-8066474 on removing this arch dir, 
> we really should get that fixed.
We found the problem initially in the ios build.

It  will be obvious when we need to update the mobile repos when the
OPENJDK_TARGET_CPU_LEGACY_LIB variable is removed.

>
>> Ideally, the build system would allow us to cross compile
>> multiple targets in a single pass.
>>     macosx build system
>>         ios-x86
>>         ios-x86_64
>>         ios-arm
>>         ios-aarch64
>>
>>     then roll up universal static libraries with lipo.
>>
>> Since we do not have that capability we build 4 separate bundles
>> and our users are combining 4 platform bundles and rolling their own
>> universal libraries.
>
> I think we are going to need a continuing discussion on how to solve 
> these needs in the best way.
OK
>
>
>>>
>>> jdk/make/lib/Lib-jdk.management.gmk, jdk/make/lib/Lib-jdk.sctp.gmk: 
>>> Indentation, indentation...
>> Fixed.
>> (Wish there was a tool that could fix the whitespace.)
>>>
>>> jdk/make/lib/LibCommon.gmk: Why the strange order in the android case?
>> I read the android diff to mean use the "linux" native code when 
>> TARGET_OS is android.
>
> You are right. I think my eyes got a bit tired after reading through 
> all that code.
>
> Hm. Let's do it this way for now, but we should really rethink how to 
> express that android is like linux only different.
OK
>
>> +ifeq ($(OPENJDK_TARGET_OS), android)
>> +FindSrcDirsForLib = \
>> +  $(call uniq, $(wildcard \
>> +      $(JDK_TOPDIR)/src/$(strip $1)/*linux*/native/lib$(strip $2) \
>> +      $(JDK_TOPDIR)/src/$(strip $1)/$(OPENJDK_TARGET_OS_TYPE)/native/lib$(strip $2) \
>> +      $(JDK_TOPDIR)/src/$(strip $1)/share/native/lib$(strip $2)))
>> ...
>> +else
>> +FindSrcDirsForLib = \
>> +  $(call uniq, $(wildcard \
>> +      $(JDK_TOPDIR)/src/$(strip $1)/$*(OPENJDK_TARGET_OS)*/native/lib$(strip $2) \
>> +      $(JDK_TOPDIR)/src/$(strip $1)/$(OPENJDK_TARGET_OS_TYPE)/native/lib$(strip $2) \
>> +      $(JDK_TOPDIR)/src/$(strip $1)/share/native/lib$(strip $2)))
>> +endif
>>
>> Will fix the indents there.
>>
>>>
>>> jdk/make/lib/SoundLibraries.gmk: indentation (last if block, the 
>>> rest looks fine)
>> Fixed.
>>>
>>> jdk/src/java.base/share/tools/jproject/ios/frameworks/*...: I'm not 
>>> sure this is the correct location. We've never had a "share/tools" 
>>> directory before in a module. They are needed to building the 
>>> JavaLauncher static library on ios, right? I think they should 
>>> reside with the source code, then, in 
>>> jdk/src/java.base/ios/native/JavaLauncher. (but see below about the 
>>> name).
>> Will fix. We just recently stopped using xcodebuild to create a 
>> proper framework.
>>
>>>
>>> jdk/src/java.base/ios/native/JavaLauncher: Directories should only 
>>> use lower case. Normally, we prefix libraries with "lib" in the 
>>> native directory, directories without "lib" are supposed to be 
>>> programs. Now this is a static library and we haven't had many of 
>>> these before, but libjli is static (or can be) and still have the 
>>> lib prefix, so I'd argue that thisshould be 
>>> jdk/src/java.base/ios/native/libjavalauncher instead.
>> Not just a library.
>> Our deliverable artifact is a framework on ios.
>>
>> The include file and static library are packaged so they can drop
>> into an Xcode project and all the proper connections are made.
>> This is the native component that will launch the VM in the current 
>> process.
>
> But the native code compiles to a library. In SetupNativeCompilation, 
> you have:
> OUTPUT_DIR := $(SUPPORT_OUTPUTDIR)/native/java.base/libjavalauncher, \
>
> The idea is that the name here should match the source code directory. 
> We're working on getting the setup macros to get this connection 
> automatically, so you only would have to specifify something along the 
> lines of:
> SetupNativeLibrary(libjavalauncher,
>   CFLAGS := ...)
> and it will automatically infer where to find the source code and 
> where to store the output. All other libraries adhere to this 
> standard, so please don't break this for us.
>
> I'm looking a bit more closely now at the newly added files here.
>
> I think you are making this more complicated than what's needed. Drop 
> the libocldvk and share/javalauncher_api. Instead, call all of it 
> libjavalauncher. Then when we finish the automatic setup the android 
> launcher will pick up the shared api and the ios launcher will pick up 
> the shared api, and the platform specific files, all by themselves.
>
> The native compilation setup in JavaLauncher.gmk is also overly 
> complicated. SRC points to the base source dir. You don't have to 
> explicitly name the files. You don't have to include both $(OCLDVK) 
> and $(OCLDVK)/net, the top dir is enough.

I'm going to save the JavaLauncher cleanup to a subsequent push.
There are some additional code coming before we have the full android 
platform supported
in the mobile/dev repos.
>
>>
>>>
>>> make/lib/JavaLauncher.gmk: For consistency (and to clarify that this 
>>> is libraries, not launchers), it should be named 
>>> JavaLauncherLibraries.gmk. The android part creates a jar. This 
>>> should not be done in the native phase, but in the Java phase. 
>>> OCLDVK_OUTPUTDIR  is defined but not used. It's a bit sad to commit 
>>> new code with WARNINGS_AS_ERRORS_clang := false. :-( Can't you fix 
>>> the warnings instead?
>> Even though we compile a Java 5 byte code jar file, it will be 
>> processed via dex before it is actually linked into an android 
>> executable.
> This is something that's still missing, right?
While it is possible to run the java command from an adb shell on an 
android device,
the real target of the mobile project on android is the encapsulated 
application.

That build procedure is outside the scope of a jdk build.
We will be providing a sample HelloWorld project on each of the target
platforms that can drop in a "jre" and perform the final application build
step with the native toolchain.

Note: that a static build only requires symbol files and static 
libraries at
application build time and will not be copied to a deployed application
runtime image.

In a similar manner the dalvik jar file will be consumed/transformed in the
application build process.
>
>> This is the native side that will launch a Java VM within the current 
>> process.
>>
>> We called in JavaLauncher because it was a replacement for libjli.
>>
>>
>>
>> I'll investigate the unused OCLDVK_OUTPUTDIR and the WARNINGS_AS_ERRORS.
>> There is probably some shared linux code that does not compile 
>> cleanly with the android toolchain.
>
> The WARNINGS_AS_ERRORS is on the ios side. It only compiles three 
> newly added files.
I will follow up on the warnings at a later time.
>
>
>>>
>>> ---
>>>
>>> This was what I could find right now. I have not looked at hotspot 
>>> build changes, nor any source code changes.
>>
>> Thanks I appreciate all these comments.
> Thanks. I apologize once more for coming with so much feedback after 
> so long time.
>
>> My hope is that we will have much smaller reviewable changesets
>> going forward.
>
> Let's hope. :-)
>
> /Magnus
>
>>>
>>> /Magnus
>>
>



From gary.adams at oracle.com  Fri Dec 18 19:39:55 2015
From: gary.adams at oracle.com (Gary Adams)
Date: Fri, 18 Dec 2015 14:39:55 -0500
Subject: Follow up bugs from the initial review comments
Message-ID: <5674610B.6050806@oracle.com>

I deferred a number of changes in order to get the first set of sources 
out to the mobile/dev repos.
Just so we don't lose sight of those changes, I've filed a few bugs that 
can be addressed independently
going forward.

  JDK-8145802: CPPFLAGS sysroot support
  JDK-8145804: ARFLAGS versus AR_OUT_OPTION conflicts in static builds
  JDK-8145806: OPENJDK_TARGET_CPU_LEGACY_LIB build variable will be retired
  JDK-8145807: JavaLauncher should use standard naming and build constructs
  JDK-8145809: Demo projects for HelloWorld for ios and android
  JDK-8145811: Fix compiler warnings


From martinrb at google.com  Fri Dec 18 19:59:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 18 Dec 2015 11:59:09 -0800
Subject: RFR 4823133: RandomAccessFile.length() is not thread-safe
In-Reply-To: <56740B97.5000901@oracle.com>
References: <562A9DE1.4070208@oracle.com> <56695984.7030204@oracle.com>
	<56704076.8050203@Oracle.com>
	<CA+kOe08k4S5vejaLeMHghG6HkgAokEUubHHbgROvoiDUq-N2BQ@mail.gmail.com>
	<56740B97.5000901@oracle.com>
Message-ID: <CA+kOe08rV9J7fDQnzJBh0=821F+GZ3h7z0Ks+nq_6Yh1gRiFuA@mail.gmail.com>

On Fri, Dec 18, 2015 at 5:35 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> On 2015-12-15 18:25, Martin Buchholz wrote:
>>
>> _FILE_OFFSET_BITS is generally an all-or-nothing thing, because it
>> affects interoperability between translation units.  It would be good
>> to convert all of the JDK build to use -D_FILE_OFFSET_BITS=64, but
>> that would be a big job.  So traditionally the JDK has instead used
>> the functions made available via _LARGEFILE64_SOURCE.  But that is
>> also a JDK-wide job now, because every call to plain stat in the
>> source code is broken on 32-bit systems with 64-bit inodes, which are
>> becoming more common.
>>
>> I recommend the _FILE_OFFSET_BITS=64 strategy, but it's probably a job
>> for build-dev, not core-libs-dev.
>
>
> If I understand things correctly, then setting _FILE_OFFSET_BITS=64 would
> mean two things:
> 1) Just pass this additional define to all C files being compiled (a build
> change)
> 2) Update all calls to file operating functions to make sure the proper
> 64-bit types are used (changes in source code).
>
> The change for 1) is a trivial one liner, while getting 2) correct is a
> serious undertaking in the source code.

If everyone is properly pairing up their function calls with proper
types (i.e. using off_t consistently), then everything should Just
Work.

Such a change must be done by the
> component teams, not the build team.

I think this is an openjdk cultural problem - changes like this can
and should be done by one person, with help from component teams where
necessary.  It's safer to add _FILE_OFFSET_BITS=64 everywhere at once
(although hotspot and libraries can probably be cleanly separated) to
avoid type size disagreement between translation units.

For bonus points, we can later change all of those *64 functions back
to their standard equivalents.

With that said, I think it is a
> reasonable change and I'll support it as much as I can. But as the division
> of labour is done here, it's not the work of the build team to go and make
> heavy modifications to the product source code.


From thomas.stuefe at gmail.com  Fri Dec 18 21:11:39 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 18 Dec 2015 22:11:39 +0100
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <566AE88C.3040701@oracle.com>
References: <566AE88C.3040701@oracle.com>
Message-ID: <CAA-vtUwMxj2s5WrgD829quWjGmmSU9f4xEO1SeOWKZ9Yr6wMXw@mail.gmail.com>

Hi Gary,

In the Linux os layer - especially in os_linux.cpp - I see you have
reintroduced old coding we just painstakingly removed because it was not
needed for modern Linuxes anymore. For instance, coding dealing with old
Linuxthreads (vs Nptl, which is ubiquitous nowadays) or workarounds for old
glibc bugs. Is this really needed for Android? Or is this just a merge
error?

Kind regards, Thomas
On Dec 11, 2015 16:15, "Gary Adams" <gary.adams at oracle.com> wrote:

> Here's the initial upload of changes that provides support for the ios and
> android ports
> for the mobile/dev repos. While there have been some preliminary reviews
> of the code,
> there is still more work required before we will look for more thorough
> reviews
> and an integration to mobile/jdk9 repos.
>
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
>   Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/
>
>
> Here's a simple configure script to generate a ios-x86_64 build for use
> with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)
>
> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
>
> bash ../../configure \
>     --openjdk-target=x86_64-macos-ios \
>     --with-boot-jdk=$JAVA_HOME \
>     --disable-warnings-as-errors \
>     --disable-headful \
>     --enable-static-build=yes \
>     --with-jvm-variants=minimal1
>
>
> Also, tested with i586-macos-ios target for 32 bit
> with a locally built --with-freetype 2.6.2.
>


From bob.vandette at oracle.com  Fri Dec 18 21:16:35 2015
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 18 Dec 2015 16:16:35 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <CAA-vtUwMxj2s5WrgD829quWjGmmSU9f4xEO1SeOWKZ9Yr6wMXw@mail.gmail.com>
References: <566AE88C.3040701@oracle.com>
	<CAA-vtUwMxj2s5WrgD829quWjGmmSU9f4xEO1SeOWKZ9Yr6wMXw@mail.gmail.com>
Message-ID: <A97613FE-2F5C-4643-837B-43A385519B91@oracle.com>

I caught that and gave Gary an updated set of os_linux* files that hopefully corrected this.

Here?s the updated changes that Gary just pushed today.

http://hg.openjdk.java.net/mobile/dev/hotspot/rev/f1acc8fa34b8


Bob.

> On Dec 18, 2015, at 4:11 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi Gary,
> 
> In the Linux os layer - especially in os_linux.cpp - I see you have
> reintroduced old coding we just painstakingly removed because it was not
> needed for modern Linuxes anymore. For instance, coding dealing with old
> Linuxthreads (vs Nptl, which is ubiquitous nowadays) or workarounds for old
> glibc bugs. Is this really needed for Android? Or is this just a merge
> error?
> 
> Kind regards, Thomas
> On Dec 11, 2015 16:15, "Gary Adams" <gary.adams at oracle.com> wrote:
> 
>> Here's the initial upload of changes that provides support for the ios and
>> android ports
>> for the mobile/dev repos. While there have been some preliminary reviews
>> of the code,
>> there is still more work required before we will look for more thorough
>> reviews
>> and an integration to mobile/jdk9 repos.
>> 
>>  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
>>  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/
>> 
>> 
>> Here's a simple configure script to generate a ios-x86_64 build for use
>> with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)
>> 
>> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
>> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
>> 
>> bash ../../configure \
>>    --openjdk-target=x86_64-macos-ios \
>>    --with-boot-jdk=$JAVA_HOME \
>>    --disable-warnings-as-errors \
>>    --disable-headful \
>>    --enable-static-build=yes \
>>    --with-jvm-variants=minimal1
>> 
>> 
>> Also, tested with i586-macos-ios target for 32 bit
>> with a locally built --with-freetype 2.6.2.
>> 



From kim.barrett at oracle.com  Sat Dec 19 00:41:49 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 18 Dec 2015 19:41:49 -0500
Subject: RFR: JDK-8145549 Add support for Visual Studio 2015 Community
	edition
In-Reply-To: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
References: <7B657FB8-B581-4AB2-81C1-877B4B1BD658@oracle.com>
Message-ID: <C6913D57-E2DD-4A07-B9E9-C53BA239507C@oracle.com>

On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> There is an interest from the community to build OpenJDK using Visual Studio 2015 Community edition. 
> 
> This patch is provided by Timo Kinnunen <timo.kinnunen at gmail.com>. I am sponsoring this patch.
> 
> The changes to the source code files are mostly casts to uintptr_t, but there are some other changes as well.
> 
> I'm not quite sure who's the owner of all these files. If I'm missing some group, please help me and forward the mail to them.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145549
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01
> 
> /Magnus

I only looked at hotspot files.

Breaking this up into smaller and more focused chunks would be nice.
Large changes that do 17 different things are hard to deal with.

I think the various casts to uintptr_t (commented with "What???"
below) should be done differently.  They are addressing problems of
differences between pointer size and various integer sizes, and
conversions between them.  I think in some cases there is a poorly
chosen surrounding type involved.  For the 0xdeadbeef cases, there
probably ought to be a centralized helper for that sort of thing,
since doing it properly on across different platforms might be tricky,
and that trickiness ought to be in one place.

There are a couple of "TBD"s below that I need to spend more time on.

------------------------------------------------------------------------------
Sprinkling lots of files with the following seems like a bad idea.

#if _MSC_VER >= 1900
#pragma warning( disable : 4091 ) // typedef ignored on left when no variable is declared
#endif

Especially since these warnings may indicate actual bugs.
https://msdn.microsoft.com/en-us/library/eehkcz60.aspx

------------------------------------------------------------------------------ 
hotspot/src/share/vm/utilities/globalDefinitions.hpp
1062 #define       badAddress        ((address)(intptr_t)::badAddressVal)

Change the type of badAddressVal to intptr_t instead.

------------------------------------------------------------------------------ 
hotspot/src/share/vm/runtime/os.cpp
 127 #elif defined(_WIN32) && _MSC_VER > 1800
 128   const time_t zone = _timezone;

Why does (recent) Windows need special handling here?

------------------------------------------------------------------------------ 
hotspot/src/share/vm/utilities/globalDefinitions_visCPP.hpp
 198 #if _MSC_VER <= 1800

Shouldn't that be "<" the version that introduced the missing
function?

------------------------------------------------------------------------------ 
hotspot/src/share/vm/prims/whitebox.cpp
1286   return (jlong)(uintptr_t)ikh->constants();

What???

------------------------------------------------------------------------------
hotspot/src/share/vm/opto/type.cpp
  53   { Bad,             T_ILLEGAL,    "bad",           false, (int)Node::NotAMachineReg, relocInfo::none          },  // Bad
  61   { Bad,             T_ILLEGAL,    "tuple:",        false, (int)Node::NotAMachineReg, relocInfo::none          },  // Tuple
  62   { Bad,             T_ARRAY,      "array:",        false, (int)Node::NotAMachineReg, relocInfo::none          },  // Array

These are narrowing conversions in brace initializers, which are
forbidden by C++11.  The type of the member is int, while the
initialization expressions are non-literal uint.

In my opinion, it would be better to figure out how to fix the type
mismatch than to sprinkle with casts.

A way to look for these that doesn't require VS2015 would be to use
g++ -Wnarrowing.

------------------------------------------------------------------------------ 
hotspot/src/share/vm/opto/split_if.cpp
 258   Node *prior_n = (Node*)(uintptr_t)0xdeadbeef;
 305   prior_n = (Node*)(uintptr_t)0xdeadbeef;  // Reset IDOM walk

What???

------------------------------------------------------------------------------ 
hotspot/src/share/vm/opto/gcm.cpp
1448   _node_latency = (GrowableArray<uint> *)(uintptr_t)0xdeadbeef;

What???

------------------------------------------------------------------------------ 
hotspot/src/share/vm/opto/compile.cpp
2398   _cfg     = (PhaseCFG*)(uintptr_t)0xdeadbeef;
2399   _regalloc = (PhaseChaitin*)(uintptr_t)0xdeadbeef;

What???

------------------------------------------------------------------------------
hotspot/src/share/vm/opto/buildOopMap.cpp
 618     Block *pred = (Block*)(uintptr_t)0xdeadbeef;

What???

------------------------------------------------------------------------------ 
hotspot/src/share/vm/oops/typeArrayOop.hpp
 132     *long_at_addr(which) = (jlong)contents;

Yes!  Fortunately, it looks like metadata_at_put is never called.

------------------------------------------------------------------------------ 
hotspot/src/share/vm/memory/allocation.hpp
  38 #if defined _WINDOWS && _MSC_VER >= 1900
  39  // 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc
  40 #pragma warning( disable : 4577 )
  41 #endif

Another C++11 change.  Dynamic exception specifications
(e.g. "throw(TYPELISTopt)" were deprecated by C++11.  I think MSVC++
has always implemented "throw()" as "throwing an exception invokes
undefined behavior".  C++11 introduced "noexcept".

I think it would be better to turn this off in the build system,
rather than with with this conditional #pragma.

Alternatively, perhaps replace existing uses of "throw()" with a
VM_NOEXCEPT macro (or some other name) which expands into "throw()" or
"noexcept" depending on the compiler and options.

------------------------------------------------------------------------------ 
hotspot/src/share/vm/jvmci/jvmciCompilerToVM.cpp
-- many, many lines --

Ouch!  I'm not looking at this in detail...

------------------------------------------------------------------------------ 
hotspot/src/share/vm/adlc/arena.hpp
  74   // Usual (non-placement) deallocation function to allow placement delete use size_t
  75   // See 3.7.4.2 [basic.stc.dynamic.deallocation] paragraph 2.
  76   void  operator delete(void* p);

and associated code in the .cpp file.

--- TBD

------------------------------------------------------------------------------ 
hotspot/agent/src/share/native/sadis.c
  96       return (int)strlen(buf);

--- TBD

------------------------------------------------------------------------------



From thomas.stuefe at gmail.com  Sat Dec 19 02:17:09 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 19 Dec 2015 03:17:09 +0100
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <A97613FE-2F5C-4643-837B-43A385519B91@oracle.com>
References: <566AE88C.3040701@oracle.com>
	<CAA-vtUwMxj2s5WrgD829quWjGmmSU9f4xEO1SeOWKZ9Yr6wMXw@mail.gmail.com>
	<A97613FE-2F5C-4643-837B-43A385519B91@oracle.com>
Message-ID: <CAA-vtUzm_AwRnACWcieTHhq_cBaai5XLr4ZuOwQUMfo9-6km-w@mail.gmail.com>

Hi Bob and Gary,

Thank you for correcting this! Respect also on this large porting effort,
this looks like a lot of work and I am curious how this will turn out.

I took a short look at your changes - especially the android-related
changes  - and have a number of further questions and suggestions . I hope
that this is okay and the door is not already closed.

I'm away from any computer however (ironically typing this from an android
device, so anything weird is due to auto correct :), so before Monday I
will not be able to do anything.

I also think that this may be interesting to hotspot-runtime, because the
changes to the OS layer are somewhat extensive, so I'll take the freedom
and put them on the recipient list.

Kind regards, Thomas
On Dec 18, 2015 22:16, "Bob Vandette" <bob.vandette at oracle.com> wrote:

> I caught that and gave Gary an updated set of os_linux* files that
> hopefully corrected this.
>
> Here?s the updated changes that Gary just pushed today.
>
> http://hg.openjdk.java.net/mobile/dev/hotspot/rev/f1acc8fa34b8
>
>
> Bob.
>
> > On Dec 18, 2015, at 4:11 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
> >
> > Hi Gary,
> >
> > In the Linux os layer - especially in os_linux.cpp - I see you have
> > reintroduced old coding we just painstakingly removed because it was not
> > needed for modern Linuxes anymore. For instance, coding dealing with old
> > Linuxthreads (vs Nptl, which is ubiquitous nowadays) or workarounds for
> old
> > glibc bugs. Is this really needed for Android? Or is this just a merge
> > error?
> >
> > Kind regards, Thomas
> > On Dec 11, 2015 16:15, "Gary Adams" <gary.adams at oracle.com> wrote:
> >
> >> Here's the initial upload of changes that provides support for the ios
> and
> >> android ports
> >> for the mobile/dev repos. While there have been some preliminary reviews
> >> of the code,
> >> there is still more work required before we will look for more thorough
> >> reviews
> >> and an integration to mobile/jdk9 repos.
> >>
> >>  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
> >>  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/
> >>
> >>
> >> Here's a simple configure script to generate a ios-x86_64 build for use
> >> with the iphone simulator. (uses homebrew 64 bit freetype from
> pkgconfig)
> >>
> >> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
> >> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
> >>
> >> bash ../../configure \
> >>    --openjdk-target=x86_64-macos-ios \
> >>    --with-boot-jdk=$JAVA_HOME \
> >>    --disable-warnings-as-errors \
> >>    --disable-headful \
> >>    --enable-static-build=yes \
> >>    --with-jvm-variants=minimal1
> >>
> >>
> >> Also, tested with i586-macos-ios target for 32 bit
> >> with a locally built --with-freetype 2.6.2.
> >>
>
>


From boaznahum at gmail.com  Sat Dec 19 21:04:58 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Sat, 19 Dec 2015 21:04:58 +0000
Subject: Build failure on windows 'freetypeScaler.c'
In-Reply-To: <56744FE4.4030404@oracle.com>
References: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
	<56744FE4.4030404@oracle.com>
Message-ID: <CAB_DFWZ5Tgb573uJzupM4F6NjKau5zvcfbp1ghrUZwTdKrph1A@mail.gmail.com>

I pull the last update, since then, when running running 'make images' all
calls to
'.../build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
end with 'Segmentation fault'
Thx
Boaz

/usr/bin/bash: line 1:  9888 Segmentation fault
 /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
-c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
build.tools.spp.Spp -Kint -KintegralType -K -Dtype=int -DType=Int
-Dfulltype=integer -DFulltype=Integer -Dstreamtype= -DStreamtype= -Dx=i
-Dmemtype=int -DMemtype=Int -DSwaptype=Int -DfromBits= -DtoBits=
-DLG_BYTES_PER_VALUE=2 -DBYTES_PER_VALUE="(1 << 2)" -DBO=B -Dswap= -DRW=R
-Kro -Da=an -DA=An -KboB <
/cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
>
/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java.tmpGensrcBuffer.gmk:354:
recipe for target
'/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java'
failed

make[3]: ***
[/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java]
Error 139
make[3]: *** Waiting for unfinished jobs....
/usr/bin/bash: line 1:  2996 Segmentation fault
 /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
-c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
build.tools.spp.Spp -Klong -KintegralType -K -Dtype=long -DType=Long
-Dfulltype=long -DFulltype=Long -Dstreamtype= -DStreamtype= -Dx=l
-Dmemtype=long -DMemtype=Long -DSwaptype=Long -DfromBits= -DtoBits=
-DLG_BYTES_PER_VALUE=3 -DBYTES_PER_VALUE="(1 << 3)" -DBO=B -Dswap= -DRW=
-Krw -Da=a -DA=A -KboB <
/cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
>
/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java.tmp
GensrcBuffer.gmk:355: recipe for target
'/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java'
failedmake[3]: ***
[/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java]
Error 139

GensrcBuffer.gmk:356: recipe for target
'/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java'
failed
/usr/bin/bash: line 1: 10376 Segmentation fault
 /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
-c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
build.tools.spp.Spp -Klong -KintegralType -K -Dtype=long -DType=Long
-Dfulltype=long -DFulltype=Long -Dstreamtype= -DStreamtype= -Dx=l
-Dmemtype=long -DMemtype=Long -DSwaptype=Long -DfromBits= -DtoBits=
-DLG_BYTES_PER_VALUE=3 -DBYTES_PER_VALUE="(1 << 3)" -DBO=B -Dswap= -DRW=R
-Kro -Da=a -DA=A -KboB <
/cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
>
/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java.tmp
make[3]: ***
[/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java]
Error 139
make/Main.gmk:103: recipe for target 'java.base-gensrc-jdk' failedmake[2]:
*** [java.base-gensrc-jdk] Error 1


On Fri, Dec 18, 2015 at 8:26 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Fix pushed
>
> Maurizio
>
> On 18/12/15 13:16, Boaz Nahum wrote:
> > Hi
> >
> > Lately, I have this error:
> >
> >
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> > : error C2220: warning treated as error - no 'object' file generated
> >
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> > : warning C4101: 'stream' : unreferenced local variable
> >
> > I comment out:
> >
> > static void freeNativeResources(JNIEnv *env, FTScalerInfo* scalerInfo) {
> > //    void *stream;
> >
> >
> > And now it works.
> >
> > Thx
> > Boaz
>
>


From magnus.ihse.bursie at oracle.com  Sun Dec 20 00:02:03 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Sun, 20 Dec 2015 01:02:03 +0100
Subject: Build failure on windows 'freetypeScaler.c'
In-Reply-To: <CAB_DFWZ5Tgb573uJzupM4F6NjKau5zvcfbp1ghrUZwTdKrph1A@mail.gmail.com>
References: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
	<56744FE4.4030404@oracle.com>
	<CAB_DFWZ5Tgb573uJzupM4F6NjKau5zvcfbp1ghrUZwTdKrph1A@mail.gmail.com>
Message-ID: <5675EFFB.9060208@oracle.com>

On 2015-12-19 22:04, Boaz Nahum wrote:
> I pull the last update, since then, when running running 'make images' all
> calls to
> '.../build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
> end with 'Segmentation fault'

If you have build problems with no local changes that can have caused 
it, the sledgehammers to use (in increasing brutality) are:
1) make clean
2) make dist-clean
This will remove your configuration. "make print-configuration" before 
will give you the command line you used for configure, if you need to be 
reminded of it.
3) remove the forest and re-clone it.

My guess is that your problems can be solved by 1), but if not, try with 
a bigger hammer.

/Magnus

> Thx
> Boaz
>
> /usr/bin/bash: line 1:  9888 Segmentation fault
>   /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> -c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
> build.tools.spp.Spp -Kint -KintegralType -K -Dtype=int -DType=Int
> -Dfulltype=integer -DFulltype=Integer -Dstreamtype= -DStreamtype= -Dx=i
> -Dmemtype=int -DMemtype=Int -DSwaptype=Int -DfromBits= -DtoBits=
> -DLG_BYTES_PER_VALUE=2 -DBYTES_PER_VALUE="(1 << 2)" -DBO=B -Dswap= -DRW=R
> -Kro -Da=an -DA=An -KboB <
> /cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java.tmpGensrcBuffer.gmk:354:
> recipe for target
> '/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java'
> failed
>
> make[3]: ***
> [/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java]
> Error 139
> make[3]: *** Waiting for unfinished jobs....
> /usr/bin/bash: line 1:  2996 Segmentation fault
>   /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> -c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
> build.tools.spp.Spp -Klong -KintegralType -K -Dtype=long -DType=Long
> -Dfulltype=long -DFulltype=Long -Dstreamtype= -DStreamtype= -Dx=l
> -Dmemtype=long -DMemtype=Long -DSwaptype=Long -DfromBits= -DtoBits=
> -DLG_BYTES_PER_VALUE=3 -DBYTES_PER_VALUE="(1 << 3)" -DBO=B -Dswap= -DRW=
> -Krw -Da=a -DA=A -KboB <
> /cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java.tmp
> GensrcBuffer.gmk:355: recipe for target
> '/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java'
> failedmake[3]: ***
> [/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java]
> Error 139
>
> GensrcBuffer.gmk:356: recipe for target
> '/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java'
> failed
> /usr/bin/bash: line 1: 10376 Segmentation fault
>   /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> -c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
> build.tools.spp.Spp -Klong -KintegralType -K -Dtype=long -DType=Long
> -Dfulltype=long -DFulltype=Long -Dstreamtype= -DStreamtype= -Dx=l
> -Dmemtype=long -DMemtype=Long -DSwaptype=Long -DfromBits= -DtoBits=
> -DLG_BYTES_PER_VALUE=3 -DBYTES_PER_VALUE="(1 << 3)" -DBO=B -Dswap= -DRW=R
> -Kro -Da=a -DA=A -KboB <
> /cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java.tmp
> make[3]: ***
> [/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java]
> Error 139
> make/Main.gmk:103: recipe for target 'java.base-gensrc-jdk' failedmake[2]:
> *** [java.base-gensrc-jdk] Error 1
>
>
> On Fri, Dec 18, 2015 at 8:26 PM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> Fix pushed
>>
>> Maurizio
>>
>> On 18/12/15 13:16, Boaz Nahum wrote:
>>> Hi
>>>
>>> Lately, I have this error:
>>>
>>>
>> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
>>> : error C2220: warning treated as error - no 'object' file generated
>>>
>> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
>>> : warning C4101: 'stream' : unreferenced local variable
>>>
>>> I comment out:
>>>
>>> static void freeNativeResources(JNIEnv *env, FTScalerInfo* scalerInfo) {
>>> //    void *stream;
>>>
>>>
>>> And now it works.
>>>
>>> Thx
>>> Boaz
>>



From boaznahum at gmail.com  Sun Dec 20 21:49:00 2015
From: boaznahum at gmail.com (Boaz Nahum)
Date: Sun, 20 Dec 2015 21:49:00 +0000
Subject: Build failure on windows 'freetypeScaler.c'
In-Reply-To: <5675EFFB.9060208@oracle.com>
References: <CAB_DFWbEBRPvu3pnTcz9XQKAcnknvUKdZHtP+ADJ-P8h86L7gA@mail.gmail.com>
	<56744FE4.4030404@oracle.com>
	<CAB_DFWZ5Tgb573uJzupM4F6NjKau5zvcfbp1ghrUZwTdKrph1A@mail.gmail.com>
	<5675EFFB.9060208@oracle.com>
Message-ID: <CAB_DFWYS_o7K41Hckb5-x2wdOOTM03RoQNirmBqxV2HeCoRaSA@mail.gmail.com>

2) did the trick.
Thanks
Boaz

On Sun, 20 Dec 2015 at 2:02 AM Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2015-12-19 22:04, Boaz Nahum wrote:
> > I pull the last update, since then, when running running 'make images'
> all
> > calls to
> >
> '.../build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe'
> > end with 'Segmentation fault'
>
> If you have build problems with no local changes that can have caused
> it, the sledgehammers to use (in increasing brutality) are:
> 1) make clean
> 2) make dist-clean
> This will remove your configuration. "make print-configuration" before
> will give you the command line you used for configure, if you need to be
> reminded of it.
> 3) remove the forest and re-clone it.
>
> My guess is that your problems can be solved by 1), but if not, try with
> a bigger hammer.
>
> /Magnus
>
> > Thx
> > Boaz
> >
> > /usr/bin/bash: line 1:  9888 Segmentation fault
> >
>  /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> > -c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
> > build.tools.spp.Spp -Kint -KintegralType -K -Dtype=int -DType=Int
> > -Dfulltype=integer -DFulltype=Integer -Dstreamtype= -DStreamtype= -Dx=i
> > -Dmemtype=int -DMemtype=Int -DSwaptype=Int -DfromBits= -DtoBits=
> > -DLG_BYTES_PER_VALUE=2 -DBYTES_PER_VALUE="(1 << 2)" -DBO=B -Dswap= -DRW=R
> > -Kro -Da=an -DA=An -KboB <
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java.tmpGensrcBuffer.gmk:354:
> > recipe for target
> >
> '/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java'
> > failed
> >
> > make[3]: ***
> >
> [/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsIntBufferRB.java]
> > Error 139
> > make[3]: *** Waiting for unfinished jobs....
> > /usr/bin/bash: line 1:  2996 Segmentation fault
> >
>  /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> > -c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
> > build.tools.spp.Spp -Klong -KintegralType -K -Dtype=long -DType=Long
> > -Dfulltype=long -DFulltype=Long -Dstreamtype= -DStreamtype= -Dx=l
> > -Dmemtype=long -DMemtype=Long -DSwaptype=Long -DfromBits= -DtoBits=
> > -DLG_BYTES_PER_VALUE=3 -DBYTES_PER_VALUE="(1 << 3)" -DBO=B -Dswap= -DRW=
> > -Krw -Da=a -DA=A -KboB <
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java.tmp
> > GensrcBuffer.gmk:355: recipe for target
> >
> '/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java'
> > failedmake[3]: ***
> >
> [/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferB.java]
> > Error 139
> >
> > GensrcBuffer.gmk:356: recipe for target
> >
> '/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java'
> > failed
> > /usr/bin/bash: line 1: 10376 Segmentation fault
> >
>  /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
> > -c /cygdrive/f/Dev/JDKs/8/jdk1.8.0_20/bin/java -Xms32M -Xmx512M -cp
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/buildtools/jdk_tools_classes
> > build.tools.spp.Spp -Klong -KintegralType -K -Dtype=long -DType=Long
> > -Dfulltype=long -DFulltype=Long -Dstreamtype= -DStreamtype= -Dx=l
> > -Dmemtype=long -DMemtype=Long -DSwaptype=Long -DfromBits= -DtoBits=
> > -DLG_BYTES_PER_VALUE=3 -DBYTES_PER_VALUE="(1 << 3)" -DBO=B -Dswap= -DRW=R
> > -Kro -Da=a -DA=A -KboB <
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/jdk/src/java.base/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template
> >
> /cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java.tmp
> > make[3]: ***
> >
> [/cygdrive/f/Dev/JDKBuild/valhalla/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBufferAsLongBufferRB.java]
> > Error 139
> > make/Main.gmk:103: recipe for target 'java.base-gensrc-jdk'
> failedmake[2]:
> > *** [java.base-gensrc-jdk] Error 1
> >
> >
> > On Fri, Dec 18, 2015 at 8:26 PM Maurizio Cimadamore <
> > maurizio.cimadamore at oracle.com> wrote:
> >
> >> Fix pushed
> >>
> >> Maurizio
> >>
> >> On 18/12/15 13:16, Boaz Nahum wrote:
> >>> Hi
> >>>
> >>> Lately, I have this error:
> >>>
> >>>
> >>
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> >>> : error C2220: warning treated as error - no 'object' file generated
> >>>
> >>
> f:/Dev/JDKBuild/valhalla/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(106)
> >>> : warning C4101: 'stream' : unreferenced local variable
> >>>
> >>> I comment out:
> >>>
> >>> static void freeNativeResources(JNIEnv *env, FTScalerInfo* scalerInfo)
> {
> >>> //    void *stream;
> >>>
> >>>
> >>> And now it works.
> >>>
> >>> Thx
> >>> Boaz
> >>
>
>


From ioi.lam at oracle.com  Mon Dec 21 06:05:26 2015
From: ioi.lam at oracle.com (Ioi Lam)
Date: Sun, 20 Dec 2015 22:05:26 -0800
Subject: RFR (XS) 8145271 - stand-alone hotspot build is broken
Message-ID: <567796A6.5050209@oracle.com>

Please review a very small fix:

    http://cr.openjdk.java.net/~iklam/jdk9/8145271-standalone-hotspot-build/

Bug: stand-alone hotspot build is broken

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

Summary of fix:

    This was broken by the recent JDK version changes.

    The fix is to add "export" to variables such as VERSION_MAJOR so
    that they can be inherited by "make" sub processes.

Tests:

     JPRT

Thanks
- Ioi


From magnus.ihse.bursie at oracle.com  Mon Dec 21 07:50:48 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Mon, 21 Dec 2015 08:50:48 +0100
Subject: RFR (XS) 8145271 - stand-alone hotspot build is broken
In-Reply-To: <567796A6.5050209@oracle.com>
References: <567796A6.5050209@oracle.com>
Message-ID: <8D2AE418-D1E3-42DF-8A19-7D545C0DDB90@oracle.com>

Looks good to me. 

/Magnus

> 21 dec. 2015 kl. 07:05 skrev Ioi Lam <ioi.lam at oracle.com>:
> 
> Please review a very small fix:
> 
>   http://cr.openjdk.java.net/~iklam/jdk9/8145271-standalone-hotspot-build/
> 
> Bug: stand-alone hotspot build is broken
> 
>   https://bugs.openjdk.java.net/browse/JDK-8145271
> 
> Summary of fix:
> 
>   This was broken by the recent JDK version changes.
> 
>   The fix is to add "export" to variables such as VERSION_MAJOR so
>   that they can be inherited by "make" sub processes.
> 
> Tests:
> 
>    JPRT
> 
> Thanks
> - Ioi


From erik.joelsson at oracle.com  Mon Dec 21 11:00:42 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 21 Dec 2015 12:00:42 +0100
Subject: RFR: JDK-8145789: Switch JDK 9 to use Jib in JPRT
Message-ID: <5677DBDA.5000508@oracle.com>

Hello,

With Jib support in JDK 9, it would be nice to start using it in JPRT 
instead of having JPRT having to track dependencies and configurations. 
This change enables Jib in JPRT and disables all the JPRT functionality 
for tracking dependencies (build.needs and most configure args).

Bug: https://bugs.openjdk.java.net/browse/JDK-8145789
Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.01/

/Erik


From tim.bell at oracle.com  Mon Dec 21 15:39:18 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 21 Dec 2015 07:39:18 -0800
Subject: RFR: JDK-8145789: Switch JDK 9 to use Jib in JPRT
In-Reply-To: <5677DBDA.5000508@oracle.com>
References: <5677DBDA.5000508@oracle.com>
Message-ID: <56781D26.5050200@oracle.com>

Erik:

> With Jib support in JDK 9, it would be nice to start using it in JPRT 
> instead of having JPRT having to track dependencies and 
> configurations. This change enables Jib in JPRT and disables all the 
> JPRT functionality for tracking dependencies (build.needs and most 
> configure args).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145789
> Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.01

Looks good to me, as long as test builds work OK.

TIm



From silvia.l.vidaurre at lmco.com  Mon Dec 21 20:03:47 2015
From: silvia.l.vidaurre at lmco.com (Vidaurre, Silvia L)
Date: Mon, 21 Dec 2015 20:03:47 +0000
Subject: OpenJDK9 Build Error on Linux 32-bit
Message-ID: <9889B6346DBB6B4A95CDDCB87D5A11E502BA2239@HVXDSP24.us.lmco.com>

Hello,

I just downloaded OpenJDK9, and am trying to build it on 32bit RHEL 5.11 with g++ 4.2.1, and I am getting this error from commandLineFlagRangeList.cpp:

hotspot/src/share/vm/runtime/commandLineFlagRangeList.cpp:293: error: integer constant is too large for 'long' type

commandLineFlagRangeList.cpp:293 points to:
  emit_range_no(NULL RUNTIME_FLAGS(EMIT_RANGE_DEVELOPER_FLAG,
                                   EMIT_RANGE_PD_DEVELOPER_FLAG,
                                   EMIT_RANGE_PRODUCT_FLAG,
                                   EMIT_RANGE_PD_PRODUCT_FLAG,
                                   EMIT_RANGE_DIAGNOSTIC_FLAG,
                                   EMIT_RANGE_EXPERIMENTAL_FLAG,
                                   EMIT_RANGE_NOTPRODUCT_FLAG,
                                   EMIT_RANGE_MANAGEABLE_FLAG,
                                   EMIT_RANGE_PRODUCT_RW_FLAG,
                                   EMIT_RANGE_LP64_PRODUCT_FLAG,
                                   EMIT_RANGE_CHECK,
                                   IGNORE_CONSTRAINT) );


These are my configuration and build commands:
bash ./configure --enable-debug --disable-warnings-as-errors --with-target-bits=32 --with-boot-jdk=/usr/java/jdk1.8.0_60
make LOG=debug all

Has anyone seen this error before? How do I go about fixing this error? Any help is greatly appreciated.

Thanks,

Silvia Vidaurre


From bob.vandette at oracle.com  Mon Dec 21 20:18:54 2015
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 21 Dec 2015 15:18:54 -0500
Subject: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS Mobile
	JRE
Message-ID: <BAC8D714-2834-432D-A2EC-2EE8732B656E@oracle.com>

http://cr.openjdk.java.net/~bobv/8145936/webrev.00/

Please review the following fixes that were required to complete the 
initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest.

1. Change the VAR_CPU_ARCH for 64-bit to "arm" from ?aarch64 in order to 
ensure that OPENJDK_TARGET_CPU_ARCH is set to CPU architecture family
and not specific architecture version.  This is the way x86/x86_x64 is also handled.

2. Add the SocketOption and UnixConstant template files into the JDK repo.
These are required for cross compilation builds since the genSocketOption
and genUnixConstants programs cannot be run on the build system.

3. Add a macosx directory for iOS build in the NIO makefile.
Exclude the UTIFileTypeDetector.c file from the iOS build since it
is dependent on a Framework that is not available in iOS.  We probably 
should remove the entire MacOSXFileSystemProvider set of classes.
Currently the default provider for iOS is Bsd.

Bob Vandette



From erik.joelsson at oracle.com  Mon Dec 21 20:21:46 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 21 Dec 2015 21:21:46 +0100
Subject: OpenJDK9 Build Error on Linux 32-bit
In-Reply-To: <9889B6346DBB6B4A95CDDCB87D5A11E502BA2239@HVXDSP24.us.lmco.com>
References: <9889B6346DBB6B4A95CDDCB87D5A11E502BA2239@HVXDSP24.us.lmco.com>
Message-ID: <56785F5A.4060104@oracle.com>

I have seen the same error in other parts of the code when building on 
older versions of Linux and am not surprised it pops up again. At 
Oracle, we don't support this old version of Redhat anymore for JDK 9 so 
it's not a regularly tested build configuration. I would recommend 
trying a newer version of GCC to get a working build. Internally we use 
GCC 4.9.2 built from source.

If that is not an option, you will need to fix the types. I remember 
wrapping 64 bit constants in CONST64() did the trick before, but this 
isn't really my area of expertise.

/Erik

On 2015-12-21 21:03, Vidaurre, Silvia L wrote:
> Hello,
>
> I just downloaded OpenJDK9, and am trying to build it on 32bit RHEL 5.11 with g++ 4.2.1, and I am getting this error from commandLineFlagRangeList.cpp:
>
> hotspot/src/share/vm/runtime/commandLineFlagRangeList.cpp:293: error: integer constant is too large for 'long' type
>
> commandLineFlagRangeList.cpp:293 points to:
>    emit_range_no(NULL RUNTIME_FLAGS(EMIT_RANGE_DEVELOPER_FLAG,
>                                     EMIT_RANGE_PD_DEVELOPER_FLAG,
>                                     EMIT_RANGE_PRODUCT_FLAG,
>                                     EMIT_RANGE_PD_PRODUCT_FLAG,
>                                     EMIT_RANGE_DIAGNOSTIC_FLAG,
>                                     EMIT_RANGE_EXPERIMENTAL_FLAG,
>                                     EMIT_RANGE_NOTPRODUCT_FLAG,
>                                     EMIT_RANGE_MANAGEABLE_FLAG,
>                                     EMIT_RANGE_PRODUCT_RW_FLAG,
>                                     EMIT_RANGE_LP64_PRODUCT_FLAG,
>                                     EMIT_RANGE_CHECK,
>                                     IGNORE_CONSTRAINT) );
>
>
> These are my configuration and build commands:
> bash ./configure --enable-debug --disable-warnings-as-errors --with-target-bits=32 --with-boot-jdk=/usr/java/jdk1.8.0_60
> make LOG=debug all
>
> Has anyone seen this error before? How do I go about fixing this error? Any help is greatly appreciated.
>
> Thanks,
>
> Silvia Vidaurre



From bob.vandette at oracle.com  Mon Dec 21 20:48:27 2015
From: bob.vandette at oracle.com (Bob Vandette)
Date: Mon, 21 Dec 2015 15:48:27 -0500
Subject: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.
In-Reply-To: <CAA-vtUzm_AwRnACWcieTHhq_cBaai5XLr4ZuOwQUMfo9-6km-w@mail.gmail.com>
References: <566AE88C.3040701@oracle.com>
	<CAA-vtUwMxj2s5WrgD829quWjGmmSU9f4xEO1SeOWKZ9Yr6wMXw@mail.gmail.com>
	<A97613FE-2F5C-4643-837B-43A385519B91@oracle.com>
	<CAA-vtUzm_AwRnACWcieTHhq_cBaai5XLr4ZuOwQUMfo9-6km-w@mail.gmail.com>
Message-ID: <97E0466B-5224-441D-A9BB-782CE62B0792@oracle.com>

Thomas, 

It is definitely not too late.  The push that Gary did was to our mobile/dev forest which is
not the final forest before integration into OpenJDK.  We pushed this to mobile/dev in order to 
allow interested developers to begin working with these changes and to provide us with feedback.

The final changesets will end up going to mobile/jdk9.  This is the staging forest that we will
eventually integrate into the mainline OpenJDK sources.

Bob.


> On Dec 18, 2015, at 9:17 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi Bob and Gary,
> 
> Thank you for correcting this! Respect also on this large porting effort, this looks like a lot of work and I am curious how this will turn out.
> 
> I took a short look at your changes - especially the android-related changes  - and have a number of further questions and suggestions . I hope that this is okay and the door is not already closed.
> 
> I'm away from any computer however (ironically typing this from an android device, so anything weird is due to auto correct :), so before Monday I will not be able to do anything.
> 
> I also think that this may be interesting to hotspot-runtime, because the changes to the OS layer are somewhat extensive, so I'll take the freedom and put them on the recipient list.
> 
> Kind regards, Thomas
> 
> On Dec 18, 2015 22:16, "Bob Vandette" <bob.vandette at oracle.com <mailto:bob.vandette at oracle.com>> wrote:
> I caught that and gave Gary an updated set of os_linux* files that hopefully corrected this.
> 
> Here?s the updated changes that Gary just pushed today.
> 
> http://hg.openjdk.java.net/mobile/dev/hotspot/rev/f1acc8fa34b8 <http://hg.openjdk.java.net/mobile/dev/hotspot/rev/f1acc8fa34b8>
> 
> 
> Bob.
> 
> > On Dec 18, 2015, at 4:11 PM, Thomas St?fe <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
> >
> > Hi Gary,
> >
> > In the Linux os layer - especially in os_linux.cpp - I see you have
> > reintroduced old coding we just painstakingly removed because it was not
> > needed for modern Linuxes anymore. For instance, coding dealing with old
> > Linuxthreads (vs Nptl, which is ubiquitous nowadays) or workarounds for old
> > glibc bugs. Is this really needed for Android? Or is this just a merge
> > error?
> >
> > Kind regards, Thomas
> > On Dec 11, 2015 16:15, "Gary Adams" <gary.adams at oracle.com <mailto:gary.adams at oracle.com>> wrote:
> >
> >> Here's the initial upload of changes that provides support for the ios and
> >> android ports
> >> for the mobile/dev repos. While there have been some preliminary reviews
> >> of the code,
> >> there is still more work required before we will look for more thorough
> >> reviews
> >> and an integration to mobile/jdk9 repos.
> >>
> >>  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132 <https://bugs.openjdk.java.net/browse/JDK-8145132>
> >>  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/ <http://cr.openjdk.java.net/~gadams/8145132/webrev.00/>
> >>
> >>
> >> Here's a simple configure script to generate a ios-x86_64 build for use
> >> with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)
> >>
> >> export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
> >> export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH
> >>
> >> bash ../../configure \
> >>    --openjdk-target=x86_64-macos-ios \
> >>    --with-boot-jdk=$JAVA_HOME \
> >>    --disable-warnings-as-errors \
> >>    --disable-headful \
> >>    --enable-static-build=yes \
> >>    --with-jvm-variants=minimal1
> >>
> >>
> >> Also, tested with i586-macos-ios target for 32 bit
> >> with a locally built --with-freetype 2.6.2.
> >>
> 



From dmitry.samersoff at oracle.com  Mon Dec 21 21:50:27 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 22 Dec 2015 00:50:27 +0300
Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the
	modular source layout
Message-ID: <56787423.6020809@oracle.com>

Everybody,

Please, review the changes:

http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/

The problem:

  Serviceability agent source should follow source layout
  convention for modular jdk.

The solution:

  Move SA sources under src/jdk.hotspot.agent

  Move native code under jdk.hotspot.agent/{OS}/native/libsaproc

Problems left:
  * I'll file a CR for each of problem and fix it later.

  1. Custom gif copy routine left unchanged.

  2. The name of SA under windows left unchanged it's sawindbg.dll

  3. doc, scripts, test directories moved to a new location
     as is. It's content about to be evaluated.

-Dmitry

-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From erik.joelsson at oracle.com  Tue Dec 22 07:38:14 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Dec 2015 08:38:14 +0100
Subject: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS
	Mobile JRE
In-Reply-To: <BAC8D714-2834-432D-A2EC-2EE8732B656E@oracle.com>
References: <BAC8D714-2834-432D-A2EC-2EE8732B656E@oracle.com>
Message-ID: <5678FDE6.2030601@oracle.com>

Looks good to me.

/Erik

On 2015-12-21 21:18, Bob Vandette wrote:
> http://cr.openjdk.java.net/~bobv/8145936/webrev.00/
>
> Please review the following fixes that were required to complete the
> initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest.
>
> 1. Change the VAR_CPU_ARCH for 64-bit to "arm" from ?aarch64 in order to
> ensure that OPENJDK_TARGET_CPU_ARCH is set to CPU architecture family
> and not specific architecture version.  This is the way x86/x86_x64 is also handled.
>
> 2. Add the SocketOption and UnixConstant template files into the JDK repo.
> These are required for cross compilation builds since the genSocketOption
> and genUnixConstants programs cannot be run on the build system.
>
> 3. Add a macosx directory for iOS build in the NIO makefile.
> Exclude the UTIFileTypeDetector.c file from the iOS build since it
> is dependent on a Framework that is not available in iOS.  We probably
> should remove the entire MacOSXFileSystemProvider set of classes.
> Currently the default provider for iOS is Bsd.
>
> Bob Vandette
>



From erik.joelsson at oracle.com  Tue Dec 22 07:46:07 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Dec 2015 08:46:07 +0100
Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the
	modular source layout
In-Reply-To: <56787423.6020809@oracle.com>
References: <56787423.6020809@oracle.com>
Message-ID: <5678FFBF.1000002@oracle.com>

Hello Dmitry,

Nice to see this happen!

make/lib/Lib-jdk.hotspot.agent.gmk:
Missing a "/libsaproc" here:
SA_SRC += $(SA_TOPDIR)/share/native 
$(SA_TOPDIR)/$(OPENJDK_TARGET_OS)/native/libsaproc

Otherwise it looks good.

/Erik

On 2015-12-21 22:50, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review the changes:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/
>
> The problem:
>
>    Serviceability agent source should follow source layout
>    convention for modular jdk.
>
> The solution:
>
>    Move SA sources under src/jdk.hotspot.agent
>
>    Move native code under jdk.hotspot.agent/{OS}/native/libsaproc
>
> Problems left:
>    * I'll file a CR for each of problem and fix it later.
>
>    1. Custom gif copy routine left unchanged.
>
>    2. The name of SA under windows left unchanged it's sawindbg.dll
>
>    3. doc, scripts, test directories moved to a new location
>       as is. It's content about to be evaluated.
>
> -Dmitry
>



From magnus.ihse.bursie at oracle.com  Tue Dec 22 09:49:15 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Dec 2015 10:49:15 +0100
Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the
	modular source layout
In-Reply-To: <5678FFBF.1000002@oracle.com>
References: <56787423.6020809@oracle.com> <5678FFBF.1000002@oracle.com>
Message-ID: <56791C9B.108@oracle.com>

On 2015-12-22 08:46, Erik Joelsson wrote:
> Hello Dmitry,
>
> Nice to see this happen!
>
> make/lib/Lib-jdk.hotspot.agent.gmk:
> Missing a "/libsaproc" here:
> SA_SRC += $(SA_TOPDIR)/share/native 
> $(SA_TOPDIR)/$(OPENJDK_TARGET_OS)/native/libsaproc
>
> Otherwise it looks good.

Looks good to me too.

/Magnus

>
> /Erik
>
> On 2015-12-21 22:50, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review the changes:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/
>>
>> The problem:
>>
>>    Serviceability agent source should follow source layout
>>    convention for modular jdk.
>>
>> The solution:
>>
>>    Move SA sources under src/jdk.hotspot.agent
>>
>>    Move native code under jdk.hotspot.agent/{OS}/native/libsaproc
>>
>> Problems left:
>>    * I'll file a CR for each of problem and fix it later.
>>
>>    1. Custom gif copy routine left unchanged.
>>
>>    2. The name of SA under windows left unchanged it's sawindbg.dll
>>
>>    3. doc, scripts, test directories moved to a new location
>>       as is. It's content about to be evaluated.
>>
>> -Dmitry
>>
>



From magnus.ihse.bursie at oracle.com  Tue Dec 22 09:59:10 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Dec 2015 10:59:10 +0100
Subject: RFR: JDK-8145789: Switch JDK 9 to use Jib in JPRT
In-Reply-To: <5677DBDA.5000508@oracle.com>
References: <5677DBDA.5000508@oracle.com>
Message-ID: <56791EEE.3000901@oracle.com>

On 2015-12-21 12:00, Erik Joelsson wrote:
> Hello,
>
> With Jib support in JDK 9, it would be nice to start using it in JPRT 
> instead of having JPRT having to track dependencies and 
> configurations. This change enables Jib in JPRT and disables all the 
> JPRT functionality for tracking dependencies (build.needs and most 
> configure args).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145789
> Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.01/
>
> /Erik

Looks good to me.

/Magnus



From erik.joelsson at oracle.com  Tue Dec 22 14:13:13 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Dec 2015 15:13:13 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
Message-ID: <56795A79.7000305@oracle.com>

Hello,

If we are to rely on Jib, the whole process needs redundancy in download 
locations. For the main downloads, this is already in place, but the 
weak link is the initial bootstrapping of the tool itself. I propose to 
add support in common/bin/jib.sh for checking a list of mirrors to 
download the install script from.

Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/

/Erik


From magnus.ihse.bursie at oracle.com  Tue Dec 22 14:23:32 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Dec 2015 15:23:32 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <56795A79.7000305@oracle.com>
References: <56795A79.7000305@oracle.com>
Message-ID: <C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>

If you set IFS=' ,' before looping over the jib_mirrors variable, you will allow a comma-separated list as well as a space separated, which makes it possible to set using environment variables in a reasonable way. I think. :) I always have to look up the details on IFS. 

Otherwise it's looking fine. 

/Magnus

> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Hello,
> 
> If we are to rely on Jib, the whole process needs redundancy in download locations. For the main downloads, this is already in place, but the weak link is the initial bootstrapping of the tool itself. I propose to add support in common/bin/jib.sh for checking a list of mirrors to download the install script from.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
> 
> /Erik


From erik.joelsson at oracle.com  Tue Dec 22 14:33:21 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Dec 2015 15:33:21 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>
References: <56795A79.7000305@oracle.com>
	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>
Message-ID: <56795F31.7010300@oracle.com>

Thanks for fast review!

Added IFS and verified that it accepts any combination of space and 
comma as separator.

Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/

/Erik

On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
> If you set IFS=' ,' before looping over the jib_mirrors variable, you will allow a comma-separated list as well as a space separated, which makes it possible to set using environment variables in a reasonable way. I think. :) I always have to look up the details on IFS.
>
> Otherwise it's looking fine.
>
> /Magnus
>
>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>
>> Hello,
>>
>> If we are to rely on Jib, the whole process needs redundancy in download locations. For the main downloads, this is already in place, but the weak link is the initial bootstrapping of the tool itself. I propose to add support in common/bin/jib.sh for checking a list of mirrors to download the install script from.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>
>> /Erik



From jaroslav.bachorik at oracle.com  Tue Dec 22 15:39:32 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 22 Dec 2015 16:39:32 +0100
Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the
	modular source layout
In-Reply-To: <56787423.6020809@oracle.com>
References: <56787423.6020809@oracle.com>
Message-ID: <56796EB4.4030501@oracle.com>

Hi,

looks good, modulo the problems you are mentioning (docs will need 
update to refer to correct locations; the same might be true for the 
textual output from scripts). I believe the tests are still passing.

Supposing the remaining problems are covered by CR you can consider this 
reviewed.


Regards,

-JB-

On 21.12.2015 22:50, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review the changes:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/
>
> The problem:
>
>    Serviceability agent source should follow source layout
>    convention for modular jdk.
>
> The solution:
>
>    Move SA sources under src/jdk.hotspot.agent
>
>    Move native code under jdk.hotspot.agent/{OS}/native/libsaproc
>
> Problems left:
>    * I'll file a CR for each of problem and fix it later.
>
>    1. Custom gif copy routine left unchanged.
>
>    2. The name of SA under windows left unchanged it's sawindbg.dll
>
>    3. doc, scripts, test directories moved to a new location
>       as is. It's content about to be evaluated.
>
> -Dmitry
>



From jaroslav.bachorik at oracle.com  Tue Dec 22 15:40:05 2015
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 22 Dec 2015 16:40:05 +0100
Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the
	modular source layout
In-Reply-To: <56787423.6020809@oracle.com>
References: <56787423.6020809@oracle.com>
Message-ID: <56796ED5.8070705@oracle.com>

Hi,

looks good, modulo the problems you are mentioning (docs will need 
update to refer to correct locations; the same might be true for the 
textual output from scripts). I believe the tests are still passing.

Supposing the remaining problems are covered by CR you can consider this 
reviewed.


Regards,

-JB-

On 21.12.2015 22:50, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review the changes:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/
>
> The problem:
>
>    Serviceability agent source should follow source layout
>    convention for modular jdk.
>
> The solution:
>
>    Move SA sources under src/jdk.hotspot.agent
>
>    Move native code under jdk.hotspot.agent/{OS}/native/libsaproc
>
> Problems left:
>    * I'll file a CR for each of problem and fix it later.
>
>    1. Custom gif copy routine left unchanged.
>
>    2. The name of SA under windows left unchanged it's sawindbg.dll
>
>    3. doc, scripts, test directories moved to a new location
>       as is. It's content about to be evaluated.
>
> -Dmitry
>



From dmitry.samersoff at oracle.com  Tue Dec 22 15:45:04 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 22 Dec 2015 18:45:04 +0300
Subject: RFR(L): JDK-8067194 Restructure hotspot/agent/src to conform the
	modular source layout
In-Reply-To: <56796EB4.4030501@oracle.com>
References: <56787423.6020809@oracle.com> <56796EB4.4030501@oracle.com>
Message-ID: <56797000.7090100@oracle.com>

Thank you!


On 2015-12-22 18:39, Jaroslav Bachorik wrote:
> Hi,
> 
> looks good, modulo the problems you are mentioning (docs will need
> update to refer to correct locations; the same might be true for the
> textual output from scripts). I believe the tests are still passing.
> 
> Supposing the remaining problems are covered by CR you can consider this
> reviewed.
> 
> 
> Regards,
> 
> -JB-
> 
> On 21.12.2015 22:50, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review the changes:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8067194/webrevs.02/
>>
>> The problem:
>>
>>    Serviceability agent source should follow source layout
>>    convention for modular jdk.
>>
>> The solution:
>>
>>    Move SA sources under src/jdk.hotspot.agent
>>
>>    Move native code under jdk.hotspot.agent/{OS}/native/libsaproc
>>
>> Problems left:
>>    * I'll file a CR for each of problem and fix it later.
>>
>>    1. Custom gif copy routine left unchanged.
>>
>>    2. The name of SA under windows left unchanged it's sawindbg.dll
>>
>>    3. doc, scripts, test directories moved to a new location
>>       as is. It's content about to be evaluated.
>>
>> -Dmitry
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From magnus.ihse.bursie at oracle.com  Tue Dec 22 16:43:58 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Dec 2015 17:43:58 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <56795F31.7010300@oracle.com>
References: <56795A79.7000305@oracle.com>
	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>
	<56795F31.7010300@oracle.com>
Message-ID: <B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>

Nice. Just one thing more: please save and restore the old value of IFS. Things can behave strange when modifying IFS so it's good to have it changed for as short a period as possible. 

/Magnus

> 22 dec. 2015 kl. 15:33 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Thanks for fast review!
> 
> Added IFS and verified that it accepts any combination of space and comma as separator.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/
> 
> /Erik
> 
>> On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
>> If you set IFS=' ,' before looping over the jib_mirrors variable, you will allow a comma-separated list as well as a space separated, which makes it possible to set using environment variables in a reasonable way. I think. :) I always have to look up the details on IFS.
>> 
>> Otherwise it's looking fine.
>> 
>> /Magnus
>> 
>>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>> 
>>> Hello,
>>> 
>>> If we are to rely on Jib, the whole process needs redundancy in download locations. For the main downloads, this is already in place, but the weak link is the initial bootstrapping of the tool itself. I propose to add support in common/bin/jib.sh for checking a list of mirrors to download the install script from.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>> 
>>> /Erik
> 


From magnus.ihse.bursie at oracle.com  Tue Dec 22 16:45:22 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 Dec 2015 17:45:22 +0100
Subject: RFR: 8145936 - Fixes required to build and run Zero arm64 iOS
	Mobile JRE
In-Reply-To: <BAC8D714-2834-432D-A2EC-2EE8732B656E@oracle.com>
References: <BAC8D714-2834-432D-A2EC-2EE8732B656E@oracle.com>
Message-ID: <4332DB87-605E-47C3-897A-EF09085337BF@oracle.com>

Looks good to me. 

/Magnus

> 21 dec. 2015 kl. 21:18 skrev Bob Vandette <bob.vandette at oracle.com>:
> 
> http://cr.openjdk.java.net/~bobv/8145936/webrev.00/
> 
> Please review the following fixes that were required to complete the 
> initial bringup of the iOS ARM64 Zero Java runtime in the JDK 9 Mobile/dev forest.
> 
> 1. Change the VAR_CPU_ARCH for 64-bit to "arm" from ?aarch64 in order to 
> ensure that OPENJDK_TARGET_CPU_ARCH is set to CPU architecture family
> and not specific architecture version.  This is the way x86/x86_x64 is also handled.
> 
> 2. Add the SocketOption and UnixConstant template files into the JDK repo.
> These are required for cross compilation builds since the genSocketOption
> and genUnixConstants programs cannot be run on the build system.
> 
> 3. Add a macosx directory for iOS build in the NIO makefile.
> Exclude the UTIFileTypeDetector.c file from the iOS build since it
> is dependent on a Framework that is not available in iOS.  We probably 
> should remove the entire MacOSXFileSystemProvider set of classes.
> Currently the default provider for iOS is Bsd.
> 
> Bob Vandette
> 


From erik.joelsson at oracle.com  Tue Dec 22 16:50:05 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 Dec 2015 17:50:05 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>
References: <56795A79.7000305@oracle.com>
	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>
	<56795F31.7010300@oracle.com>
	<B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>
Message-ID: <56797F3D.4000008@oracle.com>

Right, new webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.03/

/Erik

On 2015-12-22 17:43, Magnus Ihse Bursie wrote:
> Nice. Just one thing more: please save and restore the old value of IFS. Things can behave strange when modifying IFS so it's good to have it changed for as short a period as possible.
>
> /Magnus
>
>> 22 dec. 2015 kl. 15:33 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>
>> Thanks for fast review!
>>
>> Added IFS and verified that it accepts any combination of space and comma as separator.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/
>>
>> /Erik
>>
>>> On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
>>> If you set IFS=' ,' before looping over the jib_mirrors variable, you will allow a comma-separated list as well as a space separated, which makes it possible to set using environment variables in a reasonable way. I think. :) I always have to look up the details on IFS.
>>>
>>> Otherwise it's looking fine.
>>>
>>> /Magnus
>>>
>>>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>>
>>>> Hello,
>>>>
>>>> If we are to rely on Jib, the whole process needs redundancy in download locations. For the main downloads, this is already in place, but the weak link is the initial bootstrapping of the tool itself. I propose to add support in common/bin/jib.sh for checking a list of mirrors to download the install script from.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>>>
>>>> /Erik



From tim.bell at oracle.com  Tue Dec 22 19:36:28 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 22 Dec 2015 11:36:28 -0800
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <56797F3D.4000008@oracle.com>
References: <56795A79.7000305@oracle.com>	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>	<56795F31.7010300@oracle.com>	<B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>
	<56797F3D.4000008@oracle.com>
Message-ID: <5679A63C.30003@oracle.com>

Erik:

Looks good to me as well.

/Tim


> Right, new webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.03/
>
> /Erik
>
> On 2015-12-22 17:43, Magnus Ihse Bursie wrote:
>> Nice. Just one thing more: please save and restore the old value of 
>> IFS. Things can behave strange when modifying IFS so it's good to 
>> have it changed for as short a period as possible.
>>
>> /Magnus
>>
>>> 22 dec. 2015 kl. 15:33 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>
>>> Thanks for fast review!
>>>
>>> Added IFS and verified that it accepts any combination of space and 
>>> comma as separator.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/
>>>
>>> /Erik
>>>
>>>> On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
>>>> If you set IFS=' ,' before looping over the jib_mirrors variable, 
>>>> you will allow a comma-separated list as well as a space separated, 
>>>> which makes it possible to set using environment variables in a 
>>>> reasonable way. I think. :) I always have to look up the details on 
>>>> IFS.
>>>>
>>>> Otherwise it's looking fine.
>>>>
>>>> /Magnus
>>>>
>>>>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson 
>>>>> <erik.joelsson at oracle.com>:
>>>>>
>>>>> Hello,
>>>>>
>>>>> If we are to rely on Jib, the whole process needs redundancy in 
>>>>> download locations. For the main downloads, this is already in 
>>>>> place, but the weak link is the initial bootstrapping of the tool 
>>>>> itself. I propose to add support in common/bin/jib.sh for checking 
>>>>> a list of mirrors to download the install script from.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>>>>
>>>>> /Erik
>



From Peter.B.Kessler at Oracle.COM  Tue Dec 22 20:00:28 2015
From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler)
Date: Tue, 22 Dec 2015 12:00:28 -0800
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <5679A63C.30003@oracle.com>
References: <56795A79.7000305@oracle.com>	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>	<56795F31.7010300@oracle.com>	<B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>	<56797F3D.4000008@oracle.com>
	<5679A63C.30003@oracle.com>
Message-ID: <5679ABDC.7090102@Oracle.COM>

I am not a reviewer, but ....

If you want the range of IFS to be short, how about

	for mirror in $(IFS=" ," echo ${jib_server_mirrors}); do

assuming you really only want IFS set for the expansion of the values for mirror.  Then you don't have to remember to save and restore it, either.

Or, if you find IFS confusing, how about

	for mirror in $(echo ${jib_server_mirrors} | sed -e 's/,/ /g') ; do

to say that what you mean is that commas are treated as spaces in list of mirrors.  (Unless you find "sed" confusing, too. :-)  You could pull the sed command out to where you assign jib_server_mirrors so you only have to do it once and can't forget to do it.

			... peter

On 12/22/15 11:36 AM, Tim Bell wrote:
> Erik:
>
> Looks good to me as well.
>
> /Tim
>
>
>> Right, new webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.03/
>>
>> /Erik
>>
>> On 2015-12-22 17:43, Magnus Ihse Bursie wrote:
>>> Nice. Just one thing more: please save and restore the old value of IFS. Things can behave strange when modifying IFS so it's good to have it changed for as short a period as possible.
>>>
>>> /Magnus
>>>
>>>> 22 dec. 2015 kl. 15:33 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>>
>>>> Thanks for fast review!
>>>>
>>>> Added IFS and verified that it accepts any combination of space and comma as separator.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/
>>>>
>>>> /Erik
>>>>
>>>>> On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
>>>>> If you set IFS=' ,' before looping over the jib_mirrors variable, you will allow a comma-separated list as well as a space separated, which makes it possible to set using environment variables in a reasonable way. I think. :) I always have to look up the details on IFS.
>>>>>
>>>>> Otherwise it's looking fine.
>>>>>
>>>>> /Magnus
>>>>>
>>>>>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> If we are to rely on Jib, the whole process needs redundancy in download locations. For the main downloads, this is already in place, but the weak link is the initial bootstrapping of the tool itself. I propose to add support in common/bin/jib.sh for checking a list of mirrors to download the install script from.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>>>>>
>>>>>> /Erik
>>
>


From erik.joelsson at oracle.com  Wed Dec 23 08:59:22 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 23 Dec 2015 09:59:22 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <5679ABDC.7090102@Oracle.COM>
References: <56795A79.7000305@oracle.com>
	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>
	<56795F31.7010300@oracle.com>
	<B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>
	<56797F3D.4000008@oracle.com> <5679A63C.30003@oracle.com>
	<5679ABDC.7090102@Oracle.COM>
Message-ID: <567A626A.5020003@oracle.com>

These are all good suggestions, but to not delay this further, I'm going 
to go with what I have. Keep the range of IFS shorter isn't actually 
necessary in this case.

/Erik

On 2015-12-22 21:00, Peter B. Kessler wrote:
> I am not a reviewer, but ....
>
> If you want the range of IFS to be short, how about
>
>     for mirror in $(IFS=" ," echo ${jib_server_mirrors}); do
>
> assuming you really only want IFS set for the expansion of the values 
> for mirror.  Then you don't have to remember to save and restore it, 
> either.
>
> Or, if you find IFS confusing, how about
>
>     for mirror in $(echo ${jib_server_mirrors} | sed -e 's/,/ /g') ; do
>
> to say that what you mean is that commas are treated as spaces in list 
> of mirrors.  (Unless you find "sed" confusing, too. :-)  You could 
> pull the sed command out to where you assign jib_server_mirrors so you 
> only have to do it once and can't forget to do it.
>
>             ... peter
>
> On 12/22/15 11:36 AM, Tim Bell wrote:
>> Erik:
>>
>> Looks good to me as well.
>>
>> /Tim
>>
>>
>>> Right, new webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.03/
>>>
>>> /Erik
>>>
>>> On 2015-12-22 17:43, Magnus Ihse Bursie wrote:
>>>> Nice. Just one thing more: please save and restore the old value of 
>>>> IFS. Things can behave strange when modifying IFS so it's good to 
>>>> have it changed for as short a period as possible.
>>>>
>>>> /Magnus
>>>>
>>>>> 22 dec. 2015 kl. 15:33 skrev Erik Joelsson 
>>>>> <erik.joelsson at oracle.com>:
>>>>>
>>>>> Thanks for fast review!
>>>>>
>>>>> Added IFS and verified that it accepts any combination of space 
>>>>> and comma as separator.
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/
>>>>>
>>>>> /Erik
>>>>>
>>>>>> On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
>>>>>> If you set IFS=' ,' before looping over the jib_mirrors variable, 
>>>>>> you will allow a comma-separated list as well as a space 
>>>>>> separated, which makes it possible to set using environment 
>>>>>> variables in a reasonable way. I think. :) I always have to look 
>>>>>> up the details on IFS.
>>>>>>
>>>>>> Otherwise it's looking fine.
>>>>>>
>>>>>> /Magnus
>>>>>>
>>>>>>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson 
>>>>>>> <erik.joelsson at oracle.com>:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> If we are to rely on Jib, the whole process needs redundancy in 
>>>>>>> download locations. For the main downloads, this is already in 
>>>>>>> place, but the weak link is the initial bootstrapping of the 
>>>>>>> tool itself. I propose to add support in common/bin/jib.sh for 
>>>>>>> checking a list of mirrors to download the install script from.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>>>>>>
>>>>>>> /Erik
>>>
>>



From erik.joelsson at oracle.com  Wed Dec 23 12:03:40 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 23 Dec 2015 13:03:40 +0100
Subject: JDK-8146091: Configure fails to configure icecc on OEL
Message-ID: <567A8D9C.1010206@oracle.com>

Hello,

The icecc-create-env utility in older icecc distributions takes input 
parameters differently. On my Ubuntu:

$ /usr/lib/icecc/icecc-create-env
usage: /usr/lib/icecc/icecc-create-env --gcc <gcc_path> <g++_path>
usage: /usr/lib/icecc/icecc-create-env --clang <clang_path> 
<compiler_wrapper>
usage: Use --addfile <file> to add extra files.

On an OEL:
$ /usr/lib64/icecc/icecc-create-env
usage: /usr/lib64/icecc/icecc-create-env <gcc_path> <g++_path>

Testing for which format is needed is pretty simple. If there is a 
"--gcc" in th help text, then we need to set --gcc.

I also added several checks so that configure fails when the icecc build 
environment cannot be built.

Bug: https://bugs.openjdk.java.net/browse/JDK-8146091
Webrev: http://cr.openjdk.java.net/~erikj/8146091/webrev.01/

/Erik


From magnus.ihse.bursie at oracle.com  Wed Dec 23 15:48:53 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 23 Dec 2015 16:48:53 +0100
Subject: RFR: JDK-8146002: Need to support mirrors for bootstrapping Jib
In-Reply-To: <56797F3D.4000008@oracle.com>
References: <56795A79.7000305@oracle.com>
	<C56D30BD-1CEF-4992-9ABF-CE32E8B345A8@oracle.com>
	<56795F31.7010300@oracle.com>
	<B96C32A0-D4C9-4685-8682-BF13A47E38A2@oracle.com>
	<56797F3D.4000008@oracle.com>
Message-ID: <3F4C53AD-591D-498F-9BB7-E7532B98626F@oracle.com>

Looks good to me. 

/Magnus

> 22 dec. 2015 kl. 17:50 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Right, new webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.03/
> 
> /Erik
> 
>> On 2015-12-22 17:43, Magnus Ihse Bursie wrote:
>> Nice. Just one thing more: please save and restore the old value of IFS. Things can behave strange when modifying IFS so it's good to have it changed for as short a period as possible.
>> 
>> /Magnus
>> 
>>> 22 dec. 2015 kl. 15:33 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>> 
>>> Thanks for fast review!
>>> 
>>> Added IFS and verified that it accepts any combination of space and comma as separator.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.02/
>>> 
>>> /Erik
>>> 
>>>> On 2015-12-22 15:23, Magnus Ihse Bursie wrote:
>>>> If you set IFS=' ,' before looping over the jib_mirrors variable, you will allow a comma-separated list as well as a space separated, which makes it possible to set using environment variables in a reasonable way. I think. :) I always have to look up the details on IFS.
>>>> 
>>>> Otherwise it's looking fine.
>>>> 
>>>> /Magnus
>>>> 
>>>>> 22 dec. 2015 kl. 15:13 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> If we are to rely on Jib, the whole process needs redundancy in download locations. For the main downloads, this is already in place, but the weak link is the initial bootstrapping of the tool itself. I propose to add support in common/bin/jib.sh for checking a list of mirrors to download the install script from.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8146002
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8146002/webrev.01/
>>>>> 
>>>>> /Erik
> 


From david.holmes at oracle.com  Tue Dec 29 10:05:26 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 29 Dec 2015 20:05:26 +1000
Subject: OpenJDK9 Build Error on Linux 32-bit
In-Reply-To: <56785F5A.4060104@oracle.com>
References: <9889B6346DBB6B4A95CDDCB87D5A11E502BA2239@HVXDSP24.us.lmco.com>
	<56785F5A.4060104@oracle.com>
Message-ID: <56825AE6.2050300@oracle.com>

This seems like a compiler bug to me. When we compile with a later gcc 
we do not see this, but neither the constant's value nor the size of 
long has changed. Not that it is at all clear what "integer constant" is 
being referred to.

David

On 22/12/2015 6:21 AM, Erik Joelsson wrote:
> I have seen the same error in other parts of the code when building on
> older versions of Linux and am not surprised it pops up again. At
> Oracle, we don't support this old version of Redhat anymore for JDK 9 so
> it's not a regularly tested build configuration. I would recommend
> trying a newer version of GCC to get a working build. Internally we use
> GCC 4.9.2 built from source.
>
> If that is not an option, you will need to fix the types. I remember
> wrapping 64 bit constants in CONST64() did the trick before, but this
> isn't really my area of expertise.
>
> /Erik
>
> On 2015-12-21 21:03, Vidaurre, Silvia L wrote:
>> Hello,
>>
>> I just downloaded OpenJDK9, and am trying to build it on 32bit RHEL
>> 5.11 with g++ 4.2.1, and I am getting this error from
>> commandLineFlagRangeList.cpp:
>>
>> hotspot/src/share/vm/runtime/commandLineFlagRangeList.cpp:293: error:
>> integer constant is too large for 'long' type
>>
>> commandLineFlagRangeList.cpp:293 points to:
>>    emit_range_no(NULL RUNTIME_FLAGS(EMIT_RANGE_DEVELOPER_FLAG,
>>                                     EMIT_RANGE_PD_DEVELOPER_FLAG,
>>                                     EMIT_RANGE_PRODUCT_FLAG,
>>                                     EMIT_RANGE_PD_PRODUCT_FLAG,
>>                                     EMIT_RANGE_DIAGNOSTIC_FLAG,
>>                                     EMIT_RANGE_EXPERIMENTAL_FLAG,
>>                                     EMIT_RANGE_NOTPRODUCT_FLAG,
>>                                     EMIT_RANGE_MANAGEABLE_FLAG,
>>                                     EMIT_RANGE_PRODUCT_RW_FLAG,
>>                                     EMIT_RANGE_LP64_PRODUCT_FLAG,
>>                                     EMIT_RANGE_CHECK,
>>                                     IGNORE_CONSTRAINT) );
>>
>>
>> These are my configuration and build commands:
>> bash ./configure --enable-debug --disable-warnings-as-errors
>> --with-target-bits=32 --with-boot-jdk=/usr/java/jdk1.8.0_60
>> make LOG=debug all
>>
>> Has anyone seen this error before? How do I go about fixing this
>> error? Any help is greatly appreciated.
>>
>> Thanks,
>>
>> Silvia Vidaurre
>