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

[jesper . wilhelmsson]

Looks good to me.
/Jesper

> On 4 Jun 2018, at 22:10, Erik Joelsson  wrote:
> 
> New webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.02/
> 
> Renamed the new jvm variant to "hardened".
> 
> /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-8200132: Remove jre images and bundles

[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

[Bob Vandette]

> On Jun 4, 2018, at 4:32 PM, Jonathan Gibbons  
> wrote:
> 
> 
> 
> On 06/02/2018 12:20 AM, Alan Bateman wrote:
>> On 02/06/2018 08:05, Aleksey Shipilev wrote:
>>> :
>>> Unfortunately, in the age of containers, distribution size matters. It 
>>> makes the whole sense to ship
>>> JRE in Docker containers to provide the execution environment for the upper 
>>> layers. Remember, hardly
>>> any application is fully modularized and/or uses jlink/jimage way of 
>>> distribution.
>>> 
>>> Also, products that ship with their own OpenJDK distribution (e.g. 
>>> JetBrains IDEs) do ship with
>>> jres, which cuts down their distribution sizes.
>>> 
>>> Cost savings for having JRE only are significant, as can be observed with 
>>> current bundles:
>>> 
>>>  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
>>>   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz
>>> 
>>> Therefore, I believe removing jre is too disruptive, at least for 11, at 
>>> least until we see that the
>>> whole jlink/jimage thing really works out in the wider Java ecosystem and 
>>> JREs are really abandoned.
>> I don't disagree with the significance of what has been proposed here. 
>> However, just to point out that creating what used to know as the JRE is one 
>> `jlink` command. There is no requirement for the application or libraries 
>> using that run-time be developed as modules. Also incorporate generating of 
>> JDK run-time images into the build when working with containers is very 
>> useful as you get fine control on which modules to include.
>> 
>> -Alan
>> 
> 
> If it is that easy to generate a JRE image, why not provide a target to 
> create such an image, that invokes that one command?  The target need not be 
> part of the default build, but would be available for those that want to 
> build it.

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.

Bob.


> 
> -- Jon

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

[Jonathan Gibbons]

On 06/02/2018 12:20 AM, Alan Bateman wrote:

On 02/06/2018 08:05, Aleksey Shipilev wrote:

:
Unfortunately, in the age of containers, distribution size matters. 
It makes the whole sense to ship
JRE in Docker containers to provide the execution environment for the 
upper layers. Remember, hardly
any application is fully modularized and/or uses jlink/jimage way of 
distribution.


Also, products that ship with their own OpenJDK distribution (e.g. 
JetBrains IDEs) do ship with

jres, which cuts down their distribution sizes.

Cost savings for having JRE only are significant, as can be observed 
with current bundles:


  178M Jun  2 08:53 jdk-11-internal+0_linux-x64_bin.tar.gz
   38M Jun  2 08:53 jre-11-internal+0_linux-x64_bin.tar.gz

Therefore, I believe removing jre is too disruptive, at least for 11, 
at least until we see that the
whole jlink/jimage thing really works out in the wider Java ecosystem 
and JREs are really abandoned.
I don't disagree with the significance of what has been proposed here. 
However, just to point out that creating what used to know as the JRE 
is one `jlink` command. There is no requirement for the application or 
libraries using that run-time be developed as modules. Also 
incorporate generating of JDK run-time images into the build when 
working with containers is very useful as you get fine control on 
which modules to include.


-Alan



If it is that easy to generate a JRE image, why not provide a target to 
create such an image, that invokes that one command?  The target need 
not be part of the default build, but would be available for those that 
want to build it.


-- Jon

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

[Erik Joelsson]

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

Renamed the new jvm variant to "hardened".

/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-8200132: Remove jre images and bundles

[Alan Bateman]

On 04/06/2018 20:45, Bob Vandette wrote:
If we do this, shouldn’t we provide an aggregator module to allow 
developers to
easily create a Java runtime with the same list of modules?  AFAIK, 
this doesn’t exists.
The java.se  module is not the same.  It’s missing 
many modules.


That creates an attractive nuisance in that developers would end 
requiring it (with `requires) and it's not a "platform" or a module that 
someone should be depending on.  As I recall, that was part of the 
reason why the proposed "jdk.jre" aggregator was dropped during the JDK 
9 development. It may be something for the Packaging Tool (draft JEP 
JDK-8200758). I could imagine the build for the packaging tool 
generating a list of modules that the tool uses when creating packages 
for end-user applications.


-Alan

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

[Bob Vandette]

If we do this, shouldn’t we provide an aggregator module to allow developers to
easily create a Java runtime with the same list of modules?  AFAIK, this 
doesn’t exists.
The java.se  module is not the same.  It’s missing many 
modules.

Bob.


> On Jun 2, 2018, at 1:01 PM, Alan Bateman  wrote:
> 
> On 02/06/2018 15:07, Magnus Ihse Bursie wrote:
>> It is probably relatively trivial to add a configure option to select just 
>> the "JRE modules" when building, rather than all modules. If we add such an 
>> option, it would still be possible to build a traditional JRE, not just at 
>> the same time as building the full JDK. Doing Erik's change as suggested 
>> here, combined with such additional functionality would allow us to remove a 
>> lot of old cruft from the build system, while still allowing distributors to 
>> build a JRE. I'd recommend doing something like this, rather than to delay 
>> this patch to post-JDK11.
>> 
> Removing old cruft is good. Also not building the jre image by default might 
> reduce build times a little bit, a boon for those doing "make images" but 
> never using the jre image (as the tests are run on the jdk image, not the jre 
> image).
> 
> I don't have an opinion on whether configure option or a make target is the 
> right approach. It might be that those consuming the jre image today are 
> using the bundles target, a target that I wouldn't expect most developers 
> will use when working on OpenJDK. Part of the socializing of this topic might 
> be to get a better handle on what downstream projects and packagers are doing 
> with the jre image (beyond creating install bundles for specific distros).
> 
> -Alan

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

[Erik Joelsson]

Looks ok.

/Erik


On 2018-06-02 16:17, David Buck wrote:

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-8202384: Introduce altserver jvm variant with speculative execution disabled

[jesper . wilhelmsson]

> 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

[Erik Joelsson]

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.

/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

[Langer, Christoph]

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,
> > DC_PAPERS, papers, NULL) != -1) {
> >
> >
> >
> >
> >
> >
> > > -Original Message-
> > > From: Baesken, Matthias
> > > Sent: Freitag, 1. Juni 2018 14:18
> > > To: 'Thomas Stüfe' 
> > > Cc: 2d-dev <2d-...@openjdk.java.net>; Langer, Christoph
> > > 
> > > Subject: RE: RFR: JDK-8204211: 

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]

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,
> DC_PAPERS, papers, NULL) != -1) {
> 
> 
> 
> 
> 
> 
> > -Original Message-
> > From: Baesken, Matthias
> > Sent: Freitag, 1. Juni 2018 14:18
> > 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
> >
> > Hi  Thomas ,  using the  const-reference  sounds like a good idea  ( I just
> > copied from  other locations in  the source code where  (almost?)  always
> > std::bad_alloc& (non-const)  is caught .
> >
> > For example :
> >
> >
> > alloc.h 170 } catch (std::bad_alloc&) { \
> > 177 } catch (std::bad_alloc&) { \
> > 200 } catch (std::bad_alloc&) { \
> > 206 } catch (std::bad_alloc&) { \
> >
> >  awt_InputTextInfor.cpp 223 } catch (std::bad_alloc&) {
> > 247 } catch (std::bad_alloc&) {
> > 317 } catch (std::bad_alloc&) {
> > 372 } catch (std::bad_alloc&) {
> > 407 } catch 

Re: RFR: 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

[Per Liden]

Hi Magnus,

Thanks for reviewing.

On 06/04/2018 01:20 PM, Magnus Ihse Bursie wrote:

Hi Per,

Please always include build-dev when proposing build changes.

The changes in make/autoconf/hotspot.m4 looks a bit suspect. Since you 
are adding zgc to disabled jvm features, which always override enabled 
features, it will never be possible to enable zgc on any other platform.
Is this intentional? Otherwise, I suggest instead adding zgc to the 
baseline set NON_MINIMAL_FEATURES for linux-x64.




Yes, that's intentional, since ZGC is only supported on linux-x64 and 
enabling ZGC on other platforms wouldn't build. When additional 
platforms gets supported, this check would of course also be updated to 
reflect that.


cheers,
Per


/Magnus



On 2018-06-01 23:41, Per Liden wrote:

Hi,

Please review the implementation of JEP 333: ZGC: A Scalable 
Low-Latency Garbage Collector (Experimental)


Please see the JEP for more information about the project. The JEP is 
currently in state "Proposed to Target" for JDK 11.


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

Additional information in can also be found on the ZGC project wiki.

https://wiki.openjdk.java.net/display/zgc/Main


Webrevs
---

To make this easier to review, we've divided the change into two webrevs.

* ZGC Master: http://cr.openjdk.java.net/~pliden/8204210/webrev.0-master

  This patch contains the actual ZGC implementation, the new unit 
tests and other changes needed in HotSpot.


* ZGC Testing: 
http://cr.openjdk.java.net/~pliden/8204210/webrev.0-testing


  This patch contains changes to existing tests needed by ZGC.


Overview of Changes
---

Below follows a list of the files we add/modify in the master patch, 
with a short summary describing each group.


* Build support - Making ZGC an optional feature.

  make/autoconf/hotspot.m4
  make/hotspot/lib/JvmFeatures.gmk
  src/hotspot/share/utilities/macros.hpp

* C2 AD file - Additions needed to generate ZGC load barriers (adlc 
does not currently offer a way to easily break this out).


  src/hotspot/cpu/x86/x86.ad
  src/hotspot/cpu/x86/x86_64.ad

* C2 - Things that can't be easily abstracted out into ZGC specific 
code, most of which is guarded behind a #if INCLUDE_ZGC and/or if 
(UseZGC) condition. There should only be two logic changes (one in 
idealKit.cpp and one in node.cpp) that are still active when ZGC is 
disabled. We believe these are low risk changes and should not 
introduce any real change i behavior when using other GCs.


  src/hotspot/share/adlc/formssel.cpp
  src/hotspot/share/opto/*
  src/hotspot/share/compiler/compilerDirectives.hpp

* General GC+Runtime - Registering ZGC as a collector.

  src/hotspot/share/gc/shared/*
  src/hotspot/share/runtime/vmStructs.cpp
  src/hotspot/share/runtime/vm_operations.hpp
  src/hotspot/share/prims/whitebox.cpp

* GC thread local data - Increasing the size of data area by 32 bytes.

  src/hotspot/share/gc/shared/gcThreadLocalData.hpp

* ZGC - The collector itself.

  src/hotspot/share/gc/z/*
  src/hotspot/cpu/x86/gc/z/*
  src/hotspot/os_cpu/linux_x86/gc/z/*
  test/hotspot/gtest/gc/z/*

* JFR - Adding new event types.

  src/hotspot/share/jfr/*
  src/jdk.jfr/share/conf/jfr/*

* Logging - Adding new log tags.

  src/hotspot/share/logging/*

* Metaspace - Adding a friend declaration.

  src/hotspot/share/memory/metaspace.hpp

* InstanceRefKlass - Adjustments for concurrent reference processing.

  src/hotspot/share/oops/instanceRefKlass.inline.hpp

* vmSymbol - Disabled clone intrinsic for ZGC.

  src/hotspot/share/classfile/vmSymbols.cpp

* Oop Verification - In four cases we disabled oop verification 
because it do not makes sense or is not applicable to a GC using load 
barriers.


  src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
  src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
  src/hotspot/share/compiler/oopMap.cpp
  src/hotspot/share/runtime/jniHandles.cpp

* StackValue - Apply a load barrier in case of OSR. This is a bit of a 
hack. However, this will go away in the future, when we have the next 
iteration of C2's load barriers in place (aka "C2 late barrier 
insertion").


  src/hotspot/share/runtime/stackValue.cpp

* JVMTI - Adding an assert() to catch problems if the tagmap hashing 
is changed in the future.


  src/hotspot/share/prims/jvmtiTagMap.cpp

* Legal - Adding copyright/license for 3rd party hash function used in 
ZHash.


  src/java.base/share/legal/c-libutl.md

* SA - Adding basic ZGC support.

  src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/*


Testing
---

* Unit testing

  A number of new ZGC specific gtests have been added, in 
test/hotspot/gtest/gc/z/


* Regression testing

  No new failures in Mach5, with ZGC enabled, tier{1,2,3,4,5,6}
  No new failures in Mach5, with ZGC disabled, tier{1,2,3}

* Stress testing

  We have been continuously been running a number stress tests 
throughout the development, these include:


    specjbb2000
    specjbb2005
    specjbb2015
    specjvm98
    

Re: RFR: 8204210: Implementation: JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)

[Magnus Ihse Bursie]

Hi Per,

Please always include build-dev when proposing build changes.

The changes in make/autoconf/hotspot.m4 looks a bit suspect. Since you 
are adding zgc to disabled jvm features, which always override enabled 
features, it will never be possible to enable zgc on any other platform. 
Is this intentional? Otherwise, I suggest instead adding zgc to the 
baseline set NON_MINIMAL_FEATURES for linux-x64.


/Magnus



On 2018-06-01 23:41, Per Liden wrote:

Hi,

Please review the implementation of JEP 333: ZGC: A Scalable 
Low-Latency Garbage Collector (Experimental)


Please see the JEP for more information about the project. The JEP is 
currently in state "Proposed to Target" for JDK 11.


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

Additional information in can also be found on the ZGC project wiki.

https://wiki.openjdk.java.net/display/zgc/Main


Webrevs
---

To make this easier to review, we've divided the change into two webrevs.

* ZGC Master: http://cr.openjdk.java.net/~pliden/8204210/webrev.0-master

  This patch contains the actual ZGC implementation, the new unit 
tests and other changes needed in HotSpot.


* ZGC Testing: 
http://cr.openjdk.java.net/~pliden/8204210/webrev.0-testing


  This patch contains changes to existing tests needed by ZGC.


Overview of Changes
---

Below follows a list of the files we add/modify in the master patch, 
with a short summary describing each group.


* Build support - Making ZGC an optional feature.

  make/autoconf/hotspot.m4
  make/hotspot/lib/JvmFeatures.gmk
  src/hotspot/share/utilities/macros.hpp

* C2 AD file - Additions needed to generate ZGC load barriers (adlc 
does not currently offer a way to easily break this out).


  src/hotspot/cpu/x86/x86.ad
  src/hotspot/cpu/x86/x86_64.ad

* C2 - Things that can't be easily abstracted out into ZGC specific 
code, most of which is guarded behind a #if INCLUDE_ZGC and/or if 
(UseZGC) condition. There should only be two logic changes (one in 
idealKit.cpp and one in node.cpp) that are still active when ZGC is 
disabled. We believe these are low risk changes and should not 
introduce any real change i behavior when using other GCs.


  src/hotspot/share/adlc/formssel.cpp
  src/hotspot/share/opto/*
  src/hotspot/share/compiler/compilerDirectives.hpp

* General GC+Runtime - Registering ZGC as a collector.

  src/hotspot/share/gc/shared/*
  src/hotspot/share/runtime/vmStructs.cpp
  src/hotspot/share/runtime/vm_operations.hpp
  src/hotspot/share/prims/whitebox.cpp

* GC thread local data - Increasing the size of data area by 32 bytes.

  src/hotspot/share/gc/shared/gcThreadLocalData.hpp

* ZGC - The collector itself.

  src/hotspot/share/gc/z/*
  src/hotspot/cpu/x86/gc/z/*
  src/hotspot/os_cpu/linux_x86/gc/z/*
  test/hotspot/gtest/gc/z/*

* JFR - Adding new event types.

  src/hotspot/share/jfr/*
  src/jdk.jfr/share/conf/jfr/*

* Logging - Adding new log tags.

  src/hotspot/share/logging/*

* Metaspace - Adding a friend declaration.

  src/hotspot/share/memory/metaspace.hpp

* InstanceRefKlass - Adjustments for concurrent reference processing.

  src/hotspot/share/oops/instanceRefKlass.inline.hpp

* vmSymbol - Disabled clone intrinsic for ZGC.

  src/hotspot/share/classfile/vmSymbols.cpp

* Oop Verification - In four cases we disabled oop verification 
because it do not makes sense or is not applicable to a GC using load 
barriers.


  src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
  src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
  src/hotspot/share/compiler/oopMap.cpp
  src/hotspot/share/runtime/jniHandles.cpp

* StackValue - Apply a load barrier in case of OSR. This is a bit of a 
hack. However, this will go away in the future, when we have the next 
iteration of C2's load barriers in place (aka "C2 late barrier 
insertion").


  src/hotspot/share/runtime/stackValue.cpp

* JVMTI - Adding an assert() to catch problems if the tagmap hashing 
is changed in the future.


  src/hotspot/share/prims/jvmtiTagMap.cpp

* Legal - Adding copyright/license for 3rd party hash function used in 
ZHash.


  src/java.base/share/legal/c-libutl.md

* SA - Adding basic ZGC support.

  src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/*


Testing
---

* Unit testing

  A number of new ZGC specific gtests have been added, in 
test/hotspot/gtest/gc/z/


* Regression testing

  No new failures in Mach5, with ZGC enabled, tier{1,2,3,4,5,6}
  No new failures in Mach5, with ZGC disabled, tier{1,2,3}

* Stress testing

  We have been continuously been running a number stress tests 
throughout the development, these include:


specjbb2000
specjbb2005
specjbb2015
specjvm98
specjvm2008
dacapo2009
test/hotspot/jtreg/gc/stress/gcold
test/hotspot/jtreg/gc/stress/systemgc
test/hotspot/jtreg/gc/stress/gclocker
test/hotspot/jtreg/gc/stress/gcbasher
test/hotspot/jtreg/gc/stress/finalizer
Kitchensink


Thanks!

/Per, Stefan & the ZGC team