Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

[Weijun Wang]

> On Mar 24, 2018, at 6:03 AM, Magnus Ihse Bursie 
>  wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8200193 -- for jdk.security.auth

There is only one function to export and it already has JNIEXPORT, so you can 
just remove the new $(LIBJAAS_CFLAGS) [1].

Are you going to update your webrev?

Thanks
Max

[1] 
http://cr.openjdk.java.net/~ihse/JDK-8200178-remove-mapfiles/webrev.01/make/lib/Lib-jdk.security.auth.gmk.sdiff.html

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[David Holmes]

Hi Magnus,

I appreciate what you are trying to do here but there are reasons this 
kind of cleanup keeps getting deferred :) - it's not trivial and deals 
with really old code that isn't always clear. You may have bitten off 
more than you want to chew here. (And I'm strapped for time to work 
through this with you - sorry.)


On the positive side you can use the pthread functions on Solaris so no 
need to special case for that.


However there are still a number of issues:

  52 #ifndef NSIG
  53   #define NSIG SIGRTMAX
  54 #endif

SIGRTMAX is Solaris only, but even on Solaris NSIG might be defined 
(it's conditional in sys/signal.h but I don't know when the conditions 
are enabled).


 56 static struct sigaction sact[NSIG];

SIGRTMAX is a macro not a constant so you can't declare a static array 
using it. You would need to malloc the array as done on Solaris.


 58 static __thread bool reentry = false; /* prevent reentry deadlock 
(per-thread) */


I didn't realize this was in the OSX version as we don't unconditionally 
use compiler-based thread locals. I would make this field and its use 
OSX specific


148 #ifdef SOLARIS
 149 sact[sig].sa_flags = SA_NODEFER;
 150 if (sig != SIGILL && sig != SIGTRAP && sig != SIGPWR) {
 151   sact[sig].sa_flags |= SA_RESETHAND;
 152 }
 153 #else

I'd have to do some research to see why this is needed so best to keep it.

178 #ifdef SOLARIS
 179 if (is_sigset && sigblocked) {
 180   /* We won't honor the SIG_HOLD request to change the signal 
mask */

 181   oldhandler = SIG_HOLD;
 182 }
 183 #endif

Ditto.

More below ...

On 27/03/2018 7:42 PM, Magnus Ihse Bursie wrote:
When I was about to update jsig.c, I noticed that the four copies for 
aix, linux, macosx and solaris were basically the same, with only small 
differences. Some of the differences were not even well motivated, but 
were likely the result of this code duplication causing the code to 
diverge.


A better solution is to unify them all into a single unix version, with 
the few platform-specific changes handled on a per-platform basis.


I've made the following notable changes:

* I have removed the version check for Solaris. All other platforms seem 
to do fine without it, and in general, we don't mistrust other JDK 
libraries. An alternative is to add this version check to all other 
platforms instead. If you think this is the correct course of action, 
let me know and I'll fix it.


That's fine. I actually thought this had gone. Or it may be we have a 
bug to clean this up. Which reminds me - there may be a number of 
existing bugs that get handled by the changes you're making. But there 
may still be open bugs that need fixing.


* Solaris used to have a dynamically allocated sact, instead of a 
statically allocated array as all other platforms have. It's not likely 
to be large, and the size is known at compile time, so there seems to be 
no good reason for this.


See above. If you didn't get a compile-time error here then it's likely 
NSIG was already defined.


> cat sig.c
#include 

static int sigs[SIGRTMAX];

int main(int argc, char* argv[]) {
  sigs[0] = 1;
}

 > CC -c sig.c
"sig.c", line 3: Error: An integer constant expression is required 
within the array subscript operator.

1 Error(s) detected.


* Linux and macosx used a uint32_t/uint64_t instead of sigset_t for 
jvmsigs, as aix and solaris do. This is a less robust solution, and the 
added checks show that it has failed in the past. Now all platforms use 
sigset_t/sigismember().


Probably historical (macosx copied linux) and a good change to make. 
That said I have to wonder why we didn't make it when we put in the 
guards on the size.



Also worth noting:

* Solaris is not using pthreads, but it's own thread library, which 
accounts for most of the #ifdef SOLARIS.


Not needed as above.

