Re: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto

[Magnus Ihse Bursie]

Looks good to me.

/Magnus

> 8 dec. 2016 kl. 00:21 skrev Valerie Peng :
> 
> Anyone can help reviewing this? 
> 
> The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to address 
> the E_MACRO_REDEFINED warning. 
> In addition, I also updated the nativeCrypto.h to remove the workaround for a 
> Solaris12-specific issue which has now been fixed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8079898 
> Webrev: http://cr.openjdk.java.net/~valeriep/8079898/webrev.00/ 
> 
> JPRT result looks fine. 
> 
> Thanks, 
> 
> Valerie 

Re: Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

[Naoto Sato]

Hi Mandy,

Just noticed that the CLDR license is located under jdk.localedata 
module. That needs to be moved into java.base, as its English resource 
files are derived from CLDR too.


Naoto

On 12/7/16 1:28 PM, Mandy Chung wrote:

This proposes to organize license files by module in source, JMOD,
and run-time image.

A summary of the proposal:
1. Organize third party notices by module in the source as follows:
src/$MODULE/{share,$OS}/legal/*

The `legal` directory contains one file for each third party
library in the module, for example,
src/java.base/share/legal/asm.md
  unicode.md
  zlib.md

The proposed template for this file is described in [1] and JEP 201
will be updated to reflect this proposed source layout.

2. Introduce a new LEGAL_NOTICES section in JMOD format. A new jmod
   option `—-legal-notices` is added to package legal notices in
   a JMOD file.

3. At jlink time, jlink will copy all legal notices from JMOD files
   to the `legal` directory in the run-time image.  A plugin is
   added to de-duplicate the legal notices if the filename and the
   content matches that may reduce the image footprint.

4. THIRD_PARTY_README in the top-level directory of each repo is removed.
   Manual edit to this file, multiple copies is no longer needed.

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169925/webrev.00/

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8169925

Re: [9] RFR 8079898: Resolve disabled warnings for libj2ucrypto

[Anthony Scarpino]

On 12/07/2016 03:21 PM, Valerie Peng wrote:

Anyone can help reviewing this?

The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to
address the E_MACRO_REDEFINED warning.
In addition, I also updated the nativeCrypto.h to remove the workaround
for a Solaris12-specific issue which has now been fixed.


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

JPRT result looks fine.

Thanks,

Valerie



looks fine to me.

Tony

[9] RFR 8079898: Resolve disabled warnings for libj2ucrypto

[Valerie Peng]

Anyone can help reviewing this?

The fix is straight forward, just renamed the DEBUG to J2UC_DEBUG to 
address the E_MACRO_REDEFINED warning.
In addition, I also updated the nativeCrypto.h to remove the workaround 
for a Solaris12-specific issue which has now been fixed.



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

JPRT result looks fine.

Thanks,

Valerie

Re: [9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler

[Igor Veresov]

Perfect. :) Reviewed.

igor

> On Dec 7, 2016, at 2:10 PM, Vladimir Kozlov  
> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8166417
> 
> It is part of JEP 295: Ahead-of-Time Compilation
> https://bugs.openjdk.java.net/browse/JDK-8166089
> 
> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
> 
> This is formal review request for integration Graal-core sources into 
> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to 
> integrated Graal-core sources into JDK and add build changes to build Graal 
> module.
> 
> Note, changes are based on latest jdk9/hs sources which do not have latest 
> jigsaw update yet. With jigsaw update small changes will be done to 
> module-info.java.extra in java.base:
> 
>  exports jdk.internal.misc to jdk.vm.compiler;
> + opens jdk.internal.misc to jdk.vm.compiler;
> 
> - exports com.sun.crypto.provider to jdk.vm.compiler;
> + opens com.sun.crypto.provider to jdk.vm.compiler;
> 
> And changes in top make/GensrcModuleInfo.gmk will not be needed.
> 
> 
> 
> Graal is a dynamic compiler written in Java that integrates with the HotSpot 
> JVM. It has a focus on high performance and extensibility. In addition, it 
> provides optimized performance for Truffle based languages running on the JVM.
> 
> https://github.com/graalvm/graal-core
> 
> Oracle Labs is developing and maintaining it.
> 
> Here are people who contributed into Graal development (sorry if someone is 
> missing or misspelled, please speak):
> 
> ~70k LOC: Douglas Simon
> ~60k LOC: Lukas Stadler
> ~30k LOC: Thomas Wuerthinger
> ~30k LOC: Tom Rodriguez
> ~30k LOC: Roland Schatz
> ~30k LOC: Josef Eisl
> ~30k LOC: Christian Wimmer
> ~16k LOC: Chris Thalinger
> ~13k LOC: Gilles Duboscq
> ~11k LOC: David Leopoldseder
> ~ 8k LOC: Stefan Anzinger
> ~ 8k LOC: Christian Humer
> 
> Other contributors >100 LOC in approximate order of contribution size:
> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos Kotselidis, 
> Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, Christian Haeubl, 
> Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef Haider, Manuel Rigger, 
> Michael Haupt, Niclas Adlertz, Jaroslav Tulach, Chris Seaton, Peter B. 
> Kessler, Christian Wirth, Benoit Daloze.
> 
> 
> Thanks,
> Vladimir

[9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler

[Vladimir Kozlov]

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

It is part of JEP 295: Ahead-of-Time Compilation
https://bugs.openjdk.java.net/browse/JDK-8166089

http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/

This is formal review request for integration Graal-core sources into 
OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to 
integrated Graal-core sources into JDK and add build changes to build 
Graal module.


Note, changes are based on latest jdk9/hs sources which do not have 
latest jigsaw update yet. With jigsaw update small changes will be done 
to module-info.java.extra in java.base:


  exports jdk.internal.misc to jdk.vm.compiler;
+ opens jdk.internal.misc to jdk.vm.compiler;

- exports com.sun.crypto.provider to jdk.vm.compiler;
+ opens com.sun.crypto.provider to jdk.vm.compiler;

And changes in top make/GensrcModuleInfo.gmk will not be needed.



Graal is a dynamic compiler written in Java that integrates with the 
HotSpot JVM. It has a focus on high performance and extensibility. In 
addition, it provides optimized performance for Truffle based languages 
running on the JVM.


https://github.com/graalvm/graal-core

Oracle Labs is developing and maintaining it.

Here are people who contributed into Graal development (sorry if someone 
is missing or misspelled, please speak):


~70k LOC: Douglas Simon
~60k LOC: Lukas Stadler
~30k LOC: Thomas Wuerthinger
~30k LOC: Tom Rodriguez
~30k LOC: Roland Schatz
~30k LOC: Josef Eisl
~30k LOC: Christian Wimmer
~16k LOC: Chris Thalinger
~13k LOC: Gilles Duboscq
~11k LOC: David Leopoldseder
~ 8k LOC: Stefan Anzinger
~ 8k LOC: Christian Humer

Other contributors >100 LOC in approximate order of contribution size:
Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos 
Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec, 
Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef 
Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach, 
Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.



Thanks,
Vladimir

Review Request JDK-8169925: Organize licenses by module in source, JMOD file, and run-time image

[Mandy Chung]

This proposes to organize license files by module in source, JMOD, 
and run-time image.

A summary of the proposal:
1. Organize third party notices by module in the source as follows:
src/$MODULE/{share,$OS}/legal/*
 
The `legal` directory contains one file for each third party
library in the module, for example,
src/java.base/share/legal/asm.md
  unicode.md
  zlib.md

The proposed template for this file is described in [1] and JEP 201 
will be updated to reflect this proposed source layout.

2. Introduce a new LEGAL_NOTICES section in JMOD format. A new jmod
   option `—-legal-notices` is added to package legal notices in
   a JMOD file.

3. At jlink time, jlink will copy all legal notices from JMOD files
   to the `legal` directory in the run-time image.  A plugin is
   added to de-duplicate the legal notices if the filename and the
   content matches that may reduce the image footprint.

4. THIRD_PARTY_README in the top-level directory of each repo is removed.
   Manual edit to this file, multiple copies is no longer needed.

Webrev at:
   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169925/webrev.00/

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8169925

Re: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port

[Bob Vandette]

Thanks Magnus,  see comments below ..

> On Dec 7, 2016, at 3:44 AM, Magnus Ihse Bursie 
>  wrote:
> 
> On 2016-12-05 16:23, Bob Vandette wrote:
>>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov  
>>>  wrote:
>>> 
>>> hi Bob,
>>> 
>>> I would suggest to have separate webrevs for different repositories because 
>>> different groups should look on them.
>> There are only 3 non hotspot files and they are on top.  Forwarding to 
>> build-dev for their review.
> 
> Build changes mostly look good. A few comments:
> 
> * We try to use the autoconf defined "$with_opt" variables only when checking 
> and verifying arguments. In hotspot.m4, please let 
> SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. 
> OPENJDK_TARGET_CPU_PORT, and use that to do the check in 
> HOTSPOT_SETUP_JVM_FEATURES.

I think it should be called HOTSPOT_TARGET_CPU_PORT since this variable only 
impact which directory hotspot uses for it build.
I also removed a redundant if test "x$with_cpu_port" != x; in 
SETUP_HOTSPOT_TARGET_CPU_PORT.

+  # Override hotspot cpu definitions for ARM platforms
+  if test "x$OPENJDK_TARGET_CPU" = xarm; then
+HOTSPOT_TARGET_CPU=arm_32
+HOTSPOT_TARGET_CPU_DEFINE="ARM32"
+JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char"
+JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char"
+  elif test "x$OPENJDK_TARGET_CPU" = xaarch64 && test 
"x$HOTSPOT_TARGET_CPU_PORT" = xarm64; then
+HOTSPOT_TARGET_CPU=arm_64
+HOTSPOT_TARGET_CPU_ARCH=arm
+JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char"
+JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char"
+  fi
+

+AC_DEFUN([SETUP_HOTSPOT_TARGET_CPU_PORT],
+[
+  AC_ARG_WITH(cpu-port, [AS_HELP_STRING([--with-cpu-port],
+  [specify sources to use for Hotspot 64-bit ARM port (arm64,aarch64) 
@<:@aarch64@:>@ ])])
+
+  if test "x$with_cpu_port" != x; then
+if test "x$OPENJDK_TARGET_CPU" != xaarch64; then
+  AC_MSG_ERROR([--with-cpu-port only available on aarch64])
+fi
+if test "x$with_cpu_port" != xarm64 && \
+test "x$with_cpu_port" != xaarch64; then
+  AC_MSG_ERROR([--with-cpu-port must specify arm64 or aarch64])
+fi
+HOTSPOT_TARGET_CPU_PORT = $with_cpu_port
+  fi
+])
+
+

> 
> * In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks 
> OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU instead, 
> since explicitly checking the CPU_ARCH variable seems to indicate that we 
> want to test more than a single CPU, but for arm there is only one. (At 
> first, I thought this was a test for "arm64" as well. If this was the 
> intention, then the code is broken.)
> 
Ok.

> * In CompileJvm.gmk, you might want to rephrase the comment, since from now 
> on both the original aarch64 and the new arm64 port are "open". What the code 
> does is in fact to select between the two different aarch64 ports.

Done.  I also found another comment that needed to be updated.

diff --git a/make/lib/CompileJvm.gmk b/make/lib/CompileJvm.gmk
--- a/make/lib/CompileJvm.gmk
+++ b/make/lib/CompileJvm.gmk
@@ -63,8 +63,8 @@
 # INCLUDE_SUFFIX_* is only meant for including the proper
 # platform files. Don't use it to guard code. Use the value of
 # HOTSPOT_TARGET_CPU_DEFINE etc. instead.
-# Remaining TARGET_ARCH_* is needed to distinguish closed and open
-# 64-bit ARM ports (also called AARCH64).
+# Remaining TARGET_ARCH_* is needed to select the cpu specific 
+# sources for 64-bit ARM ports (arm versus aarch64).
 JVM_CFLAGS_TARGET_DEFINES += \
 -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) \
 -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \
@@ -139,6 +139,20 @@
 

 # Platform specific setup
 
+# ARM source selection
+
+ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-arm)
+  JVM_EXCLUDE_PATTERNS += arm_64
+
+else ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-aarch64)
+  # For 64-bit arm builds, we use the 64 bit hotspot/src/cpu/arm 
+  # hotspot sources if HOTSPOT_TARGET_CPU_ARCH is set to arm.
+  # Exclude the aarch64 and 32 bit arm files for this build.
+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), arm)
+JVM_EXCLUDE_PATTERNS += arm_32 aarch64
+  endif
+endif
+

Bob.


> 
> /Magnus
> 
> 
>> 
>>> For example, top repository and makefiles changes should be also reviewed 
>>> on build-dev@openjdk.java.net 
>>> 
>>> Why do you need cahnges in SA libproc.h?
>> The cross compilation toolchains we use do not define user_regs_struct or 
>> user_pt_regs.
>> 
>> I just looked again and there is a definition of struct user_regs in user.h. 
>>  I might be able to change the code to:
>> 
>> #if defined(arm) || defined(arm64)
>> #define user_regs_struct user_regs
>> #endif
>> 
>> This change would result  in the exact same declaration based on the number 
>> of registers
>> derived from the structure in user.h. 
>> 
>> Bob.
>> 
>> 
>>> I saw Hotspot 

RFR: JDK-8170863 Always pass MAKE_ARGS to MAKE in Main.gmk

[Magnus Ihse Bursie]

In JDK-8170284, the hotspot build logic was better integrated with the 
top make level. However, the calls to make there was not provided with 
MAKE_ARGS.


I will push this to jdk9-hs, since JDK-8170284 has still not reached 
jdk9/dev.


Bug: https://bugs.openjdk.java.net/browse/JDK-8170863
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8170863-pass-MAKE_ARGS/webrev.01


/Magnus

Re: RFR: JDK-8170863 Always pass MAKE_ARGS to MAKE in Main.gmk

[Erik Joelsson]

Looks good.

/Erik


On 2016-12-07 16:07, Magnus Ihse Bursie wrote:
In JDK-8170284, the hotspot build logic was better integrated with the 
top make level. However, the calls to make there was not provided with 
MAKE_ARGS.


I will push this to jdk9-hs, since JDK-8170284 has still not reached 
jdk9/dev.


Bug: https://bugs.openjdk.java.net/browse/JDK-8170863
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8170863-pass-MAKE_ARGS/webrev.01


/Magnus

Re: RFR: JDK-8170629 Remove code duplication in test makefiles

[Erik Joelsson]

Looks good to me.

/Erik


On 2016-12-06 11:15, Magnus Ihse Bursie wrote:

On 2016-12-05 05:34, David Holmes wrote:



Hi Magnus,

Some independent changes are going to collide here. :)

hotspot/make/test/JtregNative.gmk

This change has already happened in hs repo - JDK-8169261.

Ok, I removed that fix from my patch.


---

hotspot/test/Makefile

33 USE_JTREG_VERSION := 4.1

Aside: - Jigsaw bumped this to 4.2 (and I think that was a while 
ago). I don't think anything we do with jtreg relies on the JT_HOME 
setting currently set in hotspot/test/Makefile. So we should bump 
this after your refactor.


I think so too.



41 # hotspot currently do not use ProblemList.txt
42 NO_EXCLUDES := true

Igor is adding this right now:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025436.html 



I removed the NO_EXCLUDES statement from Hotspot. This does not have 
any effect as long as no ProblemList.txt is present (in fact, had I 
thought a bit more on this before, I would not even have needed to add 
that guard for hotspot), but will facilitate merging with Igor's patch.


Otherwise looks good.


I discovered a few other issues in the Hotspot file (it turned out I 
didn't run the hotspot tests before with my jprt command :() which I 
also have fixed.


New webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.02


/Magnus




Thanks,
David
-

On 2/12/2016 7:24 PM, Magnus Ihse Bursie wrote:

There is a lot of common code that has been duplicated in
*/test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the 
code in

