Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

Hi Erik, Jesper,

On 6/06/2018 2:59 AM, jesper.wilhelms...@oracle.com wrote:

On 5 Jun 2018, at 08:10, David Holmes  wrote:

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow reflected in 
the name. Though really I don't see why this should be restricted this way ... 
to be honest I don't see hardened as a variant of server vs. client vs. zero 
etc at all, you should be able to harden any of those.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
- only build hotspot "hardened" if requested; and in that case
  - jvm.cfg will list -server and -hardened with server as default

Is that right? I can see that we may choose to always build Oracle JDK this way 
but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot is 
selectable but JDK is not. ??


Sorry for the lack of information here. There has been a lot of off-list 
discussions behind this change, I've added the background to the bug now.

The short version is that we see a ~25% regression in startup times if the JVM 
is compiled with the gcc flags to avoid speculative execution. We have not 
observed any performance regressions due to compiling the rest of the native 
libraries with these gcc flags, so there doesn't seem to be any reason to have 
different versions of other libraries.


So "benevolent dictatorship"?  ;-)

My main concern is that the updated toolchains that support this have 
all been produced in a mad rush and quite frankly I expect them to be 
buggy. I don't think it is hard to enable the builder of OpenJDK to have 
full choice and control here.


Cheers,
David


/Jesper


Sorry.

David
-


/Erik
On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:

This patch defines flags for disabling speculative execution for GCC and Visual 
Studio and applies
them to all binaries except libjvm when available in the compiler. It defines a 
new jvm feature
no-speculative-cti, which is used to control whether to use the flags for 
libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with this new 
feature added.

I think the classic name for such product configuration is "hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Phil Race]

In that case Matthias is good to go after fixing the indentation.

-phil.

On 06/05/2018 01:37 PM, Sergey Bylokhov wrote:

I have checked the fix using mach5.

On 05/06/2018 12:45, Phil Race wrote:
Oh .. can I please ask that you make sure that VS2017 is OK with the 
re-enabled
warning ? I seriously doubt that it has anything new to add over 
VS2013, but a jdk-submit

will tell you if it has ..

VS2017 is now the default so a jdk-submit will use that.

-phil.

On 06/05/2018 12:43 PM, Phil Race wrote:
This looks good to me except for what looks like in my browser like 
missing indentation in
http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows 


/GDIRenderer.cpp.udiff.html

You can fix that with or without an updated webrev.

Good to clear a class of warnings.

-phil.

On 06/05/2018 12:47 AM, Baesken, Matthias wrote:

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev 
reviewers ?


Best Regards, Matthias



-Original Message-
From: Langer, Christoph
Sent: Montag, 4. Juni 2018 16:49
To: Baesken, Matthias ; Thomas Stüfe
; 'build-dev@openjdk.java.net' ; awt-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>
Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph


-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 16:20
To: Thomas Stüfe ; 'build-
d...@openjdk.java.net' ; awt-
d...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by

Thomas

- reenabled the cl warning showing the exception issues  in
make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues 
after

reenabling the warnings

Please review :

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

(cc-ing  build-dev   because of  the makefile change, and
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
because of the awt change )


Thanks, Matthias




-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 09:24
To: 'Thomas Stüfe' 
Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception

in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

A small update  -  I found a second  place  in WPrinterJob.cpp 
where  the
exception handling is missing. After fixing both places I can 
reenable

warning 4297  in
Awt2dLibraries.gmk  which has been  disabled before , probably

because

of

the warnings generated when the exceptions where not handled .
Should I update the change with the other file + makefile change ?

Best regards, Matthias



hg diff

diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 
+0800
+++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 
+0200

@@ -213,6 +213,7 @@
LIBAWT_CFLAGS += -fgcse-after-reload
  endif


  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
  NAME := awt, \
  SRC := $(LIBAWT_DIRS), \
@@ -224,7 +225,7 @@
  format-nonliteral parentheses, \
  DISABLED_WARNINGS_clang := logical-op-parentheses extern-

initializer,

\

DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
-DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
+DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
  ASFLAGS := $(LIBAWT_ASFLAGS), \
  LDFLAGS := $(LDFLAGS_JDKLIB) $(call 
SET_SHARED_LIBRARY_ORIGIN),

\

  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
diff -r 12fe57c319e1


src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp

---


a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppTue Apr 10 11:02:09 2018 +0800
+++


b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppMon Jun 04 09:18:03 2018 +0200
@@ -85,7 +85,13 @@
  *pNpoints = outpoints;
  }
  if (outpoints > POLYTEMPSIZE) {
-pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+try {
+pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+} catch (const std::bad_alloc&) {
+return NULL;
+}
  }
  BOOL isempty = fixend;
  for (int i = 0; i < npoints; i++) {
diff -r 12fe57c319e1
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
---

a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Tue Apr 

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Sergey Bylokhov]

I have checked the fix using mach5.

On 05/06/2018 12:45, Phil Race wrote:
Oh .. can I please ask that you make sure that VS2017 is OK with the 
re-enabled
warning ? I seriously doubt that it has anything new to add over VS2013, 
but a jdk-submit

will tell you if it has ..

VS2017 is now the default so a jdk-submit will use that.

-phil.

On 06/05/2018 12:43 PM, Phil Race wrote:
This looks good to me except for what looks like in my browser like 
missing indentation in
http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows 


/GDIRenderer.cpp.udiff.html

You can fix that with or without an updated webrev.

Good to clear a class of warnings.

-phil.

On 06/05/2018 12:47 AM, Baesken, Matthias wrote:

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev 
reviewers ?


Best Regards, Matthias



-Original Message-
From: Langer, Christoph
Sent: Montag, 4. Juni 2018 16:49
To: Baesken, Matthias ; Thomas Stüfe
; 'build-dev@openjdk.java.net' ; awt-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>
Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph


-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 16:20
To: Thomas Stüfe ; 'build-
d...@openjdk.java.net' ; awt-
d...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by

Thomas

- reenabled the cl warning  showing the exception issues  in
make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues 
after

reenabling the warnings

Please review :

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

(cc-ing  build-dev   because of  the makefile change,  and
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
because of the awt change )


Thanks, Matthias




-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 09:24
To: 'Thomas Stüfe' 
Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception

in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

A small update  -  I found a second  place  in WPrinterJob.cpp 
where  the
exception handling is missing. After fixing both places I can 
reenable

warning 4297  in
Awt2dLibraries.gmk  which has been  disabled before , probably

because

of

the warnings generated when the exceptions where not handled .
Should I update the change with the other file + makefile change ?

Best regards, Matthias



hg diff

diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 +0800
+++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 +0200
@@ -213,6 +213,7 @@
    LIBAWT_CFLAGS += -fgcse-after-reload
  endif


  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
  NAME := awt, \
  SRC := $(LIBAWT_DIRS), \
