Re: [PATCH] Fail to build zero on x86

[Ao Qi]

Hi John,

Thanks!
PS: It seems that the build begins to fail after this changeset:
http://hg.openjdk.java.net/jdk/jdk/rev/fb290fd1f9d4

Ao Qi

2018-01-10 7:58 GMT+08:00 John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de>:

> On 01/10/2018 12:27 AM, John Paul Adrian Glaubitz wrote:> which is the
> same configure line that the openjdk-7/8/9/10 packages in Debian> use.
> Sounds like a good
> idea to fix this warning though.
> PS: I'm happy to review and sponsor your change. But tomorrow :).
>
> 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: [PATCH] Fail to build zero on x86

[Ao Qi]

Hi John,


> I assume that you eventually want to build OpenJDK for MIPS, correct (from
> your
> email address)? If yes, there are actually two additional patches
> necessary to
> get Zero to build on MIPS. In particular, jvmsigs cannot encode all signals
> found on MIPS. I should finally get around to work on this.
>
>
Thanks for your information. We have a Jenkins server to build OpenJDK
8/9/10 on x86 and MIPS (loongson3a), and I have already used those
patches:) Hope those patches can be submitted to upstream.

Ao Qi

Re: [PATCH] Fail to build zero on x86

[John Paul Adrian Glaubitz]

On 01/10/2018 12:27 AM, John Paul Adrian Glaubitz wrote:> which is the same 
configure line that the openjdk-7/8/9/10 packages in Debian> use. Sounds like a 
good
idea to fix this warning though.
PS: I'm happy to review and sponsor your change. But tomorrow :).

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: [PATCH] Fail to build zero on x86

[John Paul Adrian Glaubitz]

Hi Ao!