the corresponding files are identical. (The odd-man-out is langtools
which is quite different.)

These files should be unified to share a single code base, to 
facilitate

further improvements to the test makefiles.

The intent of this bug is a pure refactoring. The duplication should 
go,

but all functionality should remain exactly the same. This will leave
room for some future improvements to the code, but sets a clear limit
for this first step. The consolidated code base thus contains a fair
amount of if-blocks, but I hope to be able to address most of these
later on, by adjusting the individual component to adhere more to the
standard behavior.

To minimize the amount of ifdefs in the shared code, I allowed for a 
few

changes in behavior. I do not believe these will cause any changes in
the real world, and to the extent that they do, they could be 
considered

bug fixes.

Behavior that have changed due to unification:
* jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk.
* jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists.
* jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA}
* hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it 
exists.

* hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists.

Bug: https://bugs.openjdk.java.net/browse/JDK-8170629
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01 




/Magnus

Re: RFR: JDK-8141590: Cannot build Zero with devkit

[Magnus Ihse Bursie]

On 2016-12-05 11:07, Erik Joelsson wrote:
This patch adds libffi to the linux devkit to enable building of zero. 
It also adds optional bundling of the libffi library with the JDK. The 
reason for this is that the devkit sysroot is based on a distro that 
uses libffi.so.5 while most distros we build or run tests on comes 
with libffi.so.6, and those are not compatible. Static linking was 
considered, but libffi.a doesn't seem commonly available where we 
would need it.