@@ -224,7 +225,7 @@
  format-nonliteral parentheses, \
  DISABLED_WARNINGS_clang := logical-op-parentheses extern-

initializer,

\

  DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
-    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
+    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
  ASFLAGS := $(LIBAWT_ASFLAGS), \
  LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),

\

  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
diff -r 12fe57c319e1


src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp

---


a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

pp    Tue Apr 10 11:02:09 2018 +0800
+++


b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

pp    Mon Jun 04 09:18:03 2018 +0200
@@ -85,7 +85,13 @@
  *pNpoints = outpoints;
  }
  if (outpoints > POLYTEMPSIZE) {
-    pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+    try {
+    pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+    } catch (const std::bad_alloc&) {
+    return NULL;
+    }
  }
  BOOL isempty = fixend;
  for (int i = 0; i < npoints; i++) {
diff -r 12fe57c319e1
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
---

a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Tue Apr 10 11:02:09 2018 +0800
+++

b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Mon Jun 04 09:18:03 2018 

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Sergey Bylokhov]

Looks fine.

On 05/06/2018 09:05, Erik Joelsson wrote:
Build change looks ok, but the validity of disabling the warning needs 
review from someone else.


/Erik


On 2018-06-05 00:47, Baesken, Matthias wrote:

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev  
reviewers ?


Best Regards, Matthias



-Original Message-
From: Langer, Christoph
Sent: Montag, 4. Juni 2018 16:49
To: Baesken, Matthias ; Thomas Stüfe
; 'build-dev@openjdk.java.net' ; awt-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>
Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph


-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 16:20
To: Thomas Stüfe ; 'build-
d...@openjdk.java.net' ; awt-
d...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by

Thomas

- reenabled the cl warning  showing the exception issues  in
make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues  
after

reenabling the warnings

Please review :

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

(cc-ing  build-dev   because of  the makefile change,  and
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
because of the awt change )


Thanks, Matthias




-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 09:24
To: 'Thomas Stüfe' 
Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception

in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

A small update  -  I found a second  place  in WPrinterJob.cpp   
where  the

exception handling is missing. After fixing both places I can reenable
warning 4297  in
Awt2dLibraries.gmk  which has been  disabled before , probably

because

of

the warnings generated when the exceptions where not handled .
Should I update the change with the other file + makefile change ?

Best regards, Matthias



hg diff

diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 +0800
+++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 +0200
@@ -213,6 +213,7 @@
    LIBAWT_CFLAGS += -fgcse-after-reload
  endif


  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
  NAME := awt, \
  SRC := $(LIBAWT_DIRS), \
@@ -224,7 +225,7 @@
  format-nonliteral parentheses, \
  DISABLED_WARNINGS_clang := logical-op-parentheses extern-

initializer,

\

  DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
-    DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
+    DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
  ASFLAGS := $(LIBAWT_ASFLAGS), \
  LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),

\

  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
diff -r 12fe57c319e1


src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp

---


a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

pp    Tue Apr 10 11:02:09 2018 +0800
+++


b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

pp    Mon Jun 04 09:18:03 2018 +0200
@@ -85,7 +85,13 @@
  *pNpoints = outpoints;
  }
  if (outpoints > POLYTEMPSIZE) {
-    pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+    try {
+    pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+    } catch (const std::bad_alloc&) {
+    return NULL;
+    }
  }
  BOOL isempty = fixend;
  for (int i = 0; i < npoints; i++) {
diff -r 12fe57c319e1
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
---

a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Tue Apr 10 11:02:09 2018 +0800
+++

b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Mon Jun 04 09:18:03 2018 +0200
@@ -873,7 +873,12 @@
    int numSizes = ::DeviceCapabilities(printerName, printerPort,
    DC_PAPERS, NULL, NULL);
    if (numSizes > 0) {
-  LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
numSizes, sizeof(WORD));
+  LPTSTR papers;
+  try {
+  papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,

numSizes,

sizeof(WORD));
+  } catch (const std::bad_alloc&) {
+  papers = NULL;
+  }
    if (papers != NULL &&
 

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Phil Race]

Oh .. can I please ask that you make sure that VS2017 is OK with the 
re-enabled
warning ? I seriously doubt that it has anything new to add over VS2013, 
but a jdk-submit

will tell you if it has ..

VS2017 is now the default so a jdk-submit will use that.

-phil.

On 06/05/2018 12:43 PM, Phil Race wrote:
This looks good to me except for what looks like in my browser like 
missing indentation in
http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows 


/GDIRenderer.cpp.udiff.html

You can fix that with or without an updated webrev.

Good to clear a class of warnings.

-phil.

On 06/05/2018 12:47 AM, Baesken, Matthias wrote:

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev  
reviewers ?


Best Regards, Matthias



-Original Message-
From: Langer, Christoph
Sent: Montag, 4. Juni 2018 16:49
To: Baesken, Matthias ; Thomas Stüfe
; 'build-dev@openjdk.java.net' ; awt-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>
Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph


-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 16:20
To: Thomas Stüfe ; 'build-
d...@openjdk.java.net' ; awt-
d...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by

Thomas

- reenabled the cl warning  showing the exception issues  in
make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues  
after

reenabling the warnings

Please review :

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

(cc-ing  build-dev   because of  the makefile change,  and
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
because of the awt change )


Thanks, Matthias




-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 09:24
To: 'Thomas Stüfe' 
Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ 
exception

in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

A small update  -  I found a second  place  in WPrinterJob.cpp   
where  the
exception handling is missing. After fixing both places I can 
reenable

warning 4297  in
Awt2dLibraries.gmk  which has been  disabled before , probably

because

of

the warnings generated when the exceptions where not handled .
Should I update the change with the other file + makefile change ?

Best regards, Matthias



hg diff

diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 +0800
+++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 +0200
@@ -213,6 +213,7 @@
LIBAWT_CFLAGS += -fgcse-after-reload
  endif


  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
  NAME := awt, \
  SRC := $(LIBAWT_DIRS), \
@@ -224,7 +225,7 @@
  format-nonliteral parentheses, \
  DISABLED_WARNINGS_clang := logical-op-parentheses extern-

initializer,

\

  DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
-DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
+DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
  ASFLAGS := $(LIBAWT_ASFLAGS), \
  LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),

\

  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
diff -r 12fe57c319e1


src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp

---


a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppTue Apr 10 11:02:09 2018 +0800
+++


b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppMon Jun 04 09:18:03 2018 +0200
@@ -85,7 +85,13 @@
  *pNpoints = outpoints;
  }
  if (outpoints > POLYTEMPSIZE) {
-pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+try {
+pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+} catch (const std::bad_alloc&) {
+return NULL;
+}
  }
  BOOL isempty = fixend;
  for (int i = 0; i < npoints; i++) {
diff -r 12fe57c319e1
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
---

a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Tue Apr 10 11:02:09 2018 +0800
+++

b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Mon Jun 04 09:18:03 2018 +0200
@@ -873,7 +873,12 @@
int numSizes = 

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Phil Race]

