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

[Ao Qi]

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 for downstream distributions. Rust upstream
> does the same thing and it becomes very frustrating when bootstrapping
> the compiler.
>
> When, for example, an architecture has fallen back a couple of releases
> of OpenJDK, I would have to go through the whole chain of 8->9->10->11
> to get the latest OpenJDK. I know that cross-compiling is possible, but
> it's not always the easiest option.
>

Indeed. I was trying to build OpenJDK 11 zero on MIPS. Because I only had
OpenJDK 8 binary as boot JDK, I have to build OpenJDK 9 first.
It is even more painful when I build OpenJDK 11 32 bits zero. Because I only
have 32-bit OpenJDK 6 as boot JDK, I have to build 7, 8, 9 and then 11.

> So, from a downstream perspective, allowing the oldest possible version
> is always a desirable feature to have. I do understand it though when
> OpenJDK 11 requires features from OpenJDK 10 which would rule out older
> versions completely.
>
> 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

[NEW BUG]: Configure broken on MIPS

[Ao Qi]

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
configure: Using gcc C compiler version 6.3.0 [gcc (Debian 6.3.0-18)
6.3.0 20170516]
checking whether the C compiler works... no
configure: error: in `/home/loongson/aoqi/jdk':
configure: error: C compiler cannot create executables
See `config.log' for more details
configure exiting with result code 77
...

the related content of config.log:
...
configure:35256: checking whether the C compiler works
configure:35278: /usr/bin/gcc -m64-m64   conftest.c  >&5
gcc: error: unrecognized command line option '-m64'
gcc: error: unrecognized command line option '-m64'
configure:35282: $? = 1
configure:35320: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "OpenJDK"
| #define PACKAGE_TARNAME "openjdk"
| #define PACKAGE_VERSION "jdk9"
| #define PACKAGE_STRING "OpenJDK jdk9"
| #define PACKAGE_BUGREPORT "build-dev@openjdk.java.net"
| #define PACKAGE_URL "http://openjdk.java.net";
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:35325: error: in `/home/loongson/aoqi/jdk':
configure:35327: error: C compiler cannot create executables
See `config.log' for more details
...


I made a small patch to pass the configure:

$ hg diff make/autoconf/flags.m4
diff -r 3acb379b8672 make/autoconf/flags.m4
--- a/make/autoconf/flags.m4 Thu Mar 22 08:09:51 2018 +0800
+++ b/make/autoconf/flags.m4 Thu Mar 22 12:55:00 2018 +0800
@@ -237,7 +237,11 @@
 MACHINE_FLAG="-q${OPENJDK_TARGET_CPU_BITS}"
   elif test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
 if test "x$OPENJDK_TARGET_CPU" != xaarch64 &&
-test "x$OPENJDK_TARGET_CPU" != xarm; then
+test "x$OPENJDK_TARGET_CPU" != xarm &&
+test "x$OPENJDK_TARGET_CPU" != xmips &&
+test "x$OPENJDK_TARGET_CPU" != xmipsel &&
+test "x$OPENJDK_TARGET_CPU" != xmips64 &&
+test "x$OPENJDK_TARGET_CPU" != xmips64el; then
   MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
 fi
   fi


I think this is the same problem with bug 8199052 and 8199152. Could
someone help to review the change?

Thanks,
Ao Qi

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

[Magnus Ihse Bursie]

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 used to compile 
the javac proper?

I can see that how with the increased release cadence, the assumptions behind 
the old N-1 scheme might not be valid anymore. 

/Magnus

> 
> -- 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 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 jdk is definitely
>> convenient.
>> 
>> A good compromise might be to be able to bootstrap with the most recent LTS
>> release (jdk 8) but it might already be too late for that.
>> 
>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson 
>> wrote:
>> 
>>> 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 what JDK to use as boot in Oracle's
>>> internal build system).
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>>> 
>>> /Erik
>>> 
>>> 
> 

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

[Thomas Stüfe]

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 Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> 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 and it becomes very frustrating when bootstrapping
> the compiler.
>
> When, for example, an architecture has fallen back a couple of releases
> of OpenJDK, I would have to go through the whole chain of 8->9->10->11
> to get the latest OpenJDK. I know that cross-compiling is possible, but
> it's not always the easiest option.
>
> So, from a downstream perspective, allowing the oldest possible version
> is always a desirable feature to have. I do understand it though when
> OpenJDK 11 requires features from OpenJDK 10 which would rule out older
> versions completely.
>
> 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
>

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

