Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

2018-03-22 6:41 GMT+08:00 John Paul Adrian Glaubitz : > On 03/22/2018 07:07 AM, Martin Buchholz wrote: >> But for users, being able to bootstrap with an ancient jdk is definitely >> convenient. > > Convenient is an understatement. Always enforcing the N-1 version to be > used can be quite painful f

[NEW BUG]: Configure broken on MIPS

Hi, I found configure of http://hg.openjdk.java.net/jdk/jdk was broken on MIPS. the output of configure: ... configure: Using default toolchain gcc (GNU Compiler Collection) checking for gcc... /usr/bin/gcc checking resolved symbolic links for CC... /usr/bin/mips64el-linux-gnuabi64-gcc-6 configur

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

Jon, > 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons : > > Holding javac and related tools back to the latest LTS would indeed be > somewhat onerous. Can we use the interim JDK build to get around this? Something like, if we can build a interim JDK with somewhat older tools, it can then be use

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

For what it is worth, I very much agree with Marting and Adrian. It would make matters easier for downstream consumers if we could at least retain N-2 compatibility, if compatibility to LTS is too much of a hassle for Oracle. Best Regards, Thomas On Wed, Mar 21, 2018 at 11:41 PM, John Paul Adria

RFR: 8199705: Docs.gmk needs to be updated to remove the -html5 option

Hi,     This is a simple fix to Docs.gmk. A fix for JDK-8182765 was pushed recently to javadoc enabling it to generate HTML 5 output by default. This makes the "-html5" option, defined in the initial set of javadoc options in Docs.gmk, redund

Re: [11] RFR(XS) 8199896: [Graal] build Graal on all x86 platforms

Forgot to CC to build-dev. Note, this change does not have effect unless you disable AOT build. We are already building Graal on all x64 platforms as part of AOT build currently. Vladimir On 3/20/18 6:15 PM, Vladimir Kozlov wrote: https://bugs.openjdk.java.net/browse/JDK-8199896 Extend Graa

Re: RFR: JDK-8198652: Stop linking with -base:0x8000000 on Windows

Erik: On Windows, we have been linking libjvm.so with -base:0x800 since forever. This may have been a good idea on earlier versions of windows, but with VS2017 it generates a warning and with ASLR, the address a given binary is loaded at will vary between runs anyway, so there is little poin

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

On 03/22/2018 07:07 AM, Martin Buchholz wrote: > But for users, being able to bootstrap with an ancient jdk is definitely > convenient. Convenient is an understatement. Always enforcing the N-1 version to be used can be quite painful for downstream distributions. Rust upstream does the same thing

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

Holding javac and related tools back to the latest LTS would indeed be somewhat onerous. -- Jon On 03/21/2018 03:07 PM, Martin Buchholz wrote: Now that we are releasing jdks an order of magnitude faster than before, we should reconsider the N-1 boot jdk policy. The primary beneficiaries of th

Re: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

Now that we are releasing jdks an order of magnitude faster than before, we should reconsider the N-1 boot jdk policy. The primary beneficiaries of this are compiler-dev, who might like to code using the very features they are implementing. But for users, being able to bootstrap with an ancient j

RFR: JDK-8198652: Stop linking with -base:0x8000000 on Windows

On Windows, we have been linking libjvm.so with -base:0x800 since forever. This may have been a good idea on earlier versions of windows, but with VS2017 it generates a warning and with ASLR, the address a given binary is loaded at will vary between runs anyway, so there is little point set

RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

Now that JDK 10 has been officially released we can update the boot jdk requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of this rather disruptive change. This patch changes the requirement on boot jdk version in configure (and updates the configuration that controls wh

Re: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure

Hi Magnus, > I have tested the following: > * On my linux machine, failure to load libjsound.so was not fatal. In Platform.java: 54 loadLibraries(); 55 readProperties(); and readProperties calls native nIsBigEndian if libjsound loading fails I'd expect nIsBigEndian fails

Re: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure

Build changes look good. /Erik On 2018-03-21 07:09, Magnus Ihse Bursie wrote: On 2018-03-16 17:49, Alex Menkov wrote: On 03/15/2018 13:09, Magnus Ihse Bursie wrote: 15 mars 2018 kl. 20:13 skrev Phil Race : As far as I know the split was made to dynamically load ALSA/DirectSound stuff

Re: [OpenJDK 2D-Dev] RFR: JDK-8071469 Cleanup include and exclude of sound native libraries after source code restructure

On 2018-03-16 17:49, Alex Menkov wrote: On 03/15/2018 13:09, Magnus Ihse Bursie wrote: 15 mars 2018 kl. 20:13 skrev Phil Race : As far as I know the split was made to dynamically load ALSA/DirectSound stuff Yes, I think it is something like that for Linux ie if at runtime a dependent-bu

Re: RFR: 8199138: Add RISC-V support to Zero

On 03/20/2018 02:54 PM, Edward Nevill wrote: On Tue, 2018-03-20 at 08:39 +0100, Erik Helin wrote: Please review the following webrev Bugid: https://bugs.openjdk.java.net/browse/JDK-8199138 Webrev: http://cr.openjdk.java.net/~enevill/8199138/webrev.00 32 # First, filter out everything tha

Re: RFR: 8199138: Add RISC-V support to Zero

On 03/19/2018 05:19 AM, Edward Nevill wrote: > Interestingly, there is no implementation of atomic_copy64 for ARM32. I guess > it just relies on the compiler generating LDRD/STRD correctly and doesn't > support earlier ARM32 archs. I'll do a bit of investigation. I am planning to add arch-speci