* In general, if an implementation was needed on one platform, but has 
no effect or is harmless on others, I've kept it on all platforms 
instead of sprinkling the code with #ifdefs.


That depends on your own knowledge/assumptions about the behaviour. I'd 
want to check each such case to verify that is the case. As above the 
use of __thread with "reentry" is not something to use unconditionally 
without closer examination.


To facilitate code review, here is a specially crafted webrev that shows 
the differences compared to each of the individual, original per-OS 
versions of jsig.c:

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01


Appreciated, but still very hard to see when a feature from one OS is 
now being used by all.


I'd be less concerned if we had extensive testing here but I don't think 
we do, so any issues only turn up when something that's been working 
since Java 1.4 suddenly stops working. What testing was done?


Thanks,
David
-


Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03


/Magnus

Re: a.out left in root directory when configuring --with-toolchain-type=clang

[Erik Joelsson]

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


On 2018-03-27 12:35, Martin Buchholz wrote:

I notice that running bash ./configure ... leaves an a.out file in the root
directory of the jdk, but only after adding configure flags

--with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin

(i.e. not when building with default gcc)

Probably there's a test compilation whose output does not go into the
build/ directory, and whose output is not cleaned up.

a.out left in root directory when configuring --with-toolchain-type=clang

[Martin Buchholz]

I notice that running bash ./configure ... leaves an a.out file in the root
directory of the jdk, but only after adding configure flags

--with-toolchain-type=clang --with-toolchain-path=/usr/lib/llvm-3.9/bin

(i.e. not when building with default gcc)

Probably there's a test compilation whose output does not go into the
build/ directory, and whose output is not cleaned up.

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

[Edward Nevill]