[Bhavesh Patel]

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, redundant. I have removed the -html5  option. Please review 
this fix.



JBS: https://bugs.openjdk.java.net/browse/JDK-8199705

Webrev: http://cr.openjdk.java.net/~bpatel/8199705/webrev.00/ 

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

[Vladimir Kozlov]

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 Graal build to all x64 platforms.

diff -r 7fa5375fa6fd make/autoconf/hotspot.m4
--- a/make/autoconf/hotspot.m4
+++ b/make/autoconf/hotspot.m4
@@ -347,11 +347,10 @@
  fi
  INCLUDE_GRAAL="true"
    else
-    # By default enable graal build on linux-x64 or where AOT is available.
+    # By default enable graal build on x64 or where AOT is available.
  # graal build requires jvmci.
  if test "x$JVM_FEATURES_jvmci" = "xjvmci" && \
-    (test "x$OPENJDK_TARGET_CPU" = "xx86_64" && \
- test "x$OPENJDK_TARGET_OS" = "xlinux" || \
+    (test "x$OPENJDK_TARGET_CPU" = "xx86_64" || \
  test "x$ENABLE_AOT" = "xtrue") ; then
    AC_MSG_RESULT([yes])
    JVM_FEATURES_graal="graal"

Thanks,
Vladimir

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

[Tim Bell]

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 point setting this linker option anymore (since Windows Vista).
So I propose we just remove it.

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

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


Looks good.

/Tim

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

[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 for downstream distributions. Rust upstream
does the same thing and it becomes very frustrating when bootstrapping
the compiler.

When, for example, an architecture has fallen back a couple of releases
of OpenJDK, I would have to go through the whole chain of 8->9->10->11
to get the latest OpenJDK. I know that cross-compiling is possible, but
it's not always the easiest option.

So, from a downstream perspective, allowing the oldest possible version
is always a desirable feature to have. I do understand it though when
OpenJDK 11 requires features from OpenJDK 10 which would rule out older
versions completely.

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: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Jonathan Gibbons]

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 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 jdk is definitely
convenient.

A good compromise might be to be able to bootstrap with the most recent LTS
release (jdk 8) but it might already be too late for that.

On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson 
wrote:


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 what JDK to use as boot in Oracle's
internal build system).

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

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

/Erik

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

[Martin Buchholz]

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 jdk is definitely
convenient.

A good compromise might be to be able to bootstrap with the most recent LTS
release (jdk 8) but it might already be too late for that.

On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson 
wrote:

> 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 what JDK to use as boot in Oracle's
> internal build system).
>
> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>
> /Erik
>
>

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

[Erik Joelsson]

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 setting this linker option anymore (since Windows Vista). 
So I propose we just remove it.


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

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

/Erik

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

[Erik Joelsson]

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 what JDK to use as boot in 
Oracle's internal build system).


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

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

/Erik

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

[Alex Menkov]

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 too.

--alex

On 03/21/2018 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


Yes, I think it is something like that for Linux
ie if at runtime a dependent-but-not-essential .so was not
installed it was not fatal. I don't know to what extent this is no 
longer a

possible issue, or one that matters.


I have not heard of any mainstream Linux distro in years that was 
lacking ALSA.


If ALSA was not present, will the libraries fall back to OSS, or will 
there be just no sound available?


No sound.
OSS support was dropped many years ago (IIRC in jdk7)

In any case, I think that whatever Linux distros we're targeting as 
supported, ALSA will be present.


Alex, did I understand you correctly that in any case, a separate 
Windows library is always unnecessary, since we can rely on 
DirectAudio always being present in our supported versions of Windows?


Yes, that's right.
Windows always has DirectSound pre-installed and its version is 
greater than required (IIRC javasoundds requires DirectX 5).


