RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image

Hello , could you please review and push this small change fixing the aix jre generation in jdk10 : http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ (and later on it would be good to get it into jdk9 as well because the same issue exists there too) Thanks and best regards, Matthias >

Re: Building OpenJDK9 on MSYS2

And this is accomplished by running "make bootcycle-images", though if you were able to pass the images target, you have already used the newly built JDK to both create jmods and jlink the images. There are also many jtreg tests you can run, but to for that you need a jtreg binary. /Erik O

Re: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image

Looks good. /Erik On 2017-10-26 09:05, Baesken, Matthias wrote: Hello , could you please review and push this small change fixing the aix jre generation in jdk10 : http://cr.openjdk.java.net/~mbaesken/webrevs/8189618/ (and later on it would be good to get it into jdk9 as well because the

Re: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image

Hi Matthias, good job, thanks (and thanks to Magnus)! Just tried it, works. Change looks good. ..Thomas On Thu, Oct 26, 2017 at 9:05 AM, Baesken, Matthias wrote: > Hello , could you please review and push this small change fixing the > aix jre generation in jdk10 : > > http://cr.openjdk.ja

Re: RFR: 8189618: [aix] No jre image is created during images step - was : RE: AIX build not generating a jre image

(I'll push it) On Thu, Oct 26, 2017 at 9:39 AM, Thomas Stüfe wrote: > Hi Matthias, > > good job, thanks (and thanks to Magnus)! > > Just tried it, works. > > Change looks good. > > ..Thomas > > > On Thu, Oct 26, 2017 at 9:05 AM, Baesken, Matthias < > matthias.baes...@sap.com> wrote: > >> Hello ,

Re: RFR: JDK-8189955 Configuration validation is broken for some types of paths

I see why this huge check becomes necessary for a valid comparison, but it's quite a bit of extra complexity added as well. I was worried about the extra overhead on an already slow platform so I took the time to measure. While it's certainly measurable it's hardly noticeable. On a fast machine

Re: RFR: JDK-8189955 Configuration validation is broken for some types of paths

On 2017-10-26 10:09, Erik Joelsson wrote: I see why this huge check becomes necessary for a valid comparison, but it's quite a bit of extra complexity added as well. I was worried about the extra overhead on an already slow platform so I took the time to measure. While it's certainly measurabl

Re: Building OpenJDK9 on MSYS2

On 2017-10-26 00:01, Peter Budai wrote: OK, I have found what was missing, it was actually my fault with a missing exception handler. So finally OpenJDK build has finished on Windows using gcc toolchain running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks promising: ./b

Re: RFR: JDK-8189955 Configuration validation is broken for some types of paths

Hello, On 2017-10-26 10:56, Magnus Ihse Bursie wrote: On 2017-10-26 10:09, Erik Joelsson wrote: I see why this huge check becomes necessary for a valid comparison, but it's quite a bit of extra complexity added as well. I was worried about the extra overhead on an already slow platform so I t

Re: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

Coleen, Thank you for addressing this! On 2017-10-25 18:49, coleen.phillim...@oracle.com wrote: Summary: removed hotspot version of jvm*h and jni*h files Mostly used sed to remove prims/jvm.h and move #include "jvm.h" after precompiled.h, so if you have repetitive stress wrist issues don't c

Re: RFR: JDK-8189955 Configuration validation is broken for some types of paths

On 2017-10-26 11:09, Erik Joelsson wrote: This check has on the other hand caused quite a bit of problems for us and given the increased complexity necessary for keeping it in there, I would agree with your conclusion. It's better to just drop it. Updated webrev, which removes the check: WebR

Re: RFR: JDK-8189955 Configuration validation is broken for some types of paths

Looks good. /Erik On 2017-10-26 12:03, Magnus Ihse Bursie wrote: On 2017-10-26 11:09, Erik Joelsson wrote: This check has on the other hand caused quite a bit of problems for us and given the increased complexity necessary for keeping it in there, I would agree with your conclusion. It's bet

Re: Building OpenJDK9 on MSYS2

You can try to run the jtreg tests. There are instructions on running the tests in {top}/common/doc/testing.* and {top}/common/doc/building.* You’ll have to download http://openjdk.java.net/jtreg in order to run these tests. Bob. > On Oct 25, 2017, at 6:01 PM,

RFR(XXS): 8189919: Update link to license in Docs.gmk

Please review this small change to update the link to the Specification license referenced by the JavaDoc API. For JDK 10, we should reference the 10 redirect. Bug: 8189919: Update link to license in Docs.gmk https://bugs.openjdk.java.net/browse/JDK-8189919 webrev: h

Re: RFR(XXS): 8189919: Update link to license in Docs.gmk

2017/10/26 9:11:08 -0700, iris.cl...@oracle.com: > Please review this small change to update the link to the > > Specification license referenced by the JavaDoc API. For > > JDK 10, we should reference the 10 redirect. > > Bug: > > > > 8189919: Update link to license in Docs.gmk > >

RE: RFR(XXS): 8189919: Update link to license in Docs.gmk

Thanks for the review, Mark. >> http://cr.openjdk.java.net/~iris/8189919/webrev/ Pushed. iris

Re: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

On 10/26/17 2:57 AM, Magnus Ihse Bursie wrote: A third option is to remove the support for link-time-opt entirely, if it's not really used. * src/java.base/unix/native/include/jvm_md.h and src/java.base/windows/native/include/jvm_md.h: These files define a public API, and contain non-trivi

Re: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

On 10/26/17 2:47 PM, mandy chung wrote: On 10/26/17 2:57 AM, Magnus Ihse Bursie wrote: A third option is to remove the support for link-time-opt entirely, if it's not really used. * src/java.base/unix/native/include/jvm_md.h and src/java.base/windows/native/include/jvm_md.h: These files

Re: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

 Hi Magnus, Thank you for reviewing this.   I have a new version that takes out the hack in globalDefinitions.hpp and adds casts to src/hotspot/share/opto/type.cpp instead. Also some fixes from Martin at SAP. open webrev at http://cr.openjdk.java.net/~coleenp/8189610.02/webrev see below. O

Re: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot

On 10/26/17 1:34 PM, coleen.phillim...@oracle.com wrote: On 10/26/17 2:47 PM, mandy chung wrote: On 10/26/17 2:57 AM, Magnus Ihse Bursie wrote: A third option is to remove the support for link-time-opt entirely, if it's not really used. * src/java.base/unix/native/include/jvm_md.h and