On Tue, 2018-03-27 at 17:46 +0900, John Paul Adrian Glaubitz wrote:
> On 03/27/2018 05:23 PM, Edward Nevill wrote:
> > Sorry for the delay. I was doing another test build on qemu which takes 
> > about 3 days.
> > 
> > 
> What confuses me: Why RISCV here and not RISCV64?
> 
> In particular this hunk:
> 
> @@ -1758,6 +1761,7 @@
>  {EM_PARISC,  EM_PARISC,  ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"},
>  {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"},
>  {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"},
> +{EM_RISCV,   EM_RISCV,   ELFCLASS64, ELFDATA2LSB, (char*)"RISCV"},
>};
> 
> I know there is already 32-bit RISC-V and there are actually plans for
> using it. So, it looks to me you would be breaking 32-bit RISC-V here.
> 

We could do something like

{EM_RISCV,   EM_RISCV,   LP64_ONLY(ELFCLASS64) NOT_LP64(ELFCLASS32),
ELFDATA2LSB, (char*)"RISCV"},

Would this work?

All the best,
Ed.

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[Thomas Stüfe]

Hi Magnus,

just a cursory look, will look in greater detail tomorrow.

This is good, thanks for doing this.

As I wrote offlist, please remove the painfully wrong AIX "workarounds". I
do not know why we did this - the original code is quite old - my
assumption is that dlsym(RTLD_NEXT) was not working as expected on older
AIX versions. Well, it should work now according to IBMs manpages. Will
test later.

__thread is not Posix. I would prefer pthread_get/set_specific instead,
which is more portable.

Thanks!

Thomas





On Tue, Mar 27, 2018 at 11:42 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> When I was about to update jsig.c, I noticed that the four copies for aix,
> linux, macosx and solaris were basically the same, with only small
> differences. Some of the differences were not even well motivated, but were
> likely the result of this code duplication causing the code to diverge.
>
> A better solution is to unify them all into a single unix version, with
> the few platform-specific changes handled on a per-platform basis.
>
> I've made the following notable changes:
>
> * I have removed the version check for Solaris. All other platforms seem
> to do fine without it, and in general, we don't mistrust other JDK
> libraries. An alternative is to add this version check to all other
> platforms instead. If you think this is the correct course of action, let
> me know and I'll fix it.
>
> * Solaris used to have a dynamically allocated sact, instead of a
> statically allocated array as all other platforms have. It's not likely to
> be large, and the size is known at compile time, so there seems to be no
> good reason for this.
>
> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for
> jvmsigs, as aix and solaris do. This is a less robust solution, and the
> added checks show that it has failed in the past. Now all platforms use
> sigset_t/sigismember().
>
> Also worth noting:
>
> * Solaris is not using pthreads, but it's own thread library, which
> accounts for most of the #ifdef SOLARIS.
>
> * In general, if an implementation was needed on one platform, but has no
> effect or is harmless on others, I've kept it on all platforms instead of
> sprinkling the code with #ifdefs.
>
> To facilitate code review, here is a specially crafted webrev that shows
> the differences compared to each of the individual, original per-OS
> versions of jsig.c:
> http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/
> webrev.03
>
> /Magnus
>

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[Erik Joelsson]

Build change looks good. I will let someone more informed look at the 
code changes.


/Erik


On 2018-03-27 02:42, Magnus Ihse Bursie wrote:
When I was about to update jsig.c, I noticed that the four copies for 
aix, linux, macosx and solaris were basically the same, with only 
small differences. Some of the differences were not even well 
motivated, but were likely the result of this code duplication causing 
the code to diverge.


A better solution is to unify them all into a single unix version, 
with the few platform-specific changes handled on a per-platform basis.


I've made the following notable changes:

* I have removed the version check for Solaris. All other platforms 
seem to do fine without it, and in general, we don't mistrust other 
JDK libraries. An alternative is to add this version check to all 
other platforms instead. If you think this is the correct course of 
action, let me know and I'll fix it.


* Solaris used to have a dynamically allocated sact, instead of a 
statically allocated array as all other platforms have. It's not 
likely to be large, and the size is known at compile time, so there 
seems to be no good reason for this.


* Linux and macosx used a uint32_t/uint64_t instead of sigset_t for 
jvmsigs, as aix and solaris do. This is a less robust solution, and 
the added checks show that it has failed in the past. Now all 
platforms use sigset_t/sigismember().


Also worth noting:

* Solaris is not using pthreads, but it's own thread library, which 
accounts for most of the #ifdef SOLARIS.


* In general, if an implementation was needed on one platform, but has 
no effect or is harmless on others, I've kept it on all platforms 
instead of sprinkling the code with #ifdefs.


To facilitate code review, here is a specially crafted webrev that 
shows the differences compared to each of the individual, original 
per-OS versions of jsig.c:

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01

Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03


/Magnus

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

[Edward Nevill]

On Tue, 2018-03-27 at 17:46 +0900, John Paul Adrian Glaubitz wrote:
> On 03/27/2018 05:23 PM, Edward Nevill wrote:
> > @@ -1733,6 +1733,9 @@
> >  #ifndef EM_AARCH64
> >#define EM_AARCH64183   /* ARM AARCH64 */
> >  #endif
> > +#ifndef EM_RISCV  /* RISCV */
> > +  #define EM_RISCV  243
> > +#endif
> 
> What confuses me: Why RISCV here and not RISCV64?
> 
> In particular this hunk:
> 
> @@ -1758,6 +1761,7 @@
>  {EM_PARISC,  EM_PARISC,  ELFCLASS32, ELFDATA2MSB,
> (char*)"PARISC"},
>  {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB,
> (char*)"M68k"},
>  {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB,
> (char*)"AARCH64"},
> +{EM_RISCV,   EM_RISCV,   ELFCLASS64, ELFDATA2LSB,
> (char*)"RISCV"},
>};
> 
> I know there is already 32-bit RISC-V and there are actually plans
> for
> using it. So, it looks to me you would be breaking 32-bit RISC-V
> here.
> 

Because that is what is defined in elf.h

>From /usr/include/elf.h

#define EM_RISCV243 /* RISC-V */

There is no EM_RISCV32 or EM_RISCV64 in elf.h

All the best,
Ed.

RE: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl

[Baesken, Matthias]

Thanks Leo .
We have tested the same here locally  in our OpenJDK night builds .

Best regards, Matthias

> -Original Message-
> From: Leo Korinth [mailto:leo.kori...@oracle.com]
> Sent: Dienstag, 27. März 2018 14:02
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; 'hotspot-
> d...@openjdk.java.net' 
> Cc: Simonis, Volker 
> Subject: Re: 8200246 : AIX build fails after adjustments of
> src/hotspot/share/trace/traceEventClasses.xsl
> 
> >
> > Adding  the  template  parameter   to TraceEvent   makes  xlc happy too.
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/
> >
> >
> > Are you fine with this change ?
> 
> Observe that this is not a review. I have tested that your fix should
> compile on linux, solaris, windows and mac.
> 
> Thanks,
> Leo
> > Best regards, Matthias
> >

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[David Holmes]

Hi Magnus,

I will take a look at this tomorrow. There are some open bugs on jsig 
regarding the number of signals it can handle on different platforms 
IIRC. Also the Solaris differences may not be needed as the pthread 
functions can be used without any concern in most cases.


Thanks,
David

On 27/03/2018 7:42 PM, Magnus Ihse Bursie wrote:
When I was about to update jsig.c, I noticed that the four copies for 
aix, linux, macosx and solaris were basically the same, with only small 
differences. Some of the differences were not even well motivated, but 
were likely the result of this code duplication causing the code to 
diverge.


A better solution is to unify them all into a single unix version, with 
the few platform-specific changes handled on a per-platform basis.


I've made the following notable changes:

* I have removed the version check for Solaris. All other platforms seem 
to do fine without it, and in general, we don't mistrust other JDK 
libraries. An alternative is to add this version check to all other 
platforms instead. If you think this is the correct course of action, 
let me know and I'll fix it.


* Solaris used to have a dynamically allocated sact, instead of a 
statically allocated array as all other platforms have. It's not likely 
to be large, and the size is known at compile time, so there seems to be 
no good reason for this.


* Linux and macosx used a uint32_t/uint64_t instead of sigset_t for 
jvmsigs, as aix and solaris do. This is a less robust solution, and the 
added checks show that it has failed in the past. Now all platforms use 
sigset_t/sigismember().


Also worth noting:

* Solaris is not using pthreads, but it's own thread library, which 
accounts for most of the #ifdef SOLARIS.


* In general, if an implementation was needed on one platform, but has 
no effect or is harmless on others, I've kept it on all platforms 
instead of sprinkling the code with #ifdefs.


To facilitate code review, here is a specially crafted webrev that shows 
the differences compared to each of the individual, original per-OS 
versions of jsig.c:

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01

Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03


/Magnus

Re: RFR (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[John Paul Adrian Glaubitz]

On 03/27/2018 06:42 PM, Magnus Ihse Bursie wrote:
> * Linux and macosx used a uint32_t/uint64_t instead of sigset_t for jvmsigs, 
> as aix and solaris do. This is a less robust solution, and the added checks 
> show
> that it has failed in the past. Now all platforms use sigset_t/sigismember().

Ah, this is great. I guess Debian can then drop this patch we have for the MIPS
targets [1, 2]. This patch is necessary because MIPS has 128 signals and 
uint64_t
is not enough for that.

I will test whether your change makes this particular Debian patch obsolete.

Adrian

> [1] 
> https://sources.debian.org/src/openjdk-11/11%7E5-1/debian/patches/mips-sigset.diff/
> [2] 
> https://sources.debian.org/src/openjdk-9/9.0.4+12-3/debian/patches/mips-sigset.diff/

-- 
 .''`.  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 (M): JDK-8200298 Unify all unix versions of libjsig/jsig.c

[Magnus Ihse Bursie]

When I was about to update jsig.c, I noticed that the four copies for 
aix, linux, macosx and solaris were basically the same, with only small 
differences. Some of the differences were not even well motivated, but 
were likely the result of this code duplication causing the code to diverge.


A better solution is to unify them all into a single unix version, with 
the few platform-specific changes handled on a per-platform basis.


I've made the following notable changes:

* I have removed the version check for Solaris. All other platforms seem 
to do fine without it, and in general, we don't mistrust other JDK 
libraries. An alternative is to add this version check to all other 
platforms instead. If you think this is the correct course of action, 
let me know and I'll fix it.


* Solaris used to have a dynamically allocated sact, instead of a 
statically allocated array as all other platforms have. It's not likely 
to be large, and the size is known at compile time, so there seems to be 
no good reason for this.


* Linux and macosx used a uint32_t/uint64_t instead of sigset_t for 
jvmsigs, as aix and solaris do. This is a less robust solution, and the 
added checks show that it has failed in the past. Now all platforms use 
sigset_t/sigismember().


Also worth noting:

* Solaris is not using pthreads, but it's own thread library, which 
accounts for most of the #ifdef SOLARIS.


* In general, if an implementation was needed on one platform, but has 
no effect or is harmless on others, I've kept it on all platforms 
instead of sprinkling the code with #ifdefs.


To facilitate code review, here is a specially crafted webrev that shows 
the differences compared to each of the individual, original per-OS 
versions of jsig.c:

http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.01

Bug: https://bugs.openjdk.java.net/browse/JDK-8200298
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200298-unify-libjsig/webrev.03

/Magnus

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

[John Paul Adrian Glaubitz]

On 03/27/2018 05:23 PM, Edward Nevill wrote:
> Sorry for the delay. I was doing another test build on qemu which takes about 
> 3 days.
> 
> Please review the following webrev
> 
> http://cr.openjdk.java.net/~enevill/8199138/webrev.02
> 
> This has the following additional changes over the previous webrev
> 
> 1) Add comment in os_linux.cpp
> 
> @@ -1733,6 +1733,9 @@
>  #ifndef EM_AARCH64
>#define EM_AARCH64183   /* ARM AARCH64 */
>  #endif
> +#ifndef EM_RISCV  /* RISCV */
> +  #define EM_RISCV  243
> +#endif

What confuses me: Why RISCV here and not RISCV64?

In particular this hunk:

@@ -1758,6 +1761,7 @@
 {EM_PARISC,  EM_PARISC,  ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"},
 {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"},
 {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"},
+{EM_RISCV,   EM_RISCV,   ELFCLASS64, ELFDATA2LSB, (char*)"RISCV"},
   };

I know there is already 32-bit RISC-V and there are actually plans for
using it. So, it looks to me you would be breaking 32-bit RISC-V here.

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: 8199138: Add RISC-V support to Zero

[Edward Nevill]

Hi,

On Tue, 2018-03-27 at 14:10 +0900, John Paul Adrian Glaubitz wrote:
> On 03/24/2018 02:26 AM, Magnus Ihse Bursie wrote:
> > 
> > On 2018-03-20 14:54, Edward Nevill wrote:
> > > Thanks for this. I have updated the webrev with the above comment.
> > > 
> > > http://cr.openjdk.java.net/~enevill/8199138/webrev.01
> > 
> > I note that in platform.m4 (sorry I didn't say this earlier), you set the 
> > CPU_ARCH to riscv64 as well, and not just riscv. Now I don't know how 
> > likely it is
> > that OpenJDK will ever support the 32-bit version of riscv, but it seems 
> > like it would make more sense to define the CPU_ARCH as "riscv", and the 
> > CPU as "riscv64".
> > 
> > It's just a minor thing, if you like it the way it is, keep it.
> 
> I agree, this is a bit odd.
> 
> @Edward: Is this correct as it currently is? Would be great if this changeset
> could finally get merged as Debian just recently bootstrapped riscv64 and
> is now building packages on real hardware with 10 build machines running:
> 

Sorry for the delay. I was doing another test build on qemu which takes about 3 
days.

Please review the following webrev

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

This has the following additional changes over the previous webrev

1) Add comment in os_linux.cpp

@@ -1733,6 +1733,9 @@
 #ifndef EM_AARCH64
   #define EM_AARCH64183   /* ARM AARCH64 */
 #endif
+#ifndef EM_RISCV  /* RISCV */
+  #define EM_RISCV  243
+#endif

   static const arch_t arch_array[]={
 {EM_386, EM_386, ELFCLASS32, ELFDATA2LSB, (char*)"IA 32"},

2) Add RISCV to the #error list in os_linux.cpp

@@ -1794,7 +1800,7 @@
   static  Elf32_Half running_arch_code=EM_SH;
 #else
 #error Method os::dll_load requires that one of following is defined:\
-AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, 
__powerpc__, __powerpc64__, S390, SH, __sparc
+AARCH64, ALPHA, ARM, AMD64, IA32, IA64, M68K, MIPS, MIPSEL, PARISC, 
__powerpc__, __powerpc64__, S390, SH, __sparc, RISCV
 #endif

   // Identify compatability class for VM's architecture and library's 
architecture

3) Use 'riscv' instead of 'riscv64' for VAR_CPU_ARCH in platform.m4

@@ -114,6 +114,12 @@
   VAR_CPU_BITS=64
   VAR_CPU_ENDIAN=little
   ;;
+riscv64)
+  VAR_CPU=riscv64
+  VAR_CPU_ARCH=riscv
+  VAR_CPU_BITS=64
+  VAR_CPU_ENDIAN=little
+  ;;

4) Add riscv to the list of arch which do not have -m64 in flags.m4

@@ -237,7 +237,8 @@
 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" != xriscv64; then
   MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}"
 fi
   fi

(This is necessary to get it building again. The previous webrev was based on a 
rev which did not have the -m64 problem)

I have run this through submit-hs with no problems and as mentioned have also 
done a complete rebuild under qemu for riscv.

Thanks for your patience,
Ed.

RE: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl

[Langer, Christoph]

Hi Matthias,

looks good to me, too.

Best regards
Christoph

From: Baesken, Matthias
Sent: Dienstag, 27. März 2018 09:23
To: Thomas Stüfe 
Cc: build-dev@openjdk.java.net; hotspot-...@openjdk.java.net; Simonis, Volker 
; Doerr, Martin ; Langer, 
Christoph 
Subject: RE: 8200246 : AIX build fails after adjustments of 
src/hotspot/share/trace/traceEventClasses.xsl

Hi Thomas , thanks for the review .

Can I have a second review please ?

Best regards, Matthias

From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
Sent: Montag, 26. März 2018 20:14
To: Baesken, Matthias 
>
Cc: build-dev@openjdk.java.net; 
hotspot-...@openjdk.java.net; Simonis, 
Volker >; Doerr, Martin 
>
Subject: Re: 8200246 : AIX build fails after adjustments of 
src/hotspot/share/trace/traceEventClasses.xsl

Hi Matthias,

thanks for fixing this!

Patch works and looks ok.

Best Regards, Thomas

On Mon, Mar 26, 2018 at 4:55 PM, Baesken, Matthias 
> wrote:
Hello,  after  recent   adjustments of 
src/hotspot/share/trace/traceEventClasses.xsl
in jdk/hs ( see 8196337: Add commit methods that take all event properties 
as argument ) the AIX build fails.

The  xlC compiler is not happy with

using TraceEvent::commit;

in traceEventClasses.xsl (looks like correct C++ but xlc  12.1 refuses to 
compile ).
Error messages :

/nightly/output-jdk-hs/hotspot/variant-server/gensrc/tracefiles/traceEventClasses.hpp",
 line 226.9: 1540-1113 (S) The class template name "TraceEvent" must be 
followed by a < in this context.


Bug :

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

Adding  the  template  parameter   to TraceEvent   makes  xlc happy too.

http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/


Are you fine with this change ?

Best regards, Matthias

RE: 8200246 : AIX build fails after adjustments of src/hotspot/share/trace/traceEventClasses.xsl

[Baesken, Matthias]

Hi Thomas , thanks for the review .

Can I have a second review please ?

Best regards, Matthias

From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
Sent: Montag, 26. März 2018 20:14
To: Baesken, Matthias 
Cc: build-dev@openjdk.java.net; hotspot-...@openjdk.java.net; Simonis, Volker 
; Doerr, Martin 
Subject: Re: 8200246 : AIX build fails after adjustments of 
src/hotspot/share/trace/traceEventClasses.xsl

Hi Matthias,

thanks for fixing this!

Patch works and looks ok.

Best Regards, Thomas

On Mon, Mar 26, 2018 at 4:55 PM, Baesken, Matthias 
> wrote:
Hello,  after  recent   adjustments of 
src/hotspot/share/trace/traceEventClasses.xsl
in jdk/hs ( see 8196337: Add commit methods that take all event properties 
as argument ) the AIX build fails.

The  xlC compiler is not happy with

using TraceEvent::commit;

in traceEventClasses.xsl (looks like correct C++ but xlc  12.1 refuses to 
compile ).
Error messages :

/nightly/output-jdk-hs/hotspot/variant-server/gensrc/tracefiles/traceEventClasses.hpp",
 line 226.9: 1540-1113 (S) The class template name "TraceEvent" must be 
followed by a < in this context.


Bug :

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

Adding  the  template  parameter   to TraceEvent   makes  xlc happy too.

http://cr.openjdk.java.net/~mbaesken/webrevs/8200246/


Are you fine with this change ?

Best regards, Matthias