For now failure of libjsound loading is fatal (see 
com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
is non-fatal.
I believe libjsound loading failure should be made non-fatal, then all 
the functionality will remain the same as we have now.


Ok.

Here is an updated webrev. I have made the following changes:
* libjavasoundalsa and libjavasoundds is now folded into the main 
libjavasound native library, so there's exactly one library built on all 
platforms.

* Loading of libjsound is made non-fatal.
* I have cleaned out all obvious parts of the code that handle multiple 
libraries. Since loading the native library is now a all-or-nothing 
situation, the checks for various subsystems have been turned into a 
generic check if the native library is loaded.


There is a lot of defines like USE_DSOUND which are always true. This 
could probably be cleaned up further, but it is not a build issue so I'm 
leaving that to the client team to handle.


I have tested the following:
  * COMPARE_BUILD shows me just the expected changes in the build.
  * On my linux machine, failure to load libjsound.so was not fatal.
  * I have looked for sound tests. I found the test/jdk/javax/sound 
suite, which was included in tier3. So I've run tier3 testing on all 
platforms using our internal test system, and all tests pass.


I don't know if there is any other tests I should run. If so, let me know.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03


/Magnus



--alex



/Magnus



-phil.


On 03/15/2018 12:06 PM, Alex Menkov wrote:



On 03/15/2018 11:44, Magnus Ihse Bursie wrote:

On 2018-03-15 18:23, Phil Race wrote:
I wondered if that might be the case since it was a "BSD" port .. 
using X11 ..


Maybe we should be getting rid of them ?
I agree, we should delete them. I just shuffled them around in the 
hope that they would be useful for a potential future bsd port, 
but if/when that happens, we can dig them out from mercurial.


A short explanation of how the files moved. The sound library is 
apparently composed of either a single library (solaris and 
macosx) or two libraries (linux and windows). Two building blocks, 
MIDI + ports and DirectAudio is used for all platforms, but they 
go into either the main library (libjsound) or the helper library.


For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
go into the main libjsound.


I have no idea why this split is necessary, but this is how the 
libraries de facto is compiled, and the code needs to match that. 
If it would be possible to move libjsoundds and libjsoundalsa into 
libjsound directly, things would be greatly simplified.


As far as I know the split was made to dynamically load 
ALSA/DirectSound stuff. If it's not available (or old unsupported 
version is installed), libjsound stuff continues to work (in 
pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
on Linux).
For now Windows (DirectSound) libjsoundds stuff can be merged into 
libjsound, but I'm not sure we can rely on ALSA is always available 
on Linux (but most likely if ALSA is not available, libjsound does 
not provide any functionality, so I suppose libjsoundalsa stuff can 
be moved to libjsound as well)


--alex



/Magnus



-phil.


On 03/15/2018 10:21 AM, Erik Joelsson wrote:
Digging a bit, those fi

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

[Erik Joelsson]

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


Yes, I think it is something like that for Linux
ie if at runtime a dependent-but-not-essential .so was not
installed it was not fatal. I don't know to what extent this is no 
longer a

possible issue, or one that matters.


I have not heard of any mainstream Linux distro in years that was 
lacking ALSA.


If ALSA was not present, will the libraries fall back to OSS, or 
will there be just no sound available?


No sound.
OSS support was dropped many years ago (IIRC in jdk7)

In any case, I think that whatever Linux distros we're targeting as 
supported, ALSA will be present.


Alex, did I understand you correctly that in any case, a separate 
Windows library is always unnecessary, since we can rely on 
DirectAudio always being present in our supported versions of Windows?


Yes, that's right.
Windows always has DirectSound pre-installed and its version is 
greater than required (IIRC javasoundds requires DirectX 5).