This looks good to me except for what looks like in my browser like 
missing indentation in

http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/src/java.desktop/windows/native/libawt/java2d/windows
/GDIRenderer.cpp.udiff.html

You can fix that with or without an updated webrev.

Good to clear a class of warnings.

-phil.

On 06/05/2018 12:47 AM, Baesken, Matthias wrote:

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev  reviewers ?

Best Regards, Matthias



-Original Message-
From: Langer, Christoph
Sent: Montag, 4. Juni 2018 16:49
To: Baesken, Matthias ; Thomas Stüfe
; 'build-dev@openjdk.java.net' ; awt-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>
Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph


-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 16:20
To: Thomas Stüfe ; 'build-
d...@openjdk.java.net' ; awt-
d...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by

Thomas

- reenabled the cl warning  showing the exception issues  in
make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues  after
reenabling the warnings

Please review :

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

(cc-ing  build-dev   because of  the makefile change,  and
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
because of the awt change )


Thanks, Matthias




-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 09:24
To: 'Thomas Stüfe' 
Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception

in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
exception handling is missing. After fixing both places I can reenable
warning 4297  in
Awt2dLibraries.gmk  which has been  disabled before , probably

because

of

the warnings generated when the exceptions where not handled .
Should I update the change with the other file + makefile change ?

Best regards, Matthias



hg diff

diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 +0800
+++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 +0200
@@ -213,6 +213,7 @@
LIBAWT_CFLAGS += -fgcse-after-reload
  endif


  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
  NAME := awt, \
  SRC := $(LIBAWT_DIRS), \
@@ -224,7 +225,7 @@
  format-nonliteral parentheses, \
  DISABLED_WARNINGS_clang := logical-op-parentheses extern-

initializer,

\

  DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
-DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
+DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
  ASFLAGS := $(LIBAWT_ASFLAGS), \
  LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),

\

  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
diff -r 12fe57c319e1


src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp

---


a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppTue Apr 10 11:02:09 2018 +0800
+++


b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppMon Jun 04 09:18:03 2018 +0200
@@ -85,7 +85,13 @@
  *pNpoints = outpoints;
  }
  if (outpoints > POLYTEMPSIZE) {
-pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+try {
+pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+} catch (const std::bad_alloc&) {
+return NULL;
+}
  }
  BOOL isempty = fixend;
  for (int i = 0; i < npoints; i++) {
diff -r 12fe57c319e1
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
---

a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Tue Apr 10 11:02:09 2018 +0800
+++

b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Mon Jun 04 09:18:03 2018 +0200
@@ -873,7 +873,12 @@
int numSizes = ::DeviceCapabilities(printerName, printerPort,
DC_PAPERS, NULL, NULL);
if (numSizes > 0) {
-  LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
numSizes, sizeof(WORD));
+  LPTSTR papers;
+  try {
+  papers = 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

> On 5 Jun 2018, at 08:10, David Holmes  wrote:
> 
> Sorry to be late to this party ...
> 
> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>> Renamed the new jvm variant to "hardened".
> 
> As it is a hardened server build I'd prefer if that were somehow reflected in 
> the name. Though really I don't see why this should be restricted this way 
> ... to be honest I don't see hardened as a variant of server vs. client vs. 
> zero etc at all, you should be able to harden any of those.
> 
> So IIUC with this change we will:
> - always build JDK native code "hardened" (if toolchain supports it)
> - only build hotspot "hardened" if requested; and in that case
>  - jvm.cfg will list -server and -hardened with server as default
> 
> Is that right? I can see that we may choose to always build Oracle JDK this 
> way but it isn't clear to me that its suitable for OpenJDK. Nor why hotspot 
> is selectable but JDK is not. ??

Sorry for the lack of information here. There has been a lot of off-list 
discussions behind this change, I've added the background to the bug now.

The short version is that we see a ~25% regression in startup times if the JVM 
is compiled with the gcc flags to avoid speculative execution. We have not 
observed any performance regressions due to compiling the rest of the native 
libraries with these gcc flags, so there doesn't seem to be any reason to have 
different versions of other libraries.

/Jesper

> Sorry.
> 
> David
> -
> 
>> /Erik
>> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
 On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:
 
 Hello,
 
 On 2018-06-01 14:00, Aleksey Shipilev wrote:
> On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>> This patch defines flags for disabling speculative execution for GCC and 
>> Visual Studio and applies
>> them to all binaries except libjvm when available in the compiler. It 
>> defines a new jvm feature
>> no-speculative-cti, which is used to control whether to use the flags 
>> for libjvm. It also defines a
>> new jvm variant "altserver" which is the same as server, but with this 
>> new feature added.
> I think the classic name for such product configuration is "hardened", no?
 I don't know. I'm open to suggestions on naming.
>>> "hardened" sounds good to me.
>>> 
>>> The change looks good as well.
>>> /Jesper
>>> 
 /Erik
> -Aleksey
> 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Volker Simonis]

On Tue, Jun 5, 2018 at 6:47 PM, Erik Joelsson  wrote:
> Hello Volker,
>
> On 2018-06-05 09:35, Volker Simonis wrote:
>>
>> Hi Erik,
>>
>> you wrote: "Note that this applies to the build time C++ flags, not
>> the compiler in the JVM itself." So what about the code generated by
>> the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
>> code already "hardened" against speculative execution? If yes, that's
>> fine, if not, I don't see the point in hardening the HotSpot code
>> itself if the VM still generates potentially "insecure" code.
>
> Correct. These are just the build changes for the build time compiler
> options. Further work will be done by Hotspot engineers.
>>
>> And I still don't fully understand how things work if you build both
>> variants by default (as you intend to do it for Oracle builds). Will
>> you end up with two subdirectories (lib/server/ and lib/altserver)
>> where both contain a libjvm.so and the user can use "java -altserver"
>> on the command line to choose the hardened version?
>
> Correct, we use the old jvm variant mechanism, so this will work just like
> -server/-client used to work, two completely separate libjvm.so in separate
> sub directories.
>

OK. Thanks for the quick confirmation.

> /Erik
>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson 
>> wrote:
>>>
>>> Hello,
>>>
>>> On 2018-06-04 23:10, David Holmes wrote:

 Sorry to be late to this party ...

 On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>
> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>
> Renamed the new jvm variant to "hardened".


 As it is a hardened server build I'd prefer if that were somehow
 reflected
 in the name. Though really I don't see why this should be restricted
 this
 way ... to be honest I don't see hardened as a variant of server vs.
 client
 vs. zero etc at all, you should be able to harden any of those.

>>> I agree, and you sort of can. By adding the jvm feature
>>> "no-speculative-cti"
>>> to any jvm variant, you get the flags. The name of the predefined variant
>>> can be discussed. I initially suggested altserver because I, as you,
>>> thought
>>> it should include server in the name. But ultimately, I don't care that
>>> much
>>> about a name. There is also little point in defining a whole set of
>>> predefined variants that nobody has requested. If we ever need more
>>> specialized variants in the same image, we will add them.

 So IIUC with this change we will:
 - always build JDK native code "hardened" (if toolchain supports it)
>>>
>>> Yes, this is correct. The reason being that no significant performance
>>> impact was detected, so there is no cost.

 - only build hotspot "hardened" if requested; and in that case
- jvm.cfg will list -server and -hardened with server as default
>>>
>>> Correct.


 Is that right? I can see that we may choose to always build Oracle JDK
 this way but it isn't clear to me that its suitable for OpenJDK. Nor why
 hotspot is selectable but JDK is not. ??

>>> We would prefer to always build with security features enabled, but the
>>> performance impact on the JVM is so high that we want to leave it to the
>>> user to decide, both at bulid time and at runtime. With these changes,
>>> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but
>>> any
>>> other person or entity just building the OpenJDK source will just get the
>>> server variant for now (as has been the default for a long time), unless
>>> they specifically ask for "hardened" or activate the new jvm feature
>>> (--with-jvm-feature=no-speculative-cti).
>>>
>>> We don't see the point in giving the choice on the JDK libraries simply
>>> because there is no drawback to enabling the flags.
>>>
>>> /Erik
>>>
 Sorry.

 David
 -

> /Erik
>
>
> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
>>>
>>> On 4 Jun 2018, at 17:52, Erik Joelsson 
>>> wrote:
>>>
>>> Hello,
>>>
>>> On 2018-06-01 14:00, Aleksey Shipilev wrote:

 On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>
> This patch defines flags for disabling speculative execution for
> GCC
> and Visual Studio and applies
> them to all binaries except libjvm when available in the compiler.
> It
> defines a new jvm feature
> no-speculative-cti, which is used to control whether to use the
> flags
> for libjvm. It also defines a
> new jvm variant "altserver" which is the same as server, but with
> this new feature added.

 I think the classic name for such product configuration is
 "hardened",
 no?
>>>
>>> I don't know. I'm open to suggestions on naming.
>>
>> "hardened" sounds good to me.
>>
>> The 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with

[Erik Joelsson]

Hello again,

Looks like Jesper updated the bug description with more info.

/Erik


On 2018-06-05 08:50, Erik Joelsson wrote:

Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I 
think some minimal update version (the option is called -Qspectre), we 
use 15.5.5.


I was not involved in the benchmarking so I don't know any details 
there, only the conclusion.


/Erik


On 2018-06-05 01:30, Baesken, Matthias wrote:


Hi Erik , is there  some info available about  the performance impact 
when  disabling  disabling speculative execution  ?


And which compiler versions are needed for this ?

Best regards, Matthias

>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC 
and


>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to 
the


>user which JVM they want to use. If others would prefer this 
default, we


>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

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

>

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

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

Hello Volker,

On 2018-06-05 09:35, Volker Simonis wrote:

Hi Erik,

you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if not, I don't see the point in hardening the HotSpot code
itself if the VM still generates potentially "insecure" code.
Correct. These are just the build changes for the build time compiler 
options. Further work will be done by Hotspot engineers.

And I still don't fully understand how things work if you build both
variants by default (as you intend to do it for Oracle builds). Will
you end up with two subdirectories (lib/server/ and lib/altserver)
where both contain a libjvm.so and the user can use "java -altserver"
on the command line to choose the hardened version?
Correct, we use the old jvm variant mechanism, so this will work just 
like -server/-client used to work, two completely separate libjvm.so in 
separate sub directories.


/Erik

Thank you and best regards,
Volker


On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson  wrote:

Hello,

On 2018-06-04 23:10, David Holmes wrote:

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow reflected
in the name. Though really I don't see why this should be restricted this
way ... to be honest I don't see hardened as a variant of server vs. client
vs. zero etc at all, you should be able to harden any of those.


I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
to any jvm variant, you get the flags. The name of the predefined variant
can be discussed. I initially suggested altserver because I, as you, thought
it should include server in the name. But ultimately, I don't care that much
about a name. There is also little point in defining a whole set of
predefined variants that nobody has requested. If we ever need more
specialized variants in the same image, we will add them.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)