I'm also adding Jib profiles and a JPRT configuration which enables 
building of zero on Linux x86 and x64 for the "buildinfra" testset in 
JPRT. Note that these builds are currently not clean (for OracleJDK 
builds at least).


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

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


Looks good to me.

Thanks for fixing this!

/Magnus

Re: RFR(XXS): JDK-8170530: bash configure output contains a typo in a suggested library name

[Stas Smirnov]

Thank you Magnus

Best regards,
Stanislav Smirnov

> 7 дек. 2016 г., в 11:23, Magnus Ihse Bursie  
> написал(а):
> 
>> On 2016-11-30 12:09, Stanislav Smirnov wrote:
>> Hi,
>> 
>> please review this minor fix of a typo I have noticed in "bash configure” 
>> output when required X11 libraries are missing.
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8170530 
>> 
>> webrev: http://cr.openjdk.java.net/~stsmirno/8170530/webrev.00 
>> 
>> 
>> And I also need a sponsor for this change.
> 
> Looks good to me. I'll sponsor this change.
> 
> /Magnus

Re: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port

[Magnus Ihse Bursie]

On 2016-12-05 16:23, Bob Vandette wrote:

On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov  wrote:

hi Bob,

I would suggest to have separate webrevs for different repositories because 
different groups should look on them.