For now failure of libjsound loading is fatal (see 
com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
is non-fatal.
I believe libjsound loading failure should be made non-fatal, then 
all the functionality will remain the same as we have now.


Ok.

Here is an updated webrev. I have made the following changes:
* libjavasoundalsa and libjavasoundds is now folded into the main 
libjavasound native library, so there's exactly one library built on 
all platforms.

* Loading of libjsound is made non-fatal.
* I have cleaned out all obvious parts of the code that handle 
multiple libraries. Since loading the native library is now a 
all-or-nothing situation, the checks for various subsystems have been 
turned into a generic check if the native library is loaded.


There is a lot of defines like USE_DSOUND which are always true. This 
could probably be cleaned up further, but it is not a build issue so 
I'm leaving that to the client team to handle.


I have tested the following:
 * COMPARE_BUILD shows me just the expected changes in the build.
 * On my linux machine, failure to load libjsound.so was not fatal.
 * I have looked for sound tests. I found the test/jdk/javax/sound 
suite, which was included in tier3. So I've run tier3 testing on all 
platforms using our internal test system, and all tests pass.


I don't know if there is any other tests I should run. If so, let me 
know.


Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03


/Magnus



--alex



/Magnus



-phil.


On 03/15/2018 12:06 PM, Alex Menkov wrote:



On 03/15/2018 11:44, Magnus Ihse Bursie wrote:

On 2018-03-15 18:23, Phil Race wrote:
I wondered if that might be the case since it was a "BSD" port 
.. using X11 ..


Maybe we should be getting rid of them ?
I agree, we should delete them. I just shuffled them around in 
the hope that they would be useful for a potential future bsd 
port, but if/when that happens, we can dig them out from mercurial.


A short explanation of how the files moved. The sound library is 
apparently composed of either a single library (solaris and 
macosx) or two libraries (linux and windows). Two building 
blocks, MIDI + ports and DirectAudio is used for all platforms, 
but they go into either the main library (libjsound) or the 
helper library.


For Windows, MIDI+Ports go into libjsound, and DirectAudio go 
into libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
go into the main libjsound.


I have no idea why this split is necessary, but this is how the 
libraries de facto is compiled, and the code needs to match that. 
If it would be possible to move libjsoundds and libjsoundalsa 
into libjsound directly, things would be greatly simplified.


As far as I know the split was made to dynamically load 
ALSA/DirectSound stuff. If it's not available (or old unsupported 
version is installed), libjsound stuff continues to work (in 
pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
on Linux).
For now Windows (DirectSound) libjsoundds stuff can be merged into 
libjsound, but I'm not sure we can rely on ALSA is always 
available on Linux (but most likely if ALSA is not available, 
libjsound does not provide any functionality, so I suppose 
libjsoundalsa stuff can be moved to libjsound as well)


--alex



/Magnus



-phil.


On 03/15/2018 10:21 AM, Erik Joelsson wrote:
Digging a bit, those files came with the initial Macosx 
support. It doesn't look like they were ever used.


/Erik



On 2018-03-15 09:53, Phil Race wrote:
It is very hard to follow all the moved around files, but one 
thing

that sticks out is there is a "bsd" directory created and I can't
work out

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

[Magnus Ihse Bursie]

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-but-not-essential .so was not
installed it was not fatal. I don't know to what extent this is no 
longer a

possible issue, or one that matters.


I have not heard of any mainstream Linux distro in years that was 
lacking ALSA.


If ALSA was not present, will the libraries fall back to OSS, or will 
there be just no sound available?


No sound.
OSS support was dropped many years ago (IIRC in jdk7)

In any case, I think that whatever Linux distros we're targeting as 
supported, ALSA will be present.


Alex, did I understand you correctly that in any case, a separate 
Windows library is always unnecessary, since we can rely on 
DirectAudio always being present in our supported versions of Windows?


Yes, that's right.
Windows always has DirectSound pre-installed and its version is 
greater than required (IIRC javasoundds requires DirectX 5).


For now failure of libjsound loading is fatal (see 
com.sun.media.sound.Platform.loadLibraries()), loading of extra libs 
is non-fatal.
I believe libjsound loading failure should be made non-fatal, then all 
the functionality will remain the same as we have now.


Ok.

Here is an updated webrev. I have made the following changes:
* libjavasoundalsa and libjavasoundds is now folded into the main 
libjavasound native library, so there's exactly one library built on all 
platforms.

* Loading of libjsound is made non-fatal.
* I have cleaned out all obvious parts of the code that handle multiple 
libraries. Since loading the native library is now a all-or-nothing 
situation, the checks for various subsystems have been turned into a 
generic check if the native library is loaded.


There is a lot of defines like USE_DSOUND which are always true. This 
could probably be cleaned up further, but it is not a build issue so I'm 
leaving that to the client team to handle.


I have tested the following:
 * COMPARE_BUILD shows me just the expected changes in the build.
 * On my linux machine, failure to load libjsound.so was not fatal.
 * I have looked for sound tests. I found the test/jdk/javax/sound 