Yes, this is correct. The reason being that no significant performance
impact was detected, so there is no cost.

- only build hotspot "hardened" if requested; and in that case
   - jvm.cfg will list -server and -hardened with server as default

Correct.


Is that right? I can see that we may choose to always build Oracle JDK
this way but it isn't clear to me that its suitable for OpenJDK. Nor why
hotspot is selectable but JDK is not. ??


We would prefer to always build with security features enabled, but the
performance impact on the JVM is so high that we want to leave it to the
user to decide, both at bulid time and at runtime. With these changes,
Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
other person or entity just building the OpenJDK source will just get the
server variant for now (as has been the default for a long time), unless
they specifically ask for "hardened" or activate the new jvm feature
(--with-jvm-feature=no-speculative-cti).

We don't see the point in giving the choice on the JDK libraries simply
because there is no drawback to enabling the flags.

/Erik


Sorry.

David
-


/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson 
wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:

This patch defines flags for disabling speculative execution for GCC
and Visual Studio and applies
them to all binaries except libjvm when available in the compiler. It
defines a new jvm feature
no-speculative-cti, which is used to control whether to use the flags
for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with
this new feature added.

I think the classic name for such product configuration is "hardened",
no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Volker Simonis]

Hi Erik,

you wrote: "Note that this applies to the build time C++ flags, not
the compiler in the JVM itself." So what about the code generated by
the HotSpot (i.e. stubs, template interpreter, c1, c2, Graal)? Is this
code already "hardened" against speculative execution? If yes, that's
fine, if not, I don't see the point in hardening the HotSpot code
itself if the VM still generates potentially "insecure" code.

And I still don't fully understand how things work if you build both
variants by default (as you intend to do it for Oracle builds). Will
you end up with two subdirectories (lib/server/ and lib/altserver)
where both contain a libjvm.so and the user can use "java -altserver"
on the command line to choose the hardened version?

Thank you and best regards,
Volker