There are only 3 non hotspot files and they are on top.  Forwarding to 
build-dev for their review.


Build changes mostly look good. A few comments:

* We try to use the autoconf defined "$with_opt" variables only when 
checking and verifying arguments. In hotspot.m4, please let 
SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. 
OPENJDK_TARGET_CPU_PORT, and use that to do the check in 
HOTSPOT_SETUP_JVM_FEATURES.


* In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks 
OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU 
instead, since explicitly checking the CPU_ARCH variable seems to 
indicate that we want to test more than a single CPU, but for arm there 
is only one. (At first, I thought this was a test for "arm64" as well. 
If this was the intention, then the code is broken.)


* In CompileJvm.gmk, you might want to rephrase the comment, since from 
now on both the original aarch64 and the new arm64 port are "open". What 
the code does is in fact to select between the two different aarch64 ports.


/Magnus





For example, top repository and makefiles changes should be also reviewed on 
build-dev@openjdk.java.net

Why do you need cahnges in SA libproc.h?

The cross compilation toolchains we use do not define user_regs_struct or 
user_pt_regs.

I just looked again and there is a definition of struct user_regs in user.h.  I 
might be able to change the code to:

#if defined(arm) || defined(arm64)
#define user_regs_struct user_regs
#endif

This change would result  in the exact same declaration based on the number of 
registers
derived from the structure in user.h.