suite, which was included in tier3. So I've run tier3 testing on all 
platforms using our internal test system, and all tests pass.


I don't know if there is any other tests I should run. If so, let me know.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.03


/Magnus



--alex



/Magnus



-phil.


On 03/15/2018 12:06 PM, Alex Menkov wrote:



On 03/15/2018 11:44, Magnus Ihse Bursie wrote:

On 2018-03-15 18:23, Phil Race wrote:
I wondered if that might be the case since it was a "BSD" port .. 
using X11 ..


Maybe we should be getting rid of them ?
I agree, we should delete them. I just shuffled them around in the 
hope that they would be useful for a potential future bsd port, 
but if/when that happens, we can dig them out from mercurial.


A short explanation of how the files moved. The sound library is 
apparently composed of either a single library (solaris and 
macosx) or two libraries (linux and windows). Two building blocks, 
MIDI + ports and DirectAudio is used for all platforms, but they 
go into either the main library (libjsound) or the helper library.


For Windows, MIDI+Ports go into libjsound, and DirectAudio go into 
libjsoundds. On Linux, MIDI+Ports and DirectAudio go into 
libjsoundalsa. On Macosx and Solaris, MIDI+Ports and DirectAudio 
go into the main libjsound.


I have no idea why this split is necessary, but this is how the 
libraries de facto is compiled, and the code needs to match that. 
If it would be possible to move libjsoundds and libjsoundalsa into 
libjsound directly, things would be greatly simplified.


As far as I know the split was made to dynamically load 
ALSA/DirectSound stuff. If it's not available (or old unsupported 
version is installed), libjsound stuff continues to work (in 
pre-OpenJDK libjsound supported WaveIn/WaveOut on Windows and OSS 
on Linux).
For now Windows (DirectSound) libjsoundds stuff can be merged into 
libjsound, but I'm not sure we can rely on ALSA is always available 
on Linux (but most likely if ALSA is not available, libjsound does 
not provide any functionality, so I suppose libjsoundalsa stuff can 
be moved to libjsound as well)


--alex



/Magnus



-phil.


On 03/15/2018 10:21 AM, Erik Joelsson wrote:
Digging a bit, those files came with the initial Macosx support. 
It doesn't look like they were ever used.


/Erik



On 2018-03-15 09:53, Phil Race wrote:
It is very hard to follow all the moved around files, but one 
thing

that sticks out is there is a "bsd" directory created and I can't
work out how the files in there are used.
If they are for a BSD port of OpenJDK where is rest

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

[Erik Helin]

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 that doesn't begin with "aarch64-"
33 if ! echo $* | grep '^aarch64-\|^riscv64-' >/dev/null ; then

Could you please update the comment on line 32 to say the same thing as
the code?



Hi Eirk,

Thanks for this. I have updated the webrev with the above comment.

http://cr.openjdk.java.net/~enevill/8199138/webrev.01


Please also update the error message at line 1802 - 1804:

1802 #error Method os::dll_load requires that one of following is 
defined:\
1803 AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, 
PARISC, __powerpc__, __powerpc64__, S390, SH, __sparc

1804 #endif


I have also fixed a problem encountered with the submit-hs repo where the build 
machine had older headers which did not define EM_RISCV.

The solution is to define EM_RISCV if not already defined as is done for 
aarch64.

IE.

  #ifndef EM_AARCH64
#define EM_AARCH64183   /* ARM AARCH64 */
  #endif
+#ifndef EM_RISCV
+  #define EM_RISCV  243
+#endif


Maybe add a corresponding /* RISC-V */ comment to use the same style as 
the other defines?



This now passes the submit-hs tests.


Ok, good.


Does this look OK to push now?


Please send out a final webrev first.

Thanks,
Erik


Thanks,
Ed.

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

[John Paul Adrian Glaubitz]

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-specific implementations for m68k and sh in the near
future. From the current build logs in Debian, it seems that the JVM is actually
hanging on these architectures from time to time and I think this could probably
be related to atomic_copy64 actually not being 100% atomic. I already added the
one for PowerPCSPE.

It's also interesting that there is no implementation for 32-Bit MIPS either.

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