On Tue, Jun 5, 2018 at 5:47 PM, Erik Joelsson  wrote:
> Hello,
>
> On 2018-06-04 23:10, David Holmes wrote:
>>
>> Sorry to be late to this party ...
>>
>> On 5/06/2018 6:10 AM, Erik Joelsson wrote:
>>>
>>> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
>>>
>>> Renamed the new jvm variant to "hardened".
>>
>>
>> As it is a hardened server build I'd prefer if that were somehow reflected
>> in the name. Though really I don't see why this should be restricted this
>> way ... to be honest I don't see hardened as a variant of server vs. client
>> vs. zero etc at all, you should be able to harden any of those.
>>
> I agree, and you sort of can. By adding the jvm feature "no-speculative-cti"
> to any jvm variant, you get the flags. The name of the predefined variant
> can be discussed. I initially suggested altserver because I, as you, thought
> it should include server in the name. But ultimately, I don't care that much
> about a name. There is also little point in defining a whole set of
> predefined variants that nobody has requested. If we ever need more
> specialized variants in the same image, we will add them.
>>
>> So IIUC with this change we will:
>> - always build JDK native code "hardened" (if toolchain supports it)
>
> Yes, this is correct. The reason being that no significant performance
> impact was detected, so there is no cost.
>>
>> - only build hotspot "hardened" if requested; and in that case
>>   - jvm.cfg will list -server and -hardened with server as default
>
> Correct.
>>
>>
>> Is that right? I can see that we may choose to always build Oracle JDK
>> this way but it isn't clear to me that its suitable for OpenJDK. Nor why
>> hotspot is selectable but JDK is not. ??
>>
> We would prefer to always build with security features enabled, but the
> performance impact on the JVM is so high that we want to leave it to the
> user to decide, both at bulid time and at runtime. With these changes,
> Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but any
> other person or entity just building the OpenJDK source will just get the
> server variant for now (as has been the default for a long time), unless
> they specifically ask for "hardened" or activate the new jvm feature
> (--with-jvm-feature=no-speculative-cti).
>
> We don't see the point in giving the choice on the JDK libraries simply
> because there is no drawback to enabling the flags.
>
> /Erik
>
>> Sorry.
>>
>> David
>> -
>>
>>> /Erik
>>>
>>>
>>> On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
>
> On 4 Jun 2018, at 17:52, Erik Joelsson 
> wrote:
>
> Hello,
>
> On 2018-06-01 14:00, Aleksey Shipilev wrote:
>>
>> On 06/01/2018 10:53 PM, Erik Joelsson wrote:
>>>
>>> This patch defines flags for disabling speculative execution for GCC
>>> and Visual Studio and applies
>>> them to all binaries except libjvm when available in the compiler. It
>>> defines a new jvm feature
>>> no-speculative-cti, which is used to control whether to use the flags
>>> for libjvm. It also defines a
>>> new jvm variant "altserver" which is the same as server, but with
>>> this new feature added.
>>
>> I think the classic name for such product configuration is "hardened",
>> no?
>
> I don't know. I'm open to suggestions on naming.

 "hardened" sounds good to me.

 The change looks good as well.
 /Jesper

> /Erik
>>
>> -Aleksey
>>
>>>
>

Re: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Erik Joelsson]

Build change looks ok, but the validity of disabling the warning needs 
review from someone else.


/Erik


On 2018-06-05 00:47, Baesken, Matthias wrote:

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev  reviewers ?

Best Regards, Matthias



-Original Message-
From: Langer, Christoph
Sent: Montag, 4. Juni 2018 16:49
To: Baesken, Matthias ; Thomas Stüfe
; 'build-dev@openjdk.java.net' ; awt-...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>
Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hi Matthias,

looks good to me.

Don't forget the Copyright years.

Best regards
Christoph


-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 16:20
To: Thomas Stüfe ; 'build-
d...@openjdk.java.net' ; awt-
d...@openjdk.java.net
Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

Hello,  I prepared a second webrev.

- use now  const-reference  in the catch-statements as suggested by

Thomas

- reenabled the cl warning  showing the exception issues  in
make/lib/Awt2dLibraries.gmk
- found a second place  in  WPrinterJob.cpp   with similar issues  after
reenabling the warnings

Please review :

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

(cc-ing  build-dev   because of  the makefile change,  and
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
because of the awt change )


Thanks, Matthias




-Original Message-
From: Baesken, Matthias
Sent: Montag, 4. Juni 2018 09:24
To: 'Thomas Stüfe' 
Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph

Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception

in

GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

A small update  -  I found a second  place  in WPrinterJob.cpp   where  the
exception handling is missing. After fixing both places I can reenable
warning 4297  in
Awt2dLibraries.gmk  which has been  disabled before , probably

because

of

the warnings generated when the exceptions where not handled .
Should I update the change with the other file + makefile change ?

Best regards, Matthias



hg diff

diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 +0800
+++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 +0200
@@ -213,6 +213,7 @@
LIBAWT_CFLAGS += -fgcse-after-reload
  endif


  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
  NAME := awt, \
  SRC := $(LIBAWT_DIRS), \
@@ -224,7 +225,7 @@
  format-nonliteral parentheses, \
  DISABLED_WARNINGS_clang := logical-op-parentheses extern-

initializer,

\

  DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
-DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
+DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
  ASFLAGS := $(LIBAWT_ASFLAGS), \
  LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),

\

  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
diff -r 12fe57c319e1


src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp

---


a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppTue Apr 10 11:02:09 2018 +0800
+++


b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c