On 01/09/2018 11:23 PM, Martin Buchholz wrote:
>> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/
>> safepoint.cpp:730:25:
>> error: '' may be used uninitialized in this function
>> [-Werror=maybe-uninitialized]
>>  if (stub_cb != NULL &&
>>  ^

Ah, this might be because you're not building with --disable-warnings-as-errors
which I always use. I always build with:

sh ./configure --with-jvm-variants=zero 
--with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ 
--disable-precompiled-headers --disable-warnings-as-errors && make
JOBS=32 MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release

which is the same configure line that the openjdk-7/8/9/10 packages in Debian
use. Sounds like a good idea to fix this warning though.

I assume that you eventually want to build OpenJDK for MIPS, correct (from your
email address)? If yes, there are actually two additional patches necessary to
get Zero to build on MIPS. In particular, jvmsigs cannot encode all signals
found on MIPS. I should finally get around to work on this.

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: [PATCH] Fail to build zero on x86

[Martin Buchholz]

[build-dev redirect]

On Tue, Jan 9, 2018 at 2:16 AM, Ao Qi  wrote:

> Hi,
>
> I found it failed to build zero. The repository I used is
> http://hg.openjdk.java.net/jdk/jdk
> I get this error (on Ubuntu 16.04 x86):
>
> $ sh configure  --with-boot-jdk=/my-path-to-jdk9 --with-jvm-variants=zero
> $ make hotspot
> Building target 'hotspot' in configuration
> 'linux-x86_64-normal-zero-release'
> Compiling 2 files for BUILD_JVMTI_TOOLS
> Creating support/modules_libs/java.base/libjsig.so from 1 file(s)
> Creating support/modules_libs/java.base/server/libjvm.so from 578 file(s)
> Creating hotspot/variant-zero/libjvm/gtest/libjvm.so from 76 file(s)
> Creating hotspot/variant-zero/libjvm/gtest/gtestLauncher from 1 file(s)
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
> function 'static void
> SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
> JavaThreadState)':
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/
> safepoint.cpp:730:25:
> error: '' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>  if (stub_cb != NULL &&
>  ^
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
> static member function 'static void
> SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
> JavaThreadState)':
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/
> safepoint.cpp:730:25:
> error: '' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> cc1plus: all warnings being treated as errors
> lib/CompileJvm.gmk:212: recipe for target
> '/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-
> zero-release/hotspot/variant-zero/libjvm/objs/safepoint.o'
> failed
> make[3]: ***
> [/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-
> zero-release/hotspot/variant-zero/libjvm/objs/safepoint.o]
> Error 1
> make[3]: *** Waiting for unfinished jobs
> make/Main.gmk:268: recipe for target 'hotspot-zero-libs' failed
> make[2]: *** [hotspot-zero-libs] Error 1
>
> ERROR: Build failed for target 'hotspot' in configuration
> 'linux-x86_64-normal-zero-release' (exit code 2)
>
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-zero_libjvm_objs_safepoint.o:
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
> function 'static void
> SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
> JavaThreadState)':
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/
> safepoint.cpp:730:25:
> error: '' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>  if (stub_cb != NULL &&
>  ^
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/safepoint.cpp: In
> static member function 'static void
> SafepointSynchronize::check_for_lazy_critical_native(JavaThread*,
> JavaThreadState)':
> /home/loongson/aoqi/jdk10/jdk/src/hotspot/share/runtime/
> safepoint.cpp:730:25:
> error: '' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> cc1plus: all warnings being treated as errors
>
> * All command lines available in
> /home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-
> zero-release/make-support/failure-logs.
> === End of repeated output ===
>
> === Make failed targets repeated here ===
> lib/CompileJvm.gmk:212: recipe for target
> '/home/loongson/aoqi/jdk10/jdk/build/linux-x86_64-normal-
> zero-release/hotspot/variant-zero/libjvm/objs/safepoint.o'
> failed
> make/Main.gmk:268: recipe for target 'hotspot-zero-libs' failed
> === End of repeated output ===
>
> Hint: Try searching the build log for the name of the first failed target.
> Hint: See doc/building.html#troubleshooting for assistance.
>
> /home/loongson/aoqi/jdk10/jdk/make/Init.gmk:291: recipe for target 'main'
> failed
> make[1]: *** [main] Error 1
> /home/loongson/aoqi/jdk10/jdk/make/Init.gmk:186: recipe for target
> 'hotspot' failed
> make: *** [hotspot] Error 2
>
>
> I made a small patch to pass the build. Could someone help to review and
> submit this patch? I had signed OCA.
>
> patch:
>
> diff -r 9a29aa153c20 src/hotspot/cpu/zero/frame_zero.inline.hpp
> --- a/src/hotspot/cpu/zero/frame_zero.inline.hpp Mon Jan 08 07:13:27 2018
> -0800
> +++ b/src/hotspot/cpu/zero/frame_zero.inline.hpp Tue Jan 09 15:38:05 2018
> +0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights
> reserved.
>   * Copyright 2007, 2008, 2009, 2010 Red Hat, Inc.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
> @@ -43,23 +43,16 @@
>  inline frame::frame(ZeroFrame* zf, intptr_t* sp) {
>_zeroframe = zf;
>_sp = sp;
> +  _cb = NULL;
> +  _deopt_state = not_deoptimized;
>switch (zeroframe()->type()) {
>case ZeroFrame::ENTRY_FRAME:
>  _pc = StubRoutines::call_stub_return_pc();
> -_cb = NULL;
> -

Re: jdk10 on macOS

[Alan Snyder]

I already tried make test-image; make run-test-tier1 and it had no impact on 
the outcome. Given that, do you still want me to try your suggestion?

  Alan


> On Jan 8, 2018, at 11:28 PM, Magnus Ihse Bursie 
>  wrote:
> 
> 
>> 8 jan. 2018 kl. 23:23 skrev David Holmes :
>> 
>>> On 9/01/2018 4:35 AM, Jonathan Gibbons wrote:
>>> Maybe the Makefile targets to run tests could report an up-front warning if 
>>> the native libraries have not been built.
>> 
>> Based on my observations the makefile target will also build the test-image 
>> if needed.
> 
> That's the idea, yes. However I'm afraid there might be a bug wrt this when 
> using the generated "run-test-*" targets, as opposed to the generic 
> "run-test" target. :(
> 
> Alan, can you try running "make run-test TEST=tier1" instead? This should 
> definitely pull in the generation of the test image. 
> 
> I also do apologize that the simple build README instructions did not work 
> out of the box. :(
> 
> /Magnus
> 
>> 
>> David
>> 
>>> A more advanced solution would be to use jtreg to determine if any native 
>>> tests will be run (using some combination of `-k native` and `-listtests`) 
>>> and if any such tests are found, then require the library to be available.
>>> -- Jon
>>> On 01/05/2018 06:37 PM, Alan Snyder wrote:
 Following the instructions for the impatient, I did make images and then 
 make run-test-tier1.
 Then after replacing the jtreg with the one Jon recommended, I did make 
 run-test-tier1 again.
 
   Alan
 
 
> On Jan 5, 2018, at 6:32 PM, David Holmes  wrote:
> 
> On 6/01/2018 12:05 PM, Alan Snyder wrote:
>> The tests were run via make.
> How exactly? And did you do "make test-image" first?
> 
> David
> 
>>> On Jan 5, 2018, at 4:13 PM, David Holmes  
>>> wrote:
>>> 
>>> Alan,
>>> 
>>> Unclear how you ran the tests, but:
>>> 
>>> TEST RESULT: Error. Use -nativepath to specify the location of native 
>>> code
>>> 
>>> indicates jtreg was not passed the -nativepath flag. That may or may 
>>> not be a build issue depending on whether the tests were executed 
>>> directly or via "make".
>>> 
>>> Cheers,
>>> David
>>> 
 On 6/01/2018 8:43 AM, Alan Snyder wrote:
 5 test failures remain using jtreg-4.2.0-tip:
 --
 TEST: java/lang/String/nativeEncoding/StringPlatformChars.java
 TEST JDK: 
 /Volumes/A/JDK/jdk10/build/macosx-x86_64-normal-server-release/images/jdk
  
 ACTION: build -- Passed. Build successful
 REASON: Named class compiled on demand
 TIME: 1.179 seconds
 messages:
 command: build StringPlatformChars
 reason: Named class compiled on demand
 Test directory:
 compile: StringPlatformChars
 elapsed time (seconds): 1.179
 ACTION: compile -- Passed. Compilation successful
 REASON: .class file out of date or does not exist
 TIME: 0.626 seconds
 messages:
 command: compile 
 /Volumes/A/JDK/jdk10/test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java
  
 reason: .class file out of date or does not exist
 Mode: agentvm
 Agent id: 1
 elapsed time (seconds): 0.626
 configuration:
 Boot Layer (javac runtime environment)
 class path: /Users/alan/javalib/share/jtreg/lib/javatest.jar
 /Users/alan/javalib/share/jtreg/lib/jtreg.jar
 patch: java.base 
 /Volumes/A/JDK/jdk10/build/macosx-x86_64-normal-server-release/test-support/jtreg_Volumes_A_JDK_jdk10_test_jdk_tier1/patches/java.base
  
 javac compilation environment
 source path: 
 /Volumes/A/JDK/jdk10/test/jdk/java/lang/String/nativeEncoding
 class path: 
 /Volumes/A/JDK/jdk10/test/jdk/java/lang/String/nativeEncoding
 /Volumes/A/JDK/jdk10/build/macosx-x86_64-normal-server-release/test-support/jtreg_Volumes_A_JDK_jdk10_test_jdk_tier1/classes/4/java/lang/String/nativeEncoding/StringPlatformChars.d
  
 rerun:
 cd 
 /Volumes/A/JDK/jdk10/build/macosx-x86_64-normal-server-release/test-support/jtreg_Volumes_A_JDK_jdk10_test_jdk_tier1/scratch/0
  && \
 HOME=/Users/alan \
 JDK8_HOME=/Library/Java/JavaVirtualMachines/1.9.0.jdk/Contents/Home \
 LANG=en_US.UTF-8 \
 LC_ALL=en_US.UTF-8 \
 PATH=/bin:/usr/bin \
 /Volumes/A/JDK/jdk10/build/macosx-x86_64-normal-server-release/images/jdk/bin/javac
  \
 -J-Xmx512m \
 -J-XX:MaxRAMPercentage=3 \
 -J-ea \
 -J-esa \
 

Re: RFR: 8194636 - Apply CONCURRENCY_FACTOR to max value in concurrency calculation

[Erik Joelsson]

Looks good.

/Erik


On 2018-01-09 06:03, Christian Tornqvist wrote:

Please review this small change that allows the CONCURRENCY_FACTOR to also be 
applied when we hit the max value (currently 12) when calculating concurrency.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8194636/webrev.00/ 


Thanks,
Christian

RFR: 8194636 - Apply CONCURRENCY_FACTOR to max value in concurrency calculation

[Christian Tornqvist]

Please review this small change that allows the CONCURRENCY_FACTOR to also be 
applied when we hit the max value (currently 12) when calculating concurrency.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8194636/webrev.00/ 


Thanks,
Christian