Bob.



I saw Hotspot changes before and I think they are fine (did not dive deep).

Thanks,
Vladimir

On 12/2/16 12:28 PM, Bob Vandette wrote:

Please review the proposed changes to be integrated under JEP 297.

Summary:

This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9.

This changeset also removes the support for the pregenerated interpreter since
this is no longer supported.

The addition of arm64 does not replace the existing aarch64 port.  A new 
configure
option (-with-cpu-port=) allows for the selection of the existing aarch64 
versus the
64-bit arm64 support being added via this JEP.  Please refer to the JEP for 
more details.

JEP 297:

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

Webrev:

http://cr.openjdk.java.net/~bobv/8168503


Note:

A complete build-able forest containing these changes is located here: 
http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264

Thanks,
Bob Vandette

Re: RFR(XXS): JDK-8170530: bash configure output contains a typo in a suggested library name

[Magnus Ihse Bursie]

On 2016-11-30 12:09, Stanislav Smirnov wrote:

Hi,

please review this minor fix of a typo I have noticed in "bash configure” 
output when required X11 libraries are missing.
JBS: https://bugs.openjdk.java.net/browse/JDK-8170530 

webrev: http://cr.openjdk.java.net/~stsmirno/8170530/webrev.00 


And I also need a sponsor for this change.


Looks good to me. I'll sponsor this change.

/Magnus