ppMon Jun 04 09:18:03 2018 +0200
@@ -85,7 +85,13 @@
  *pNpoints = outpoints;
  }
  if (outpoints > POLYTEMPSIZE) {
-pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+try {
+pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
sizeof(POINT), outpoints);
+} catch (const std::bad_alloc&) {
+return NULL;
+}
  }
  BOOL isempty = fixend;
  for (int i = 0; i < npoints; i++) {
diff -r 12fe57c319e1
src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
---

a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Tue Apr 10 11:02:09 2018 +0800
+++

b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp

Mon Jun 04 09:18:03 2018 +0200
@@ -873,7 +873,12 @@
int numSizes = ::DeviceCapabilities(printerName, printerPort,
DC_PAPERS, NULL, NULL);
if (numSizes > 0) {
-  LPTSTR papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
numSizes, sizeof(WORD));
+  LPTSTR papers;
+  try {
+  papers = (LPTSTR)SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,

numSizes,

sizeof(WORD));
+  } catch (const std::bad_alloc&) {
+  papers = NULL;
+  }
if (papers != NULL &&
::DeviceCapabilities(printerName, printerPort,
 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with

[Erik Joelsson]

Hello Matthias,

For GCC, you need 7.3.0 or later. For Microsoft you need VS2017 and I 
think some minimal update version (the option is called -Qspectre), we 
use 15.5.5.


I was not involved in the benchmarking so I don't know any details 
there, only the conclusion.


/Erik


On 2018-06-05 01:30, Baesken, Matthias wrote:


Hi Erik , is there  some info available about  the performance impact 
when  disabling  disabling speculative execution  ?


And which compiler versions are needed for this ?

Best regards, Matthias

>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC and

>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to the

>user which JVM they want to use. If others would prefer this default, we

>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

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

>

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

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[Erik Joelsson]

Hello,

On 2018-06-04 23:10, David Holmes wrote:

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow 
reflected in the name. Though really I don't see why this should be 
restricted this way ... to be honest I don't see hardened as a variant 
of server vs. client vs. zero etc at all, you should be able to harden 
any of those.


I agree, and you sort of can. By adding the jvm feature 
"no-speculative-cti" to any jvm variant, you get the flags. The name of 
the predefined variant can be discussed. I initially suggested altserver 
because I, as you, thought it should include server in the name. But 
ultimately, I don't care that much about a name. There is also little 
point in defining a whole set of predefined variants that nobody has 
requested. If we ever need more specialized variants in the same image, 
we will add them.

So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
Yes, this is correct. The reason being that no significant performance 
impact was detected, so there is no cost.

- only build hotspot "hardened" if requested; and in that case
  - jvm.cfg will list -server and -hardened with server as default

Correct.


Is that right? I can see that we may choose to always build Oracle JDK 
this way but it isn't clear to me that its suitable for OpenJDK. Nor 
why hotspot is selectable but JDK is not. ??


We would prefer to always build with security features enabled, but the 
performance impact on the JVM is so high that we want to leave it to the 
user to decide, both at bulid time and at runtime. With these changes, 
Oracle will build OracleJDK, and OpenJDK, with dual JVMs by default, but 
any other person or entity just building the OpenJDK source will just 
get the server variant for now (as has been the default for a long 
time), unless they specifically ask for "hardened" or activate the new 
jvm feature (--with-jvm-feature=no-speculative-cti).


We don't see the point in giving the choice on the JDK libraries simply 
because there is no drawback to enabling the flags.


/Erik

Sorry.

David
-


/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:
On 4 Jun 2018, at 17:52, Erik Joelsson  
wrote:


Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:
This patch defines flags for disabling speculative execution for 
GCC and Visual Studio and applies
them to all binaries except libjvm when available in the 
compiler. It defines a new jvm feature
no-speculative-cti, which is used to control whether to use the 
flags for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with 
this new feature added.
I think the classic name for such product configuration is 
"hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey

Re: [8] RFR (XS) 8204053 : libsaproc.so not linked with -z,noexecstack

[David Holmes]

Looks fine to me.

Thanks,
David


Hi!

Please review this very small fix. It only applies to JDK 8.

bug report:
https://bugs.openjdk.java.net/browse/JDK-8204053

webrev:
http://cr.openjdk.java.net/~dbuck/8204053.0/

JPRT hotspot testset run and passed. Efficacy of fix manually confirmed.

Cheers,
-Buck

Re: RFR: JDK-8200132: Remove jre images and bundles

[Magnus Ihse Bursie]

Build change itself looks good to me. I think this solves the problem for the 
time being, even if the cleanup is not as complete. 

For JDK 12, we should see if we can go further. 

/Magnus

> 4 juni 2018 kl. 23:22 skrev Erik Joelsson :
> 
> Given the feedback, I have revised the patch to restore the ability to 
> produce a legacy jre image, but it is still removed from the default 
> "product-images" and "images" targets. To build it you need to specify it 
> explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx 
> specific image layout). I still removed the bundle targets for the jre image 
> as I very much doubt anyone except Oracle was using them anyway. In addition 
> to this, I also updated the help text a bit to reflect these changes.
> 
> Will this be good enough for those that still need a JRE image?
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
> 
> /Erik
> 
> 
>> On 2018-06-01 15:02, Erik Joelsson wrote:
>> Since JDK 9 and modules, the idea of a prebuilt JRE is no longer providing 
>> much value. The idea is rather that you link together an image with the 
>> modules and settings you actually need, either with or without your 
>> application. For this reason oracle will no longer ship JRE images that 
>> differ content wise to the JDK image in JDK 11 and we would like to remove 
>> them from the OpenJDK build to reduce complexity.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200132
>> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.01/
>> 
>> /Erik
> 

Re: RFR: JDK-8200132: Remove jre images and bundles

[Martijn Verburg]

Thanks Erik,

We do have quite a few requests to build that jRE for AdoptOpenJDK
binaries, and this should let us continue doing that.

Cheers,
Martijn

On 5 June 2018 at 09:41, Alan Bateman  wrote:

> On 04/06/2018 22:22, Erik Joelsson wrote:
>
>> Given the feedback, I have revised the patch to restore the ability to
>> produce a legacy jre image, but it is still removed from the default
>> "product-images" and "images" targets. To build it you need to specify it
>> explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx
>> specific image layout). I still removed the bundle targets for the jre
>> image as I very much doubt anyone except Oracle was using them anyway. In
>> addition to this, I also updated the help text a bit to reflect these
>> changes.
>>
>> Will this be good enough for those that still need a JRE image?
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
>>
> This looks okay to me, and seems better than the configure option
> mentioned in one of the mails.
>
> I think you will still need to do some communication about this change,
> maybe to jdk-dev so that folks that may be relying on the jre image know
> that they need to build the legacy-jre-image target.
>
> I suspect this area of the build will be re-visited again if the Java
> Packager JEP goes ahead as that will need a similar list of modules and
> maybe options.
>
> -Alan.
>

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 04/06/2018 22:22, Erik Joelsson wrote:
Given the feedback, I have revised the patch to restore the ability to 
produce a legacy jre image, but it is still removed from the default 
"product-images" and "images" targets. To build it you need to specify 
it explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the 
macosx specific image layout). I still removed the bundle targets for 
the jre image as I very much doubt anyone except Oracle was using them 
anyway. In addition to this, I also updated the help text a bit to 
reflect these changes.


Will this be good enough for those that still need a JRE image?

Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
This looks okay to me, and seems better than the configure option 
mentioned in one of the mails.


I think you will still need to do some communication about this change, 
maybe to jdk-dev so that folks that may be relying on the jre image know 
that they need to build the legacy-jre-image target.


I suspect this area of the build will be re-visited again if the Java 
Packager JEP goes ahead as that will need a similar list of modules and 
maybe options.


-Alan.

Re: RFR: JDK-8200132: Remove jre images and bundles

[Alan Bateman]

On 04/06/2018 21:40, Bob Vandette wrote:

:
I could live with a jlink option to create a JRE.  The problem is that the list 
of modules required to produce a
compatible JRE is not documented anywhere.  I tried fishing the list out of the 
build makefile but it’s not trivial.  I ended
up running “jimage list module | grep Module: on a JDK 10 JRE to get the list.

The `release` file in the top-level directory has a `MODULES` key with 
the complete list. Alternatively, `java --list-modules`.


In addition, there are other options used and it might that we should 
have the build invoke `jlink` with `--save-opts` so that the options are 
saved. Part of the original motive for `--save-opts` was to support a 
way to "relink" to re-run the link with the same options but pick up 
newer versions of the modules.


