build failure on macOS: Bus error in BUILD_JIGSAW_TOOLS

[Alan Snyder]

I have just started getting a reliable build failure on macOS, even with a new 
clone of the client repo.

I’m not sure what might have changed, other than using a new SDK (from macOS 
10.14) and Xcode 10.

The key lines are:

Compiling 4 files for BUILD_JIGSAW_TOOLS
make[3]: *** 
[/Volumes/A/JDK/client2/build/macosx-x86_64-normal-server-release/jdk/_packages_attribute.done]
 Bus error: 10
make[2]: *** [exploded-image-optimize] Error 2

Re: build fail

[Sebastian Demian]

I switched from panama/panama to panama/dev instead and was able to build
it successfully.

Thank you for your help,
Sebastian.

On Fri, Jun 15, 2018 at 3:16 PM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

>
>
> On 2018-06-15 21:18, Sebastian Demian wrote:
> > + build-dev
> >
> > On Fri, Jun 15, 2018 at 2:17 PM Sebastian Demian <
> 2020sebast...@gmail.com>
> > wrote:
> >
> >> Thanks for the reply Erik.
> >>
> >> running with --disable-warnings-as-errors helped.
> >>
> >> I also ran make dist-clean before building again.
> >>
> >> The build failed at a later stage now.
> >>
> >>
> >>
> >> Here is the new output:
> >>
> >> Note: Recompile with -Xlint:removal for details.
> >> Note: Some input files use unchecked or unsafe operations.
> >> Note: Recompile with -Xlint:unchecked for details.
> >> */Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35:
> error:
> >> ordered comparison between pointer and zero ('address' (aka 'unsigned
> char
> >> *') and 'int')*
> >> *  if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.*
> >> *  ~~~ ^ ~*
> >> 1 error generated.
> >> make[3]: ***
> >>
> [/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/lcm.o]
> >> Error 1
>
> Apparently clang believe this is an error, and not just a warning, so
> this is a source code issue, and not a build issue per se.
>
> If this only happens in panama, you need to raise it with the Panama
> developers (cc:ed). If you can also reproduce it on the main jdk/jdk
> repo, then you can discuss it on hotspot-...@oopenjdk.java.net.
>
> /Magnus
>
> >> make[3]: *** Waiting for unfinished jobs
> >> make[2]: *** [hotspot-server-libs] Error 2
> >> make[2]: *** Waiting for unfinished jobs
> >>
> >> ERROR: Build failed for target 'all' in configuration
> >> 'macosx-x86_64-normal-server-release' (exit code 2)
> >> Stopping sjavac server
> >>
> >> === Output from failing command(s) repeated here ===
> >> * For target hotspot_variant-server_libjvm_objs_lcm.o:
> >> /Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35:
> error:
> >> ordered comparison between pointer and zero ('address' (aka 'unsigned
> char
> >> *') and 'int')
> >>if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.
> >>~~~ ^ ~
> >> 1 error generated.
> >>
> >> * All command lines available in
> >>
> /Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
> >> === End of repeated output ===
> >>
> >> No indication of failed target found.
> >> Hint: Try searching the build log for '] Error'.
> >> Hint: See common/doc/building.html#troubleshooting for assistance.
> >>
> >> make[1]: *** [main] Error 2
> >> make: *** [all] Error 2
> >>
> >>
> >>
> >> Thank you,
> >> Sebastian.
> >>
> >>
> >>
> >> On Fri, Jun 15, 2018 at 12:03 PM Erik Joelsson <
> erik.joels...@oracle.com>
> >> wrote:
> >>
> >>> Hello Sebastian,
> >>>
> >>> Please try running configure with --disable-warnings-as-errors.
> >>>
> >>> When using compiler versions (or OS versions) other than the ones
> listed
> >>> in doc/building.md it's common to have warnings triggered and we run
> >>> with warnings treated as errors by default.
> >>>
> >>> /Erik
> >>>
> >>>
> >>> On 2018-06-11 12:49, Sebastian Demian wrote:
>  Hello,
> 
>  I am trying to setup project panama on my local mac, and I am not able
> >>> to
>  build the project.
> 
>  Configuration summary:
>  * Debug level:release
>  * HS debug level: product
>  * JDK variant:normal
>  * JVM variants:   server
>  * OpenJDK target: OS: macosx, CPU architecture: x86, address length:
> 64
>  * Version string: 9-internal+0-adhoc.sd.panama (9-internal)
> 
>  Tools summary:
>  * Boot JDK:   java version "1.8.0_171" Java(TM) SE Runtime
> >>> Environment
>  (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
> >>> 25.171-b11,
>  mixed mode)  (at
>  /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
>  * Toolchain:  clang (clang/LLVM)
>  * C Compiler: Version 9.1.0 (at /usr/bin/clang)
>  * C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)
> 
>  Build performance summary:
>  * Cores to use:   4
>  * Memory limit:   16384 MB
> 
> 
> 
> 
>  I have attached the full log output from running make. I have read the
>  building.html and troubleshooting section and did not find anything
>  relevant to this error:
> 
> 
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
>  error: macro expansion producing 'defined' has undefined behavior
>  [-Werror,-Wexpansion-to-defined]
>  #if HEAP_REGION_SET_FORCE_VERIFY
>    ^
> 
> >>>
> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
>  note: expanded from macro 

Re: build fail

[Martin Buchholz]

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

Re: build fail

[Magnus Ihse Bursie]

On 2018-06-15 21:18, Sebastian Demian wrote:

+ build-dev

On Fri, Jun 15, 2018 at 2:17 PM Sebastian Demian <2020sebast...@gmail.com>
wrote:


Thanks for the reply Erik.

running with --disable-warnings-as-errors helped.

I also ran make dist-clean before building again.

The build failed at a later stage now.



Here is the new output:

Note: Recompile with -Xlint:removal for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
*/Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
ordered comparison between pointer and zero ('address' (aka 'unsigned char
*') and 'int')*
*  if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.*
*  ~~~ ^ ~*
1 error generated.
make[3]: ***
[/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/lcm.o]
Error 1


Apparently clang believe this is an error, and not just a warning, so 
this is a source code issue, and not a build issue per se.


If this only happens in panama, you need to raise it with the Panama 
developers (cc:ed). If you can also reproduce it on the main jdk/jdk 
repo, then you can discuss it on hotspot-...@oopenjdk.java.net.


/Magnus


make[3]: *** Waiting for unfinished jobs
make[2]: *** [hotspot-server-libs] Error 2
make[2]: *** Waiting for unfinished jobs

ERROR: Build failed for target 'all' in configuration
'macosx-x86_64-normal-server-release' (exit code 2)
Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target hotspot_variant-server_libjvm_objs_lcm.o:
/Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
ordered comparison between pointer and zero ('address' (aka 'unsigned char
*') and 'int')
   if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.
   ~~~ ^ ~
1 error generated.

* All command lines available in
/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See common/doc/building.html#troubleshooting for assistance.

make[1]: *** [main] Error 2
make: *** [all] Error 2



Thank you,
Sebastian.



On Fri, Jun 15, 2018 at 12:03 PM Erik Joelsson 
wrote:


Hello Sebastian,

Please try running configure with --disable-warnings-as-errors.

When using compiler versions (or OS versions) other than the ones listed
in doc/building.md it's common to have warnings triggered and we run
with warnings treated as errors by default.

/Erik


On 2018-06-11 12:49, Sebastian Demian wrote:

Hello,

I am trying to setup project panama on my local mac, and I am not able

to

build the project.

Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.sd.panama (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_171" Java(TM) SE Runtime

Environment

(build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build

25.171-b11,

mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 9.1.0 (at /usr/bin/clang)
* C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB




I have attached the full log output from running make. I have read the
building.html and troubleshooting section and did not find anything
relevant to this error:



/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:

error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
  ^


/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:

note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
   ^
In file included from


/Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:

In file included from


/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:

In file included from


/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:

error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
  ^


Any help would be appreciated.

Thanks,
Sebastian.

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[Magnus Ihse Bursie]

On 2018-06-15 18:02, Fridrich Strba wrote:

Hello, Magnus,

Your original patch had a problem, since the second statement overwrote
the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
like osSupport.hpp, jawt_md.h and so on could not be found in build of
tests. So, I modified your patch to read as attached and the build
finished. It is basically a 2-liner.
Sorry, it was untested and made in a bit of a hurry. A better solution 
would be to change it to read:


+  # Always add the java header dir
+  $1_SRC_HEADER_FLAGS += $$(addprefix -I, $$(call GetJavaHeaderDir, 
$$(MODULE)))


(the += will append to the existing variable, instead of replacing it).

/Magnus



Cheers

Fridrich

On 15/06/18 13:10, Magnus Ihse Bursie wrote:

Here's a better patch. Please try and see if it solves your problems.
Unfortunately, I'm leaving on vacation for today and will be gone most
of the summer, so I can't help sponsor this patch. But if it works, I'm
sure someone else can take over it.

If it does not work, the original patch should at the very least be
changed so that EXTRA_HEADER_DIRS gets an additional "$(call
GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
hard to eradicate from the CFLAGS).

Re: build fail

[Sebastian Demian]

+ build-dev

On Fri, Jun 15, 2018 at 2:17 PM Sebastian Demian <2020sebast...@gmail.com>
wrote:

> Thanks for the reply Erik.
>
> running with --disable-warnings-as-errors helped.
>
> I also ran make dist-clean before building again.
>
> The build failed at a later stage now.
>
>
>
> Here is the new output:
>
> Note: Recompile with -Xlint:removal for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> */Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
> ordered comparison between pointer and zero ('address' (aka 'unsigned char
> *') and 'int')*
> *  if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.*
> *  ~~~ ^ ~*
> 1 error generated.
> make[3]: ***
> [/Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/lcm.o]
> Error 1
> make[3]: *** Waiting for unfinished jobs
> make[2]: *** [hotspot-server-libs] Error 2
> make[2]: *** Waiting for unfinished jobs
>
> ERROR: Build failed for target 'all' in configuration
> 'macosx-x86_64-normal-server-release' (exit code 2)
> Stopping sjavac server
>
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-server_libjvm_objs_lcm.o:
> /Users/sd/Projects/panama/hotspot/src/share/vm/opto/lcm.cpp:42:35: error:
> ordered comparison between pointer and zero ('address' (aka 'unsigned char
> *') and 'int')
>   if (Universe::narrow_oop_base() > 0) { // Implies UseCompressedOops.
>   ~~~ ^ ~
> 1 error generated.
>
> * All command lines available in
> /Users/sd/Projects/panama/build/macosx-x86_64-normal-server-release/make-support/failure-logs.
> === End of repeated output ===
>
> No indication of failed target found.
> Hint: Try searching the build log for '] Error'.
> Hint: See common/doc/building.html#troubleshooting for assistance.
>
> make[1]: *** [main] Error 2
> make: *** [all] Error 2
>
>
>
> Thank you,
> Sebastian.
>
>
>
> On Fri, Jun 15, 2018 at 12:03 PM Erik Joelsson 
> wrote:
>
>> Hello Sebastian,
>>
>> Please try running configure with --disable-warnings-as-errors.
>>
>> When using compiler versions (or OS versions) other than the ones listed
>> in doc/building.md it's common to have warnings triggered and we run
>> with warnings treated as errors by default.
>>
>> /Erik
>>
>>
>> On 2018-06-11 12:49, Sebastian Demian wrote:
>> > Hello,
>> >
>> > I am trying to setup project panama on my local mac, and I am not able
>> to
>> > build the project.
>> >
>> > Configuration summary:
>> > * Debug level:release
>> > * HS debug level: product
>> > * JDK variant:normal
>> > * JVM variants:   server
>> > * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>> > * Version string: 9-internal+0-adhoc.sd.panama (9-internal)
>> >
>> > Tools summary:
>> > * Boot JDK:   java version "1.8.0_171" Java(TM) SE Runtime
>> Environment
>> > (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build
>> 25.171-b11,
>> > mixed mode)  (at
>> > /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
>> > * Toolchain:  clang (clang/LLVM)
>> > * C Compiler: Version 9.1.0 (at /usr/bin/clang)
>> > * C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)
>> >
>> > Build performance summary:
>> > * Cores to use:   4
>> > * Memory limit:   16384 MB
>> >
>> >
>> >
>> >
>> > I have attached the full log output from running make. I have read the
>> > building.html and troubleshooting section and did not find anything
>> > relevant to this error:
>> >
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
>> > error: macro expansion producing 'defined' has undefined behavior
>> > [-Werror,-Wexpansion-to-defined]
>> > #if HEAP_REGION_SET_FORCE_VERIFY
>> >  ^
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
>> > note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
>> > #define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
>> >   ^
>> > In file included from
>> >
>> /Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
>> > In file included from
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
>> > In file included from
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
>> >
>> /Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
>> > error: macro expansion producing 'defined' has undefined behavior
>> > [-Werror,-Wexpansion-to-defined]
>> > #if HEAP_REGION_SET_FORCE_VERIFY
>> >  ^
>> >
>> >
>> > Any help would be appreciated.
>> >
>> > Thanks,
>> > Sebastian.
>>
>>

Re: RFR: JDK-8203667: Platform specific include files in jdk image in wrong sub directory

[Tim Bell]

Erik:

Looks good to me as well.

/Tim

On 06/15/18 11:20, mandy chung wrote:

+1

Mandy

On 6/15/18 11:12 AM, Erik Joelsson wrote:

Due to a typo in spec.gmk.in, the platform specific include files have
lost their platform sub directory in the jdk image include dir.

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

Webrev: http://cr.openjdk.java.net/~erikj/8203667/webrev.01/

/Erik

Re: RFR: JDK-8203667: Platform specific include files in jdk image in wrong sub directory

[mandy chung]

+1

Mandy

On 6/15/18 11:12 AM, Erik Joelsson wrote:
Due to a typo in spec.gmk.in, the platform specific include files have 
lost their platform sub directory in the jdk image include dir.


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

Webrev: http://cr.openjdk.java.net/~erikj/8203667/webrev.01/

/Erik

RFR: JDK-8203667: Platform specific include files in jdk image in wrong sub directory

[Erik Joelsson]

Due to a typo in spec.gmk.in, the platform specific include files have 
lost their platform sub directory in the jdk image include dir.


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

Webrev: http://cr.openjdk.java.net/~erikj/8203667/webrev.01/

/Erik

Re: build fail

[Erik Joelsson]

Hello Sebastian,

Please try running configure with --disable-warnings-as-errors.

When using compiler versions (or OS versions) other than the ones listed 
in doc/building.md it's common to have warnings triggered and we run 
with warnings treated as errors by default.


/Erik


On 2018-06-11 12:49, Sebastian Demian wrote:

Hello,

I am trying to setup project panama on my local mac, and I am not able to
build the project.

Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.sd.panama (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_171" Java(TM) SE Runtime Environment
(build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 9.1.0 (at /usr/bin/clang)
* C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB




I have attached the full log output from running make. I have read the
building.html and troubleshooting section and did not find anything
relevant to this error:

/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
 ^
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
  ^
In file included from
/Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
In file included from
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
 ^


Any help would be appreciated.

Thanks,
Sebastian.

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

[Thomas Stüfe]

Hi Volker,



On Fri, Jun 15, 2018 at 10:05 AM, Volker Simonis
 wrote:
> On Thu, Jun 14, 2018 at 9:04 PM, Thomas Stüfe  wrote:
>> Hi Volker,
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html
>>
>> Seems like a roundabout way to have a platform specific default value.
>>
>> Why not determine a default value beforehand:
>>
>> if test "x$OPENJDK_TARGET_OS" = "xaix"; then
>>   ENABLE_CDS_DEFAULT="false"
>> else
>>   ENABLE_CDS_DEFAULT=true"
>> fi
>>
>> AC_ARG_ENABLE([cds], [AS_HELP_STRING([--enable-cds@<:@=yes/no/auto@:>@],
>>  [enable class data sharing feature in non-minimal VM. Default is
>> ${ENABLE_CDS_DEFAULT}.])])
>>
>> and so on?
>>
>
> I've just followed the pattern used for '--enable-aot' right above the
> code I changed.
>
> Moreover, I don't think that we would save any code because we would
> still have to check for AIX in the '--enable-cds=yes' case. Also, the
> new reporting added later in the file (see "AC_MSG_CHECKING([if cds
> should be enabled])" seems easier to me without the extra default
> value. So if you don't mind I'd prefer to leave it as is.
>

I just think that having three options (on/off/auto) is confusing.
Okay, I still think a platform dependent default value would be
cleaner, but I can live with auto="yes, if possible".

>> See also what we did for "8202325: [aix] disable warnings-as-errors by 
>> default".
>>
>> --
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/src/hotspot/share/classfile/javaClasses.cpp.udiff.html
>>
>> Here, do we really need to exclude this from compiling,
>> DumpSharedSpaces = false is not enough?
>>
>
> Yes, we need it because the excluded code references methods (e.g.
> 'StringTable::create_archived_string()') which are not compiled into
> libjvm.so if we disable CDS.
>

Are you really sure?

Both MetaspaceShared::is_archive_object() and
StringTable::create_archived_string() are available outside CDS, the
latter explicitly returns NULL if CDS is not enabled at build time:
NOT_CDS_JAVA_HEAP_RETURN_(NULL);

I also just built a Linux vm without CDS, and it compiles without
problems without the #ifdef. But maybe AIX is different.

---

But all this is idle nitpicking, so I leave it up to you if you change
anything. The change is good in its current form to me and I do not
need another webrev.

Best Regards, Thomas

>>
>> Best Regards, Thomas
>>
>> On Thu, Jun 14, 2018 at 4:26 PM, Volker Simonis
>>  wrote:
>>> Hi,
>>>
>>> can I please have a review for the following fix:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>>
>>> CDS does currently not work on AIX because of the way how we
>>> reserve/commit memory on AIX. The problem is that we're using a
>>> combination of shmat/mmap depending on the page size and the size of
>>> the memory chunk to reserve. This makes it impossible to reliably
>>> reserve the memory for the CDS archive and later on map the various
>>> parts of the archive into these regions.
>>>
>>> In order to fix this we would have to completely rework the memory
>>> reserve/commit/uncommit logic on AIX which is currently out of our
>>> scope because of resource limitations.
>>>
>>> Unfortunately, I could not simply disable CDS in the configure step
>>> because some of the shared code apparently relies on parts of the CDS
>>> code which gets excluded from the build when CDS is disabled. So I
>>> also fixed the offending parts in hotspot and cleaned up the configure
>>> logic for CDS.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: I did run the job through the submit forest
>>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>>> weren't really useful because they mention build failures on linux-x64
>>> which I can't reproduce locally.

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

[Jiangli Zhou]

Hi Volker,

> On Jun 15, 2018, at 12:43 AM, Volker Simonis  wrote:
> 
> Hi Jiangli,
> 
> thanks for looking at the change.
> 
> 'CDS_only' is only required for static fields because the
> VMStructEntry for them contains a reference to the actual static field
> which isn't present if we disable CDS, because the corresponding
> compilations units (i.e. filemap.cpp) won't be part of libjvm.so. For
> non-static fields, the VMStructEntry structure only contains the
> offset of the corresponding field with regards to an object of that
> type which is harmless.

Thanks for the explanation. For consistency, would it be worth to add CDS_ONLY 
for the non-static fields in FileMapInfo also?

Thanks,
Jiangli

> 
> Regards,
> Volker
> 
> 
> On Thu, Jun 14, 2018 at 6:42 PM, Jiangli Zhou  wrote:
>> Hi Volker,
>> 
>> The changes look good to me overall. I’ll refer to the JVMTI experts for
>> jvmtiEnv.cpp change. I have a question for the change in vmStructs.cpp. Any
>> reason why only _current_info needs CDS_ONLY?
>> 
>>   //
>> \
>>   /* FileMapInfo fields (CDS archive related) */
>> \
>>   //
>> \
>> 
>> \
>>   nonstatic_field(FileMapInfo, _header,
>> FileMapInfo::FileMapHeader*)   \
>> - static_field(FileMapInfo, _current_info,
>> FileMapInfo*)  \
>> + CDS_ONLY(static_field(FileMapInfo,_current_info,
>> FileMapInfo*)) \
>>   nonstatic_field(FileMapInfo::FileMapHeader,  _space[0],
>> FileMapInfo::FileMapHeader::space_info)\
>>   nonstatic_field(FileMapInfo::FileMapHeader::space_info, _addr._base,
>> char*) \
>>   nonstatic_field(FileMapInfo::FileMapHeader::space_info, _used,
>> size_t)\
>> 
>> \
>> 
>> Thanks,
>> Jiangli
>> 
>> On Jun 14, 2018, at 7:26 AM, Volker Simonis 
>> wrote:
>> 
>> Hi,
>> 
>> can I please have a review for the following fix:
>> 
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>> https://bugs.openjdk.java.net/browse/JDK-8204965
>> 
>> CDS does currently not work on AIX because of the way how we
>> reserve/commit memory on AIX. The problem is that we're using a
>> combination of shmat/mmap depending on the page size and the size of
>> the memory chunk to reserve. This makes it impossible to reliably
>> reserve the memory for the CDS archive and later on map the various
>> parts of the archive into these regions.
>> 
>> In order to fix this we would have to completely rework the memory
>> reserve/commit/uncommit logic on AIX which is currently out of our
>> scope because of resource limitations.
>> 
>> Unfortunately, I could not simply disable CDS in the configure step
>> because some of the shared code apparently relies on parts of the CDS
>> code which gets excluded from the build when CDS is disabled. So I
>> also fixed the offending parts in hotspot and cleaned up the configure
>> logic for CDS.
>> 
>> Thank you and best regards,
>> Volker
>> 
>> PS: I did run the job through the submit forest
>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>> weren't really useful because they mention build failures on linux-x64
>> which I can't reproduce locally.
>> 
>> 

build fail

[Sebastian Demian]

Hello,

I am trying to setup project panama on my local mac, and I am not able to
build the project.

Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.sd.panama (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_171" Java(TM) SE Runtime Environment
(build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version 9.1.0 (at /usr/bin/clang)
* C++ Compiler:   Version 9.1.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB




I have attached the full log output from running make. I have read the
building.html and troubleshooting section and did not find anything
relevant to this error:

/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:126:5:
error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
^
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/heapRegionSet.hpp:53:38:
note: expanded from macro 'HEAP_REGION_SET_FORCE_VERIFY'
#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT)
 ^
In file included from
/Users/sd/Projects/panama/hotspot/test/native/gc/g1/test_freeRegionList.cpp:25:
In file included from
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp:28:
In file included from
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1CollectedHeap.hpp:37:
/Users/sd/Projects/panama/hotspot/src/share/vm/gc/g1/g1HeapVerifier.hpp:67:5:
error: macro expansion producing 'defined' has undefined behavior
[-Werror,-Wexpansion-to-defined]
#if HEAP_REGION_SET_FORCE_VERIFY
^


Any help would be appreciated.

Thanks,
Sebastian.


make.log
Description: Binary data

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

[Zhengyu Gu]

Hi,

Whatever the name you come up, could you please also update 
stringDedup.inline.hpp to use the same names?


Thomas Schatzl pointed out the inconsistent, I made change to use S and 
Q, but apparently, I messed up in final patch.


Otherwise, looks good to me too.

-Zhengyu



On 06/15/2018 06:36 AM, Thomas Stüfe wrote:

Hi Matthias,

Good catch. Patch for me is good if you guys agree on a good uncommon name.

Gruß Thomas

On Fri, Jun 15, 2018, 09:48 Baesken, Matthias 
wrote:


Please review  this small  change  that fixes the AIX build after
"8203641: Refactor String Deduplication into shared".

We are getting this  compilation error  :
/build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
line 107.38: 1540-0063 (S) The text "1" is unexpected.


Looks like the name of the second template parameter (STAT)

 template 
 static void initialize_impl();

is clashing with defines from the AIX system headers  (where I find
#define STAT  1 ) .
Renaming  STAT  to something else fixes the build on AIX .

Webrev :

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

Bug :

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


Thanks, Matthias

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[Fridrich Strba]

Hello, Magnus,

Your original patch had a problem, since the second statement overwrote
the $1_SRC_HEADER_FLAGS instead of appending to it. With that, things
like osSupport.hpp, jawt_md.h and so on could not be found in build of
tests. So, I modified your patch to read as attached and the build
finished. It is basically a 2-liner.

Cheers

Fridrich

On 15/06/18 13:10, Magnus Ihse Bursie wrote:
> Here's a better patch. Please try and see if it solves your problems.
> Unfortunately, I'm leaving on vacation for today and will be gone most
> of the summer, so I can't help sponsor this patch. But if it works, I'm
> sure someone else can take over it.
> 
> If it does not work, the original patch should at the very least be
> changed so that EXTRA_HEADER_DIRS gets an additional "$(call
> GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying
> hard to eradicate from the CFLAGS).
--- jdk11/make/common/JdkNativeCompilation.gmk	2018-06-13 06:35:04.0 +0200
+++ jdk11/make/common/JdkNativeCompilation.gmk	2018-06-15 15:57:33.935447407 +0200
@@ -121,6 +121,8 @@
   ifneq ($$($1_HEADERS_FROM_SRC), false)
 $1_SRC_HEADER_FLAGS := $$(foreach dir, $$(wildcard $$($1_SRC) \
 $$(call GetJavaHeaderDir, $$(MODULE))), -I$$(dir))
+  else
+$1_SRC_HEADER_FLAGS := $$(foreach dir, $$(call GetJavaHeaderDir, $$(MODULE)), -I$$(dir))
   endif
   ifneq ($$($1_EXTRA_HEADER_DIRS), )
 $1_PROCESSED_EXTRA_HEADER_DIRS := $$(foreach dir, $$($1_EXTRA_HEADER_DIRS), \

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

[René Schünemann]

Hi Matthias,

the name SI seems also quite "common" and may result in other naming
clashes in the future.
Maybe something more readable like STAT_IMPL?

Please also change the name in the comment:

// STAT:  String Dedup Stat implementation

Regards,
Rene

On Fri, Jun 15, 2018 at 9:47 AM, Baesken, Matthias
 wrote:
> Please review  this small  change  that fixes the AIX build after  "8203641: 
> Refactor String Deduplication into shared".
>
> We are getting this  compilation error  :
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
>  line 107.38: 1540-0063 (S) The text "1" is unexpected.
>
>
> Looks like the name of the second template parameter (STAT)
>
> template 
> static void initialize_impl();
>
> is clashing with defines from the AIX system headers  (where I find  #define 
> STAT  1 ) .
> Renaming  STAT  to something else fixes the build on AIX .
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8205091
>
>
> Thanks, Matthias

Re: [8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used

[Erik Joelsson]

Looks good.

/Erik


On 2018-06-15 05:59, Severin Gehwolf wrote:

Hi,

This is a JDK 8u specific problem. It's not applicable to 10/11 since
the build system has changed. Make files in JDK 8 live in the hotspot
tree, hence, I'm also including hotspot-dev. The issue at hand is that
linker flags are not consistently passed down to individual library
builds. Specifically libjvm.so, libjsig.so and libsaproc.so. This
prevents downstream users from producing hardened builds. We have been
using this patch in downstream Fedora for a while now without issues.

Please review!

Bug: https://bugs.openjdk.java.net/browse/JDK-8205104
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/

Testing:

Before:
$ for i in 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so;
 do \
echo $i; readelf -d $i | grep NOW
   done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so

After:
$ for i in 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so;
 do \
echo $i; readelf -d $i | grep NOW
   done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
  0x0018 (BIND_NOW)
  0x6ffb (FLAGS_1)Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
  0x0018 (BIND_NOW)
  0x6ffb (FLAGS_1)Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
  0x0018 (BIND_NOW)
  0x6ffb (FLAGS_1)Flags: NOW

Thanks,
Severin

Re: client VM build doesn't build in parallel anymore

[Erik Joelsson]

Hello Matthias,

I believe I know the problem. I fixed it in my patch currently under 
review here (see GensrcJfr.gmk):


http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html

That patch will take a while before it gets in though because it needs 
to go through the JEP process first. Please take just the GensrcJfr.gmk 
patch and try it. That part could be separated out into its own fix.


/Erik


On 2018-06-15 05:04, Matthias Klose wrote:
Since b14 or b15, the client VM on x86 doesn't build anymore when 
building with


  --with-jvm-variants=client,server --with-num-cores=4

building with one to three cores seems to work however. The server and 
zero VMs build without issues and parallel builds.  Any idea which 
dependencies got dropped?


javac: file not found: 
/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
make[4]: *** 
[/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch] 
Error 3
make[4]: *** Deleting file 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch'
gensrc/GensrcJfr.gmk:40: recipe for target 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch' 
failed
make[4]: Leaving directory 
'/home/packages/openjdk/11/openjdk-11-11~18/make/hotspot'

make[3]: *** [hotspot-client-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs
make/Main.gmk:249: recipe for target 'hotspot-client-gensrc' failed

RE: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe

[Peter Budai]

Hi Magnus,

Yes, I have signed OCA last October, and Dalibor Topic has processed it.

I’m happy to work on the msys2 build part with you and Erik.

As far as I recall, the hotspot tests were really close, the number of failed 
test cases seemed to be manageable:
==
Test summary
==
   TEST  TOTAL  PASS  FAIL ERROR
>> jtreg:hotspot/test:hotspot_all 1428  13643331 <<
==


Peter

Sent from Mail for Windows 10


From: Magnus Ihse Bursie 
Sent: Friday, June 15, 2018 3:38:08 PM
To: Peter Budai
Cc: build-dev
Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file 
...fixpath.exe

On 2018-06-12 17:26, Peter Budai wrote:

Hi,



You can find the patches here:

https://github.com/peterbud/MINGW-packages/tree/openjdk/mingw-w64-openjdk



I have managed to build OpenJDK on MSYS2 with gcc, both 32 and 64 bit, but that 
was obviously the beginning. Around 10% of the test cases were failing so more 
work would have been needed. However since December I have not worked on that, 
as (don’t take it personal pls) I have not received feedback on what is the 
best way to work towards reviewing (and ultimately merging) these changes.

Hi Peter,

I think you should split up your work in two parts. The first would be to just 
build OpenJDK on msys2. Since we have been supporting msys in the past, this 
should be trivial to just get pushed.

The next step would probably involve me (or possibly Erik) cleaning up some of 
the logic in the shared build code, were we have incorrectly tested if the OS 
is Windows, when we *really* should have tested if we've using the Microsoft 
toolchain. It's been on my mental todo list for quite some time, but since we 
have up until now had a 1-1 relationship between OS and toolchain, this has not 
been prioritized.

With that in place, your patches can probably be easily adapted. Then comes the 
hard part of figuring out what is causing the failures (if you're lucky it's 
all the symptoms of a very short list of real issues, most likely incorrectly 
compiled code in Hotspot).

We have traditionally have had quite a high bar for allow new ports, but a much 
lower bar for accepting a new compiler for an existing platform, so I assume 
that you will not get as much resistance from that point.

Have you signed the OCA (Oracle Contributor's Agreement)? [1] That's a 
prerequisite for any patches to be accepted.

/Magnus

[1] http://openjdk.java.net/contribute/




Good luck on your journey.



Peter



Sent from Mail for Windows 10




From: Thomas Stüfe 
Sent: Tuesday, June 12, 2018 11:49:00 AM
To: Magnus Ihse Bursie; jbvernee
Cc: build-dev; Peter Budai
Subject: Re: bash configure - LINK : fatal error LNK1104: cannot open file 
...fixpath.exe

I second the advice to get cygwin up and running. Cygwin is the
canonical way to build on windows. Unless you have really pressing
reasons to use something else, I would use what (almost) everyone else
uses.

I have my windows build env up and running on a fresh windows machine
usually in ~30 minutes. It should not be rocket science. I use both
windows 7 and 10 for my work.

Some more points, in additions to what the others wrote:

- 64bit seems to be the standard: 64bit windows, building 64bit ojdk
with a 64bit cygwin. Other configurations may work but are less well
tested. Just something to keep in mind.

- If you do not trust your windows machine and suspect its software
stack may be messed up somehow, there is always the option of
installing a fresh copy of windows in a virtual machine, e.g.
VirtualBox, and install the tool chain from scratch (cygwin + vistual
studio).

Best Regards & good luck,

Thomas




On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
 wrote:
> Hi Jorn,
>
> As you probably have understood by now, porting OpenJDK to msys2 is not just
> a simple quick fix. If all you want is to build OpenJDK on your Windows
> computer, you are probably better off by trying to fix your Cygwin
> installation. From your description, it sounds like you'll need to rebase
> it: http://cygwin.wikia.com/wiki/Rebaseall.
>
> If you want to pursue the msys2 path (and I'd appreciate it; it would be
> good to get OpenJDK working on msys again), I suggest you start by looking
> at the work that had been done before (but never merged into mainline). See
> this conversation:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html
>
> Peter Budai got the msys part working, but he had more ambitious goals of
> getting gcc to build on Windows, which is magnitudes more work, so his patch
> was never finished. Nevertheless, he published a patch in [1] 

Re: bash configure - LINK : fatal error LNK1104: cannot open file ...fixpath.exe

[Magnus Ihse Bursie]

On 2018-06-12 17:26, Peter Budai wrote:


Hi,

You can find the patches here:

https://github.com/peterbud/MINGW-packages/tree/openjdk/mingw-w64-openjdk

I have managed to build OpenJDK on MSYS2 with gcc, both 32 and 64 bit, 
but that was obviously the beginning. Around 10% of the test cases 
were failing so more work would have been needed. However since 
December I have not worked on that, as (don’t take it personal pls) I 
have not received feedback on what is the best way to work towards 
reviewing (and ultimately merging) these changes.



Hi Peter,

I think you should split up your work in two parts. The first would be 
to just build OpenJDK on msys2. Since we have been supporting msys in 
the past, this should be trivial to just get pushed.


The next step would probably involve me (or possibly Erik) cleaning up 
some of the logic in the shared build code, were we have incorrectly 
tested if the OS is Windows, when we *really* should have tested if 
we've using the Microsoft toolchain. It's been on my mental todo list 
for quite some time, but since we have up until now had a 1-1 
relationship between OS and toolchain, this has not been prioritized.


With that in place, your patches can probably be easily adapted. Then 
comes the hard part of figuring out what is causing the failures (if 
you're lucky it's all the symptoms of a very short list of real issues, 
most likely incorrectly compiled code in Hotspot).


We have traditionally have had quite a high bar for allow new ports, but 
a much lower bar for accepting a new compiler for an existing platform, 
so I assume that you will not get as much resistance from that point.


Have you signed the OCA (Oracle Contributor's Agreement)? [1] That's a 
prerequisite for any patches to be accepted.


/Magnus

[1] http://openjdk.java.net/contribute/


Good luck on your journey.

Peter

Sent from Mail  for 
Windows 10



*From:* Thomas Stüfe 
*Sent:* Tuesday, June 12, 2018 11:49:00 AM
*To:* Magnus Ihse Bursie; jbvernee
*Cc:* build-dev; Peter Budai
*Subject:* Re: bash configure - LINK : fatal error LNK1104: cannot 
open file ...fixpath.exe

I second the advice to get cygwin up and running. Cygwin is the
canonical way to build on windows. Unless you have really pressing
reasons to use something else, I would use what (almost) everyone else
uses.

I have my windows build env up and running on a fresh windows machine
usually in ~30 minutes. It should not be rocket science. I use both
windows 7 and 10 for my work.

Some more points, in additions to what the others wrote:

- 64bit seems to be the standard: 64bit windows, building 64bit ojdk
with a 64bit cygwin. Other configurations may work but are less well
tested. Just something to keep in mind.

- If you do not trust your windows machine and suspect its software
stack may be messed up somehow, there is always the option of
installing a fresh copy of windows in a virtual machine, e.g.
VirtualBox, and install the tool chain from scratch (cygwin + vistual
studio).

Best Regards & good luck,

Thomas




On Tue, Jun 12, 2018 at 8:53 AM, Magnus Ihse Bursie
 wrote:
> Hi Jorn,
>
> As you probably have understood by now, porting OpenJDK to msys2 is 
not just

> a simple quick fix. If all you want is to build OpenJDK on your Windows
> computer, you are probably better off by trying to fix your Cygwin
> installation. From your description, it sounds like you'll need to 
rebase

> it: http://cygwin.wikia.com/wiki/Rebaseall.
>
> If you want to pursue the msys2 path (and I'd appreciate it; it would be
> good to get OpenJDK working on msys again), I suggest you start by 
looking
> at the work that had been done before (but never merged into 
mainline). See

> this conversation:
>
> 
http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019897.html

>
> Peter Budai got the msys part working, but he had more ambitious 
goals of
> getting gcc to build on Windows, which is magnitudes more work, so 
his patch

> was never finished. Nevertheless, he published a patch in [1] which got
> stripped by the mailing list. I've put it up here:
>
> http://cr.openjdk.java.net/~ihse/msys2/jdk9-mingw.patch 


>
> It is for jdk9 so it's not possibly to apply out of the box, but you can
> probably see what's been done and trying to reimplement it. I think the
> "magic" part is setting MSYS2_ARG_CONV_EXCL= (the empty string), which
> disables msys2 path mangling.
>
> Good luck!
>
> /Magnus
>
> [1]
> 
http://mail.openjdk.java.net/pipermail/build-dev/2017-October/019883.html

>
>
>
> On 2018-06-11 23:26, jbvernee wrote:
>>
>> Hello,
>>
>> I have tried the MSYS2_ARG_CONV_EXCL environment variable, thanks 
for the

>> suggestion. It's supposed to be a semi-colon separated list of argument
>> prefixes (they have some examples like `/switch;/sdcard;--root=`), so I

Re: [8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used

[Magnus Ihse Bursie]

On 2018-06-15 14:59, Severin Gehwolf wrote:

Hi,

This is a JDK 8u specific problem. It's not applicable to 10/11 since
the build system has changed. Make files in JDK 8 live in the hotspot
tree, hence, I'm also including hotspot-dev. The issue at hand is that
linker flags are not consistently passed down to individual library
builds. Specifically libjvm.so, libjsig.so and libsaproc.so. This
prevents downstream users from producing hardened builds. We have been
using this patch in downstream Fedora for a while now without issues.

Looks good to me.

Seeing this makes me realize I'm *soo* happy to not have to live with 
the old hotspot build system anymore. :-)


/Magnus



Please review!

Bug: https://bugs.openjdk.java.net/browse/JDK-8205104
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/

Testing:

Before:
$ for i in 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so;
 do \
echo $i; readelf -d $i | grep NOW
   done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so

After:
$ for i in 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 \
  
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so;
 do \
echo $i; readelf -d $i | grep NOW
   done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
  0x0018 (BIND_NOW)
  0x6ffb (FLAGS_1)Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
  0x0018 (BIND_NOW)
  0x6ffb (FLAGS_1)Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
  0x0018 (BIND_NOW)
  0x6ffb (FLAGS_1)Flags: NOW

Thanks,
Severin

Re: RFR: JDK-8200867 Remove references to "jdk 9" in build system

[Magnus Ihse Bursie]

(reviving an old review thread)

On 2018-05-25 18:17, Erik Joelsson wrote:


On 2018-05-25 06:52, Tim Bell wrote:

Magnus-

On 05/25/18 04:23, Claes Redestad wrote:

On 2018-05-25 12:06, Magnus Ihse Bursie wrote:

WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01 





Looks good to me!

/Claes



Looks good!

doc/building.md
doc/building.html

These files also have changes to minimum gcc versions 
(4.7/4.8/4.9.2/7.3.0) - is that for a different bug number?


I believe he is just updating outdated numbers in the doc that he 
stumbled on. The changes are all correct.

You are correct.

However, when all dust has settled with the new compiler upgrades (and 
possibly removal of support for older configurations) we should make 
sure that the build documentation is correct and up to date. I'm passing 
that ball on to you, Erik. :-)


/Magnus



/Erik

Looks good to me otherwise.

/Tim

[8u] RFR: 8205104: EXTRA_LDFLAGS not consistently being used

[Severin Gehwolf]

Hi,

This is a JDK 8u specific problem. It's not applicable to 10/11 since
the build system has changed. Make files in JDK 8 live in the hotspot
tree, hence, I'm also including hotspot-dev. The issue at hand is that
linker flags are not consistently passed down to individual library
builds. Specifically libjvm.so, libjsig.so and libsaproc.so. This
prevents downstream users from producing hardened builds. We have been
using this patch in downstream Fedora for a while now without issues.

Please review!

Bug: https://bugs.openjdk.java.net/browse/JDK-8205104
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8205104/webrev.01/

Testing:

Before:
$ for i in 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 \
 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 \
 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so;
 do \
   echo $i; readelf -d $i | grep NOW
  done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so

After:
$ for i in 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 \
 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 \
 
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so;
 do \
   echo $i; readelf -d $i | grep NOW
  done
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
 0x0018 (BIND_NOW)   
 0x6ffb (FLAGS_1)Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libsaproc.so
 0x0018 (BIND_NOW)   
 0x6ffb (FLAGS_1)Flags: NOW
build/linux-x86_64-normal-server-release/images/j2sdk-image/jre/lib/amd64/libjsig.so
 0x0018 (BIND_NOW)   
 0x6ffb (FLAGS_1)Flags: NOW

Thanks,
Severin

Re: RFR: JDK-8205055: Fix compilation optimization errors with new Solaris toolchain

[Magnus Ihse Bursie]

On 2018-06-15 01:26, gary.ad...@oracle.com wrote:

Locally tested the fix below and via mach5 jobs.
The ~50 failed tests all completed successfully.
It'd be good for Erik to repeat his full testing with
this patch included in case it blocked other issues
from being observed.

This fix can be integrated after the sync from jdk/client.

 Issue: https://bugs.openjdk.java.net/browse/JDK-8205055

Proposed fix:

diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk 
b/make/hotspot/lib/JvmOverrideFiles.gmk

--- a/make/hotspot/lib/JvmOverrideFiles.gmk
+++ b/make/hotspot/lib/JvmOverrideFiles.gmk
@@ -74,6 +74,8 @@

 else ifeq ($(OPENJDK_TARGET_OS), solaris)
   ifneq ($(DEBUG_LEVEL), slowdebug)
+ # dev studio 12.6 workaround
+ BUILD_LIBJVM_arguments.cpp_OPTIMIZATION := LOW


The if should test
ifeq ($(TOOLCHAIN_TYPE), solstudio)
since this is a compiler issue, not an OS issue.

Ideally, it should also test if using version 12.6, but unfortunately 
there's currently no elegant way of expressing that in the makefiles, so 
I'm OK with the workaround of just having a comment. I assume, from the 
name and a quick glance at the file, that the contents makes it unlikely 
that a lowevered optimization level wouldprovoke a performance 
regression in pre-12.6 solstudio compilations.


Still, it would be nice if you are able to drill down the issue to 
figure out exactly why a higher optimization level causes this file to 
be incorrectly compiled. It might be code in hotspot with undefined 
behavior, or it might be bugs in solstudio. In any case, it should be 
addressed. As an initial fix to allow compilation to proceed, this is 
fine, though.


/Magnus

Re: client VM build doesn't build in parallel anymore

[Magnus Ihse Bursie]

There was a race with the JFR build tools when building multiple JVMs. 
:-( Erik produced a fix for this as part of  JDK-8202384), unfortunately 
this has not yet been pushed.


You can find the JFR fix part here: 
http://cr.openjdk.java.net/~erikj/8202384/webrev.05/make/hotspot/gensrc/GensrcJfr.gmk.udiff.html


If you apply it locally, it should resolve your issue.

If JDK-8202384 takes much longer to push, hopefully Erik can separate 
out this trivial part (which is already reviewed by me as part of 
JDK-8202384) and push it separately.


/Magnus



On 2018-06-15 14:04, Matthias Klose wrote:
Since b14 or b15, the client VM on x86 doesn't build anymore when 
building with


  --with-jvm-variants=client,server --with-num-cores=4

building with one to three cores seems to work however. The server and 
zero VMs build without issues and parallel builds.  Any idea which 
dependencies got dropped?


javac: file not found: 
/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
make[4]: *** 
[/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch] 
Error 3
make[4]: *** Deleting file 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch'
gensrc/GensrcJfr.gmk:40: recipe for target 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch' 
failed
make[4]: Leaving directory 
'/home/packages/openjdk/11/openjdk-11-11~18/make/hotspot'

make[3]: *** [hotspot-client-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs
make/Main.gmk:249: recipe for target 'hotspot-client-gensrc' failed

client VM build doesn't build in parallel anymore

[Matthias Klose]

Since b14 or b15, the client VM on x86 doesn't build anymore when building with

  --with-jvm-variants=client,server --with-num-cores=4

building with one to three cores seems to work however. The server and zero VMs 
build without issues and parallel builds.  Any idea which dependencies got dropped?


javac: file not found: 
/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch.tmp
make[4]: *** 
[/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch] 
Error 3
make[4]: *** Deleting file 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch'
gensrc/GensrcJfr.gmk:40: recipe for target 
'/home/packages/openjdk/11/openjdk-11-11~18/build/buildtools/tools_classes/_the.BUILD_JFR_TOOLS_batch' 
failed

make[4]: Leaving directory 
'/home/packages/openjdk/11/openjdk-11-11~18/make/hotspot'
make[3]: *** [hotspot-client-gensrc] Error 2
make[3]: *** Waiting for unfinished jobs
make/Main.gmk:249: recipe for target 'hotspot-client-gensrc' failed

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

On 06/15/2018 01:10 PM, Magnus Ihse Bursie wrote:
> I think I understand the underlying issue but I'm not sure how to try 
> reproduce a build problem from it.

I have an openSUSE box here, so I should be able to reproduce it :).

> Here's a better patch. Please try and see if it solves your problems. 
> Unfortunately, I'm leaving on vacation for today and will be gone most of the 
> summer, so I can't help sponsor this patch. But if it works, I'm sure someone 
> else can take over it.

Don't worry. I will help Fridrich to sort this issue out.

> If it does not work, the original patch should at the very least be changed 
> so that EXTRA_HEADER_DIRS gets an additional "$(call GetJavaHeaderDir, 
> $(MODULE))", instead of the -I (which I've been trying hard to eradicate from 
> the CFLAGS).
Thanks for the heads-up! I will test your patch in any case.

Adrian

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

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[Magnus Ihse Bursie]

On 2018-06-15 10:57, John Paul Adrian Glaubitz wrote:

Hi Fridrich!

I can help you getting this issue fixed. If I remember correctly, you said
that SUSE has signed Oracle's OCA, so I it should be fine if I submit the
patch with you as the author.

Let me have a look at the problem first though.


I think I understand the underlying issue but I'm not sure how to try 
reproduce a build problem from it.


Here's a better patch. Please try and see if it solves your problems. 
Unfortunately, I'm leaving on vacation for today and will be gone most 
of the summer, so I can't help sponsor this patch. But if it works, I'm 
sure someone else can take over it.


If it does not work, the original patch should at the very least be 
changed so that EXTRA_HEADER_DIRS gets an additional "$(call 
GetJavaHeaderDir, $(MODULE))", instead of the -I (which I've been trying 
hard to eradicate from the CFLAGS).


diff --git a/make/common/JdkNativeCompilation.gmk 
b/make/common/JdkNativeCompilation.gmk

--- a/make/common/JdkNativeCompilation.gmk
+++ b/make/common/JdkNativeCompilation.gmk
@@ -119,9 +119,11 @@
   endif

   ifneq ($$($1_HEADERS_FROM_SRC), false)
-    $1_SRC_HEADER_FLAGS := $$(foreach dir, $$(wildcard $$($1_SRC) \
-    $$(call GetJavaHeaderDir, $$(MODULE))), -I$$(dir))
+    $1_SRC_HEADER_FLAGS := $$(addprefix -I, $$(wildcard $$($1_SRC)))
   endif
+  # Always add the java header dir
+  $1_SRC_HEADER_FLAGS := $$(addprefix -I, $$(call GetJavaHeaderDir, 
$$(MODULE)))

+
   ifneq ($$($1_EXTRA_HEADER_DIRS), )
 $1_PROCESSED_EXTRA_HEADER_DIRS := $$(foreach dir, 
$$($1_EXTRA_HEADER_DIRS), \

 $$(call ProcessDir, $$(dir)))


/Magnus





Adrian

On 06/15/2018 10:27 AM, Severin Gehwolf wrote:

Just for the completeness, this is a normal openSUSE package build with
--with-system-jpeg and --with-system-lcms. Maybe the
LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
able to build jdk-11+18 with bundled jpeg and lcms without problems.

Cheers

Fridrich

On 15/06/18 09:31, Fridrich Strba wrote:

Hello, good people,

Since I cannot submit anything to bugzilla, I spam this list with this
patch that I needed to be able to build jdk-11+18.

I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
the way the headers are included, but in my analysis, the generated
headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
the new way of doing. The patch makes it build for me. Do what you want
with it :)

Fridrich

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

[Thomas Stüfe]

Hi Matthias,

Good catch. Patch for me is good if you guys agree on a good uncommon name.

Gruß Thomas

On Fri, Jun 15, 2018, 09:48 Baesken, Matthias 
wrote:

> Please review  this small  change  that fixes the AIX build after
> "8203641: Refactor String Deduplication into shared".
>
> We are getting this  compilation error  :
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
> line 107.38: 1540-0063 (S) The text "1" is unexpected.
>
>
> Looks like the name of the second template parameter (STAT)
>
> template 
> static void initialize_impl();
>
> is clashing with defines from the AIX system headers  (where I find
> #define STAT  1 ) .
> Renaming  STAT  to something else fixes the build on AIX .
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8205091
>
>
> Thanks, Matthias
>

RE: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

[Baesken, Matthias]

Hi  , thanks for looking into it.
I think I  will use  STAT_IMPL  .

Best regards, Matthias


> -Original Message-
> From: René Schünemann [mailto:rene.schuenem...@gmail.com]
> Sent: Freitag, 15. Juni 2018 11:08
> To: Baesken, Matthias 
> Cc: build-dev@openjdk.java.net; hotspot-...@openjdk.java.net
> Subject: Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: 
> Refactor
> String Deduplication into shared
> 
> Hi Matthias,
> 
> the name SI seems also quite "common" and may result in other naming
> clashes in the future.
> Maybe something more readable like STAT_IMPL?
> 
> Please also change the name in the comment:
> 
> // STAT:  String Dedup Stat implementation
> 
> Regards,
> Rene
> 
> On Fri, Jun 15, 2018 at 9:47 AM, Baesken, Matthias
>  wrote:
> > Please review  this small  change  that fixes the AIX build after  "8203641:
> Refactor String Deduplication into shared".
> >
> > We are getting this  compilation error  :
> >
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stri
> ngDedup.hpp", line 107.38: 1540-0063 (S) The text "1" is unexpected.
> >
> >
> > Looks like the name of the second template parameter (STAT)
> >
> > template 
> > static void initialize_impl();
> >
> > is clashing with defines from the AIX system headers  (where I find  #define
> STAT  1 ) .
> > Renaming  STAT  to something else fixes the build on AIX .
> >
> > Webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
> >
> > Bug :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8205091
> >
> >
> > Thanks, Matthias

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

[Volker Simonis]

Hi Mattias,

the change looks good. Could you please also update the comment in the
line above which still reads "STAT".

Also, maybe "STATI" would be a better name choice (longer is better :)
because the probability of a clash is lower (and it would nicely align
with QUEUE in the comments :) But I leave that up to you...

Regards,
Volker


On Fri, Jun 15, 2018 at 9:47 AM, Baesken, Matthias
 wrote:
> Please review  this small  change  that fixes the AIX build after  "8203641: 
> Refactor String Deduplication into shared".
>
> We are getting this  compilation error  :
> /build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
>  line 107.38: 1540-0063 (S) The text "1" is unexpected.
>
>
> Looks like the name of the second template parameter (STAT)
>
> template 
> static void initialize_impl();
>
> is clashing with defines from the AIX system headers  (where I find  #define 
> STAT  1 ) .
> Renaming  STAT  to something else fixes the build on AIX .
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205091/
>
> Bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8205091
>
>
> Thanks, Matthias

Re: [Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[John Paul Adrian Glaubitz]

Hi Fridrich!

I can help you getting this issue fixed. If I remember correctly, you said
that SUSE has signed Oracle's OCA, so I it should be fine if I submit the
patch with you as the author.

Let me have a look at the problem first though.

Adrian

On 06/15/2018 10:27 AM, Severin Gehwolf wrote:
> Just for the completeness, this is a normal openSUSE package build with
> --with-system-jpeg and --with-system-lcms. Maybe the
> LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
> able to build jdk-11+18 with bundled jpeg and lcms without problems.
> 
> Cheers
> 
> Fridrich
> 
> On 15/06/18 09:31, Fridrich Strba wrote:
>> Hello, good people,
>>
>> Since I cannot submit anything to bugzilla, I spam this list with this
>> patch that I needed to be able to build jdk-11+18.
>>
>> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
>> the way the headers are included, but in my analysis, the generated
>> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
>> the new way of doing. The patch makes it build for me. Do what you want
>> with it :)
>>
>> Fridrich
>>
> 

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

[Fwd: Re: Build breakage with system jpeg and lcms and jdk-11+18]

[Severin Gehwolf]

Forwarding to build-dev.--- Begin Message ---
Just for the completeness, this is a normal openSUSE package build with
--with-system-jpeg and --with-system-lcms. Maybe the
LIBJPEG_HEADERS_FROM_SRC := false is culprit. Some other people were
able to build jdk-11+18 with bundled jpeg and lcms without problems.

Cheers

Fridrich

On 15/06/18 09:31, Fridrich Strba wrote:
> Hello, good people,
> 
> Since I cannot submit anything to bugzilla, I spam this list with this
> patch that I needed to be able to build jdk-11+18.
> 
> I saw that http://hg.openjdk.java.net/jdk/jdk/rev/f0aeede1b855 changed
> the way the headers are included, but in my analysis, the generated
> headers in $(SUPPORT_OUTPUTDIR)/headers/java.desktop were not added by
> the new way of doing. The patch makes it build for me. Do what you want
> with it :)
> 
> Fridrich
> 


--- End Message ---

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

[Volker Simonis]

On Thu, Jun 14, 2018 at 9:04 PM, Thomas Stüfe  wrote:
> Hi Volker,
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/make/autoconf/hotspot.m4.udiff.html
>
> Seems like a roundabout way to have a platform specific default value.
>
> Why not determine a default value beforehand:
>
> if test "x$OPENJDK_TARGET_OS" = "xaix"; then
>   ENABLE_CDS_DEFAULT="false"
> else
>   ENABLE_CDS_DEFAULT=true"
> fi
>
> AC_ARG_ENABLE([cds], [AS_HELP_STRING([--enable-cds@<:@=yes/no/auto@:>@],
>  [enable class data sharing feature in non-minimal VM. Default is
> ${ENABLE_CDS_DEFAULT}.])])
>
> and so on?
>

I've just followed the pattern used for '--enable-aot' right above the
code I changed.

Moreover, I don't think that we would save any code because we would
still have to check for AIX in the '--enable-cds=yes' case. Also, the
new reporting added later in the file (see "AC_MSG_CHECKING([if cds
should be enabled])" seems easier to me without the extra default
value. So if you don't mind I'd prefer to leave it as is.

> See also what we did for "8202325: [aix] disable warnings-as-errors by 
> default".
>
> --
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/src/hotspot/share/classfile/javaClasses.cpp.udiff.html
>
> Here, do we really need to exclude this from compiling,
> DumpSharedSpaces = false is not enough?
>

Yes, we need it because the excluded code references methods (e.g.
'StringTable::create_archived_string()') which are not compiled into
libjvm.so if we disable CDS.

>
> Best Regards, Thomas
>
> On Thu, Jun 14, 2018 at 4:26 PM, Volker Simonis
>  wrote:
>> Hi,
>>
>> can I please have a review for the following fix:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
>> https://bugs.openjdk.java.net/browse/JDK-8204965
>>
>> CDS does currently not work on AIX because of the way how we
>> reserve/commit memory on AIX. The problem is that we're using a
>> combination of shmat/mmap depending on the page size and the size of
>> the memory chunk to reserve. This makes it impossible to reliably
>> reserve the memory for the CDS archive and later on map the various
>> parts of the archive into these regions.
>>
>> In order to fix this we would have to completely rework the memory
>> reserve/commit/uncommit logic on AIX which is currently out of our
>> scope because of resource limitations.
>>
>> Unfortunately, I could not simply disable CDS in the configure step
>> because some of the shared code apparently relies on parts of the CDS
>> code which gets excluded from the build when CDS is disabled. So I
>> also fixed the offending parts in hotspot and cleaned up the configure
>> logic for CDS.
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: I did run the job through the submit forest
>> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
>> weren't really useful because they mention build failures on linux-x64
>> which I can't reproduce locally.

RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

[Baesken, Matthias]

Please review  this small  change  that fixes the AIX build after  "8203641: 
Refactor String Deduplication into shared".

We are getting this  compilation error  :
/build_ci_jdk_jdk_rs6000_64/src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp",
 line 107.38: 1540-0063 (S) The text "1" is unexpected.


Looks like the name of the second template parameter (STAT)

template 
static void initialize_impl();

is clashing with defines from the AIX system headers  (where I find  #define 
STAT  1 ) .
Renaming  STAT  to something else fixes the build on AIX .

Webrev :

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

Bug :

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


Thanks, Matthias

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

[Volker Simonis]

Hi Jiangli,

thanks for looking at the change.

'CDS_only' is only required for static fields because the
VMStructEntry for them contains a reference to the actual static field
which isn't present if we disable CDS, because the corresponding
compilations units (i.e. filemap.cpp) won't be part of libjvm.so. For
non-static fields, the VMStructEntry structure only contains the
offset of the corresponding field with regards to an object of that
type which is harmless.

Regards,
Volker


On Thu, Jun 14, 2018 at 6:42 PM, Jiangli Zhou  wrote:
> Hi Volker,
>
> The changes look good to me overall. I’ll refer to the JVMTI experts for
> jvmtiEnv.cpp change. I have a question for the change in vmStructs.cpp. Any
> reason why only _current_info needs CDS_ONLY?
>
>//
> \
>/* FileMapInfo fields (CDS archive related) */
> \
>//
> \
>
> \
>nonstatic_field(FileMapInfo, _header,
> FileMapInfo::FileMapHeader*)   \
> - static_field(FileMapInfo, _current_info,
> FileMapInfo*)  \
> + CDS_ONLY(static_field(FileMapInfo,_current_info,
> FileMapInfo*)) \
>nonstatic_field(FileMapInfo::FileMapHeader,  _space[0],
> FileMapInfo::FileMapHeader::space_info)\
>nonstatic_field(FileMapInfo::FileMapHeader::space_info, _addr._base,
> char*) \
>nonstatic_field(FileMapInfo::FileMapHeader::space_info, _used,
> size_t)\
>
> \
>
> Thanks,
> Jiangli
>
> On Jun 14, 2018, at 7:26 AM, Volker Simonis 
> wrote:
>
> Hi,
>
> can I please have a review for the following fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/
> https://bugs.openjdk.java.net/browse/JDK-8204965
>
> CDS does currently not work on AIX because of the way how we
> reserve/commit memory on AIX. The problem is that we're using a
> combination of shmat/mmap depending on the page size and the size of
> the memory chunk to reserve. This makes it impossible to reliably
> reserve the memory for the CDS archive and later on map the various
> parts of the archive into these regions.
>
> In order to fix this we would have to completely rework the memory
> reserve/commit/uncommit logic on AIX which is currently out of our
> scope because of resource limitations.
>
> Unfortunately, I could not simply disable CDS in the configure step
> because some of the shared code apparently relies on parts of the CDS
> code which gets excluded from the build when CDS is disabled. So I
> also fixed the offending parts in hotspot and cleaned up the configure
> logic for CDS.
>
> Thank you and best regards,
> Volker
>
> PS: I did run the job through the submit forest
> (mach5-one-simonis-JDK-8204965-20180613-1946-26349) but the results
> weren't really useful because they mention build failures on linux-x64
> which I can't reproduce locally.
>
>