-Alan

RE: RFR: JDK-8202384: Introduce altserver jvm variant with

[Baesken, Matthias]

Hi Erik , is there  some info available about  the performance impact when  
disabling  disabling speculative execution  ?



And which compiler versions are needed for this ?



Best regards, Matthias





>We need to add compilation flags for disabling speculative execution to

>our native libraries and executables. In order to allow for users not

>affected by problems with speculative execution to run a JVM at full

>speed, we need to be able to ship two JVM libraries - one that is

>compiled with speculative execution enabled, and one that is compiled

>without. Note that this applies to the build time C++ flags, not the

>compiler in the JVM itself. Luckily adding these flags to the rest of

>the native libraries did not have a significant performance impact so

>there is no need for making it optional there.

>

>This patch defines flags for disabling speculative execution for GCC and

>Visual Studio and applies them to all binaries except libjvm when

>available in the compiler. It defines a new jvm feature

>no-speculative-cti, which is used to control whether to use the flags

>for libjvm. It also defines a new jvm variant "altserver" which is the

>same as server, but with this new feature added.

>

>For Oracle builds, we are changing the default for linux-x64 and

>windows-x64 to build both server and altserver, giving the choice to the

>user which JVM they want to use. If others would prefer this default, we

>could make it default in configure as well.

>

>The change in GensrcJFR.gmk fixes a newly introduced race that appears

>when building multiple jvm variants.

>

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

>

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

RE: RFR: JDK-8204211: windows : handle potential C++ exception in GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using SAFE_SIZE_ARRAY_ALLOC / safe_Malloc

[Baesken, Matthias]

Hi Christoph, thank's for the  review .
Could I have a second one  for example from the  awt or build-dev  reviewers ?

Best Regards, Matthias


> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 4. Juni 2018 16:49
> To: Baesken, Matthias ; Thomas Stüfe
> ; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>; awt-...@openjdk.java.net
> Cc: 2d-dev <2d-...@openjdk.java.net>
> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> 
> Hi Matthias,
> 
> looks good to me.
> 
> Don't forget the Copyright years.
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: Baesken, Matthias
> > Sent: Montag, 4. Juni 2018 16:20
> > To: Thomas Stüfe ; 'build-
> > d...@openjdk.java.net' ; awt-
> > d...@openjdk.java.net
> > Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph
> > 
> > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> >
> > Hello,  I prepared a second webrev.
> >
> > - use now  const-reference  in the catch-statements as suggested by
> Thomas
> > - reenabled the cl warning  showing the exception issues  in
> > make/lib/Awt2dLibraries.gmk
> > - found a second place  in  WPrinterJob.cpp   with similar issues  after
> > reenabling the warnings
> >
> > Please review :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8204211.1/
> >
> > (cc-ing  build-dev   because of  the makefile change,  and
> > src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > because of the awt change )
> >
> >
> > Thanks, Matthias
> >
> >
> >
> > > -Original Message-
> > > From: Baesken, Matthias
> > > Sent: Montag, 4. Juni 2018 09:24
> > > To: 'Thomas Stüfe' 
> > > Cc: '2d-dev' <2d-...@openjdk.java.net>; Langer, Christoph
> > > 
> > > Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception
> in
> > > GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> > > SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
> > >
> > > A small update  -  I found a second  place  in WPrinterJob.cpp   where  
> > > the
> > > exception handling is missing. After fixing both places I can reenable
> > > warning 4297  in
> > > Awt2dLibraries.gmk  which has been  disabled before , probably
> because
> > of
> > > the warnings generated when the exceptions where not handled .
> > > Should I update the change with the other file + makefile change ?
> > >
> > > Best regards, Matthias
> > >
> > >
> > > >hg diff
> > > diff -r 12fe57c319e1 make/lib/Awt2dLibraries.gmk
> > > --- a/make/lib/Awt2dLibraries.gmk  Tue Apr 10 11:02:09 2018 +0800
> > > +++ b/make/lib/Awt2dLibraries.gmk  Mon Jun 04 09:18:03 2018 +0200
> > > @@ -213,6 +213,7 @@
> > >LIBAWT_CFLAGS += -fgcse-after-reload
> > >  endif
> > >
> > >
> > >  $(eval $(call SetupJdkLibrary, BUILD_LIBAWT, \
> > >  NAME := awt, \
> > >  SRC := $(LIBAWT_DIRS), \
> > > @@ -224,7 +225,7 @@
> > >  format-nonliteral parentheses, \
> > >  DISABLED_WARNINGS_clang := logical-op-parentheses extern-
> initializer,
> > \
> > >  DISABLED_WARNINGS_solstudio := E_DECLARATION_IN_CODE, \
> > > -DISABLED_WARNINGS_microsoft := 4297 4244 4267 4996, \
> > > +DISABLED_WARNINGS_microsoft := 4244 4267 4996, \
> > >  ASFLAGS := $(LIBAWT_ASFLAGS), \
> > >  LDFLAGS := $(LDFLAGS_JDKLIB) $(call SET_SHARED_LIBRARY_ORIGIN),
> \
> > >  LDFLAGS_macosx := -L$(INSTALL_LIBRARIES_HERE), \
> > > diff -r 12fe57c319e1
> > >
> >
> src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp
> > > ---
> > >
> >
> a/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> > > ppTue Apr 10 11:02:09 2018 +0800
> > > +++
> > >
> >
> b/src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.c
> > > ppMon Jun 04 09:18:03 2018 +0200
> > > @@ -85,7 +85,13 @@
> > >  *pNpoints = outpoints;
> > >  }
> > >  if (outpoints > POLYTEMPSIZE) {
> > > -pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > sizeof(POINT), outpoints);
> > > +try {
> > > +pPoints = (POINT *) SAFE_SIZE_ARRAY_ALLOC(safe_Malloc,
> > > sizeof(POINT), outpoints);
> > > +} catch (const std::bad_alloc&) {
> > > +return NULL;
> > > +}
> > >  }
> > >  BOOL isempty = fixend;
> > >  for (int i = 0; i < npoints; i++) {
> > > diff -r 12fe57c319e1
> > > src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > > ---
> a/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > > Tue Apr 10 11:02:09 2018 +0800
> > > +++
> > b/src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp
> > > Mon Jun 04 09:18:03 2018 +0200
> > > @@ -873,7 +873,12 @@
> > >int numSizes = ::DeviceCapabilities(printerName, printerPort,
> > >DC_PAPERS, NULL, 

RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1

[Ichiroh Takiguchi]

Hello Matthias and Christoph.
Thank you for your explanations.

I did not have enough knowledge about "visibility".

I created following patches.


diff -r 02934b0d661b 
src/java.base/share/native/libjimage/NativeImageBuffer.cpp
--- a/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Wed May 
30 14:46:28 2018 +0200
+++ b/src/java.base/share/native/libjimage/NativeImageBuffer.cpp	Tue Jun 
05 12:10:41 2018 +0900

@@ -39,7 +39,9 @@
 #include "imageFile.hpp"
 #include "inttypes.hpp"
 #include "jimage.hpp"
+#if !defined(_AIX)
 #include "osSupport.hpp"
+#endif

 #include "jdk_internal_jimage_NativeImageBuffer.h"

diff -r 02934b0d661b src/java.base/unix/native/include/jni_md.h
--- a/src/java.base/unix/native/include/jni_md.h	Wed May 30 14:46:28 
2018 +0200
+++ b/src/java.base/unix/native/include/jni_md.h	Tue Jun 05 12:10:41 
2018 +0900

@@ -29,7 +29,8 @@
 #ifndef __has_attribute
   #define __has_attribute(x) 0
 #endif
-#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && 
(__GNUC_MINOR__ > 2))) || __has_attribute(visibility)
+#if (defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4) && 
(__GNUC_MINOR__ > 2))) || __has_attribute(visibility) \

+|| (defined(_AIX) && (defined(__xlC__) && (__xlC__ >= 0xD01)))
   #ifdef ARM
 #define JNIEXPORT 
__attribute__((externally_visible,visibility("default")))
 #define JNIIMPORT 
__attribute__((externally_visible,visibility("default")))



If "osSupport.hpp" was included, XLC++ compiler complained.
I could not understand, which part was invalid...
I'm not sure, "osSupport.hpp" is really required on 
NativeImageBuffer.cpp or not...


I added __xlC__ macro to determine XLC/C++'s version# into jni_md.h. [1]
0xD01 means 13.1 by hexadecimal.

I checked symbol table by "dump -Tv -X64". [2]
It seemed it was fine, some symbols were hidden.

Does someone review my code?

[1] 
https://www.ibm.com/support/knowledgecenter/en/SSGH2K_13.1.3/com.ibm.xlc1313.aix.doc/compiler_ref/xlmacros.html
[2] 
https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/index.html


On 2018-06-01 21:12, Baesken, Matthias wrote:

Hi ,  my change  8202322   just  handled  the fact   that  the
visibility - flags   are not supported  with  xlc 12.1  ,  so  setting
them generated a TON of compile - time  warnings .

The introduction of   the  "-qvisibility=hidden"came with the
mapfile removal changes :

8200358: Remove mapfiles for JDK executables
http://hg.openjdk.java.net/jdk/jdk/rev/210cf224b690

8200178: Remove mapfiles for JDK native libraries
http://hg.openjdk.java.net/jdk/jdk/rev/396ea30afbd5

I guess it  might  need further  testing+adjustments  to make  the
"visibility hiding" work nicely   with XLC13  ,  but currently  we
build only with XLC12 .

As a workaround  you might want to  remove  the  "-qvisibility=hidden"
 setting for XLC 13 as well  ,  like I did  for XLC12 with  the change
  8202322   .


Best regards, Matthias





-Original Message-
From: Langer, Christoph
Sent: Freitag, 1. Juni 2018 10:57
To: Ichiroh Takiguchi 
Cc: Baesken, Matthias ; 'build-
d...@openjdk.java.net' ; ppc-aix-port-
d...@openjdk.java.net; core-libs-...@openjdk.java.net; Lindenmaier,
Goetz 
Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support 
on xlc 12.1


Hi Ichiroh,

we do not use the XLC 13 compiler on AIX yet here at SAP and I believe
nobody of my colleagues has played with it yet. So you are on a new
playground here 

However, I believe the idea in OpenJDK with the abolition of map files 
is that
symbols should be invisible externally unless they are declared 
exported,
e.g. JNIEXPORT. So I would think "-qvisibility=hidden" should be the 
correct

default and whatever JNIEXPORT expands to should contain the right
attributes to get that symbol visible.

Can you check if either my assumption is completely wrong, JNIEXPORT 
does
not expand to the right thing, XLC 13 has a bug or maybe just sume 
specific

required symbols are not declared correctly?

Best regards
Christoph

> -Original Message-
> From: Ichiroh Takiguchi [mailto:taki...@linux.vnet.ibm.com]
> Sent: Donnerstag, 31. Mai 2018 09:55
> To: Langer, Christoph 
> Cc: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' ; ppc-aix-port-
> d...@openjdk.java.net; core-libs-...@openjdk.java.net; Lindenmaier,
> Goetz 
> Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 
12.1
>
> Hello.
> 8202322 was integrated into jdk-11+15.
> I'm using XLC 13.1.3 on AIX 7.1.4.
> Build was failed because of "-qvisibility=hidden" on
> make/lib/LibCommon.gmk.
> According to "XL C/C++ for AIX 13.1.3" documentation [1],
> "-qvisibility=hidden" cannot create shared libraries entry points.
> For example, libverify.so was there, but entry points were not resolved
> by "-lverify" option.
> I think it should be "-qvisibility=default" (I tried, it worked)
> or "-qvisibility=protected" (I had not tried) ?
> I'm not 

Re: RFR: JDK-8202384: Introduce altserver jvm variant with speculative execution disabled

[David Holmes]

Sorry to be late to this party ...

On 5/06/2018 6:10 AM, Erik Joelsson wrote:

New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/

Renamed the new jvm variant to "hardened".


As it is a hardened server build I'd prefer if that were somehow 
reflected in the name. Though really I don't see why this should be 
restricted this way ... to be honest I don't see hardened as a variant 
of server vs. client vs. zero etc at all, you should be able to harden 
any of those.


So IIUC with this change we will:
- always build JDK native code "hardened" (if toolchain supports it)
- only build hotspot "hardened" if requested; and in that case
  - jvm.cfg will list -server and -hardened with server as default

Is that right? I can see that we may choose to always build Oracle JDK 
this way but it isn't clear to me that its suitable for OpenJDK. Nor why 
hotspot is selectable but JDK is not. ??


Sorry.

David
-


/Erik


On 2018-06-04 09:54, jesper.wilhelms...@oracle.com wrote:

On 4 Jun 2018, at 17:52, Erik Joelsson  wrote:

Hello,

On 2018-06-01 14:00, Aleksey Shipilev wrote:

On 06/01/2018 10:53 PM, Erik Joelsson wrote:
This patch defines flags for disabling speculative execution for 
GCC and Visual Studio and applies
them to all binaries except libjvm when available in the compiler. 
It defines a new jvm feature
no-speculative-cti, which is used to control whether to use the 
flags for libjvm. It also defines a
new jvm variant "altserver" which is the same as server, but with 
this new feature added.
I think the classic name for such product configuration is 
"hardened", no?

I don't know. I'm open to suggestions on naming.

"hardened" sounds good to me.

The change looks good as well.
/Jesper


/Erik

-Aleksey