RE: VS2017 build errors jdk/jdk

[Baesken, Matthias]

Hi Alan, thanks for the info .
Casting to void* first also makes the compile issue go away :

freeze_entry = (address)(void*)freeze;

// If we wanted, we could templatize by kind and have three different thaw 
entries
thaw_entry = (address)(void*)thaw;


>So maybe it time to look at it, it might be easier to have a smaller set 
>of VS releases to support.

On the other hand,  having VS2017 for JDK11 - head  is rather nice for  
backporting .

Best regards, Matthias



-Original Message-
From: Alan Bateman  
Sent: Tuesday, 10 May 2022 13:16
To: Baesken, Matthias ; 'build-dev@openjdk.java.net' 

Cc: Zeller, Arno 
Subject: Re: VS2017 build errors jdk/jdk

On 10/05/2022 09:29, Baesken, Matthias wrote:
> Hello, it seems jdk/jdk does not build any more with VS2017.
> Should we still support this compiler ?
>
> For the error see :
>
> https://bugs.openjdk.java.net/browse/JDK-8286459
> 8286459: compile error with VS2017 in continuationFreezeThaw.cpp
>
In Oracle, we moved from using VS2019 16.9.3 to VS2022 17.1.0 a few 
months ago.

I checked the Microsoft site to get the status of VS2017. It says that 
the "Mainstream End Date" for that release was April 2022 so I guess 
it's not easy to get updates without extended support now.

So maybe it time to look at it, it might be easier to have a smaller set 
of VS releases to support.

-Alan

RE: configure misses check for linux-glibc-devel / linux-headers / kernel-headers ?

[Baesken, Matthias]

Hi Aleksey I did not use a devkit,  just installed gcc/g++  on the Alpine 
docker image I  used .
Maybe that's why I do not see this help output you added  ?

Best regards, Matthias

>> Hi , while attempting to build jdk on an Alpine Linux I was running into the 
>> following issue :
>> After some additional package installations  configure  was passing 
>> successfully , however hotspot build failed with
>> 
>> /openjdk_build/jdk_1/jdk/src/hotspot/os/linux/os_linux.cpp:109:11: fatal 
>> error: linux/elf-em.h: No such file or directory
>>109 | # include 
>
> Mhm. When I was doing the Alpine hints, it failed on devkit checks, 
> suggesting to install 
> linux-headers there:
> 
> https://github.com/openjdk/jdk/commit/a30aa52b77931bcea38213cf3d243d18a37dc858#diff-187e9e1165cff171d9373b1877f4e155746ec1a5fc2684cc103be8153beee4efR200
>
> We should probably look into why this devkit check did not work for you?

RE: Heads up: planned Harfbuzz update in jdk11u-dev

[Baesken, Matthias]

Hi Andrew , it would follow what Oracle did in 11.0.13-oracle  and what Azul 
did successfully in 13.0.10
 please see  https://bugs.openjdk.java.net/browse/JDK-8261169  , those are all  
older / established releases .

>If people want a newer HarfBuzz, they can use --with-harfbuzz=system
> or upgrade to a newer JDK.

Unfortunately at least on the Linux distros I checked , the  system-installed 
harfbuzz would be older , not newer (at least on SLES where I checked).
Might be different on other distros however ...

Best regards, Matthias


-Original Message-
From: Andrew Hughes  
Sent: Montag, 17. Januar 2022 01:31
To: Baesken, Matthias 
Cc: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net' 
; Andrew Brygin ; Yuri Nesterenko 
; Zeller, Arno 
Subject: Re: Heads up: planned Harfbuzz update in jdk11u-dev

* PGP Signed by an unknown key

On 09:19 Fri 14 Jan , Baesken, Matthias wrote:
> For one of the next jdk11 updates, an update to a more recent harfbuzz 
> version is planned.
> This has been done already in jdk/jdk some time ago, and was backported 
> recently to jdk13,
> please see the harfbuzz 2.7.2 / 2.8.0 related changes done in jdk13 :
> 
> https://github.com/openjdk/jdk13u-dev/commit/e183f2d3650b6275a59d0cdd7303ca22f2ae088a
> https://github.com/openjdk/jdk13u-dev/commit/64627b5061fdd15ed52e3858cb52bb6b3b2b020b
> https://github.com/openjdk/jdk13u-dev/commit/c42c231e1dabd37ec09362291dc8141117ce0bbd
> 
> However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they are 
> built with option -std=c++11).
> So please check that
> 
> a) your toolchain supports -std=c++11 or you have the option to update your 
> toolchain to a more recent version
> 
> 
> or as a workaround
> 
> b) check the -with-harfbuzz=system option to use another precompiled harfbuzz 
> version from your system
> 
> Best regards, Matthias
> 

Why?

11u is a stable release. I don't think it is appropriate to break
existing build setups on a 3+ year old JDK.

If people want a newer HarfBuzz, they can use --with-harfbuzz=system
or upgrade to a newer JDK.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

* Unknown Key
* 0x35964222

RE: Xcode version output when devkit is used

[Baesken, Matthias]

>It sounds like a bug that should get fixed. :)
>
>Let me just verify that I understand this correctly. Your specified 
>devkit is used to actually compile the JDK, it's just in the configure 
>script output that things look wrong? (I suspect this will also mess up 
>version checking for clang in the makefiles. Thankfully, that kind of 
>checking is rare.)


Hi Magnus, from what I see in the build log,  the correct clang / clang++ 
compilers (and related tools) are taken from the 13.1  devkit .

Best regards, Matthias

Building OpenJDK with Xcode12 devkits on older macOS

[Baesken, Matthias]

Hello, I noticed the following when building jdk  on  macOS 10.14 with xcode12 
devkit .
The tool  "xcodebuild"   which  is used at some places in the configure process 
(see basic.m4 / toolchain.m4) fails because of the too old macOS :

configure:70788: xcodebuild output: dyld: Library not loaded: 
/System/Library/Frameworks/Combine.framework/Versions/A/Combine
configure:70790: error: Failed to determine Xcode version.

But when I rename/remove the xcodebuild  from the devkit, the builds work 
perfectly fine (because the compilers do not have these deps to 
Combine.framework).
So I wonder - is there a "nicer"  way to achieve this without renaming/removing 
the xcodebuild  tool from the devkit (e.g. by setting other configure options 
or env variables) ?


Thanks, Matthias

RE: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Baesken, Matthias]

> Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m.

Hi Paul, did that :

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

https://github.com/openjdk/jdk/pull/403

Best regards, Matthias


-Original Message-
From: Hohensee, Paul  
Sent: Dienstag, 29. September 2020 15:46
To: Kim Barrett ; Matthias Baesken 

Cc: 2d-...@openjdk.java.net; awt-...@openjdk.java.net; 
build-dev@openjdk.java.net; hotspot-...@openjdk.java.net
Subject: RE: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m.

Thanks,
Paul

On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" 
 wrote:

> On Sep 29, 2020, at 3:14 AM, Matthias Baesken  
wrote:
>
> On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett  
wrote:
>
>>> Please review this small patch to enable the OSX build using Xcode 12.0.
>>>
>>> Thanks,
>>> Paul
>>
>> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129:
>>
>>> 127: NSColor* result = nil;
>>> 128:
>>> 129: if (colorIndex < ((useAppleColor) ? 
sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS :
>>> java_awt_SystemColor_NUM_COLORS)) {
>>
>> This looks like a plain old bug fix, nothing really to do with the 
compiler upgrade.  The new compiler presumably just
>> has a new warning that brought attention to the problem.  As such, I 
don't think it belongs in a PR that's about issues
>> related to the compiler upgrade.  Someone might want to backport just 
this fix, for example.
>
> Hello  Kim, Paul -  so should we open a separate bug for the
> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue 
because it might be a general  problem just
> uncovered by the new compiler ? Paul , do you want to do this ? Or should 
I open a bug and post a separate change for
> the useAppleColor check in CSystemColors.m ?

I think so.

>
> -
>
> PR: https://git.openjdk.java.net/jdk/pull/348

RE: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS

[Baesken, Matthias]

>
>Should we make the change to determine just before it is needed (e.g. VM.info 
>or hs_err log) at first?
>It is out of scope of this change, so I want to work as another issue if it is 
>needed.
>

Hi , 
I think we better do not call into WMI , when  writing an hs_err file   .


Best regards, Matthias



-Original Message-
From: Yasumasa Suenaga  
Sent: Donnerstag, 13. August 2020 06:15
To: David Holmes ; Baesken, Matthias 
; hotspot-runtime-...@openjdk.java.net; 
build-dev@openjdk.java.net
Cc: Doerr, Martin 
Subject: Re: PING: RFR: 8250598: Hyper-V is detected in spite of running on 
host OS

On 2020/08/13 11:54, David Holmes wrote:
> On 13/08/2020 11:12 am, Yasumasa Suenaga wrote:
>> Hi Matthias, David,
>>
>> I measured startup benchmarks with `Measure-Command 
>> {.\jdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe 
>> --version}` on PowerShell.
>>
>> * PC: Ryzen 3 3300X, 16GB memory
>> * OS: Windows 10 x64 (May 2020 Update)
>> * Java: jdk/jdk revision 60537
>>  (Compiled by VS 2019 (16.7.0))
>>
>> * without patch
>> TotalMilliseconds : 70.2124
>> TotalMilliseconds : 64.4465
>> TotalMilliseconds : 59.0854
>> TotalMilliseconds : 68.0255
>> TotalMilliseconds : 72.6467
>> average : 66.8833
>>
>> * with webrev.01
>> TotalMilliseconds : 81.7185
>> TotalMilliseconds : 68.539
>> TotalMilliseconds : 85.7226
>> TotalMilliseconds : 72.6584
>> TotalMilliseconds : 75.6091
>> average : 76.84952
>>
>> Overhead of WMI seems to be +10ms in this case.
> 
> Which is nearly 15%! Sorry but I just know Claes will be very unhappy if this 
> were to go in as-is.

Should we make the change to determine just before it is needed (e.g. VM.info 
or hs_err log) at first?
It is out of scope of this change, so I want to work as another issue if it is 
needed.


Yasumasa


> David
> -
> 
>>
>> Yasumasa
>>
>>
>> On 2020/08/13 0:05, Baesken, Matthias wrote:
>>>> I understand that if the process runs on Xen on other hypervisor (e.g. 
>>>> KVM), information for Xen would be set between 0x4100 and 0x4001.
>>>> Ok, I will not remove the loop in new webrev, and will add comment about 
>>>> it.
>>>
>>> Hi Yasumasa  , thanks !
>>>
>>> Regarding the WMI overhead , if you could  get some more info on this it 
>>> would be better to judge if it is perfectly okay or  concerning .
>>>
>>> (I remember that I looked into it a couple of years ago , but decided not 
>>> to use it in early VM startup ;  but have to confess this was just based on 
>>> a "gut feeling",
>>>   No micro benchmarks  )
>>>
>>> Best regards, Matthias
>>>
>>>

RE: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS

[Baesken, Matthias]

>I understand that if the process runs on Xen on other hypervisor (e.g. KVM), 
>information for Xen would be set between 0x4100 and 0x4001.
>Ok, I will not remove the loop in new webrev, and will add comment about it.

Hi Yasumasa  , thanks !

Regarding the WMI overhead , if you could  get some more info on this it would 
be better to judge if it is perfectly okay or  concerning .

(I remember that I looked into it a couple of years ago , but decided not to 
use it in early VM startup ;  but have to confess this was just based on a "gut 
feeling",
 No micro benchmarks  )

Best regards, Matthias

RE: PING: RFR: 8250598: Hyper-V is detected in spite of running on host OS

[Baesken, Matthias]

Hi Yasumasa ,  I'm more or less fine with the change .
But still not fully convinced  that removing  the iteration is a good thing .

http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html

1827   for (base = 0x4000; base < 0x4001; base += 0x100) {
1828 check_virt_cpuid(base, registers);

I think just checking  "0x4000" should work in most cases but if I remember 
correctly sometimes it was not enough .
See also  some references about Xen/KVM :

https://lists.linuxfoundation.org/pipermail/virtualization/2012-May/019974.html

"If compat mode for another h/v is enabled then those leaves will appear
at 0x4000 and Xen's will be bumped up, so a fully Xen aware set of
drivers (or detection routine, etc) should check at 0x100 intervals
until 0x4001 " 

and 

https://lore.kernel.org/patchwork/patch/394371/



And not so happy about the WMI  usage (called in early JVM startup) :

http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/os_cpu/windows_x86/vm_version_windows_x86.cpp.frames.html

bool VM_Version::is_in_VM() { ... }
 ...
}

 But if noone else complains about it, I guess it's okay .


Best regards, Matthias


>PING: Could you review this change?
>
>   JBS: https://bugs.openjdk.java.net/browse/JDK-8250598
>   webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/
>
>Build change has been reviewed by Erik.
>

RE: RFR [XS]: 8248334: hs build errors on ppc64 and s390x platforms

[Baesken, Matthias]

HI David and Martin,  thanks for the reviews !


>
>Hi Matthias,
>
>Looks good. Thanks for fixing it.
>
>Best regards,
>Martin
>> 
>> Hi Matthias,
>> 
>> That all seems fine to me.
>> 
>> David
>> 

RFR [XS]: 8248334: hs build errors on ppc64 and s390x platforms

[Baesken, Matthias]

Hello, please review this small  patch  that fixes the  ppc64(le) and s390x  
builds .
( They started to break since the 24th June,  looks like some inclusions  were  
 missing after recent  HS changes )


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

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


Thanks, Matthias

RE: RFR(XS): 8244756: Build broken with some awk version after JDK-8244248

[Baesken, Matthias]

Reviewed !

Best regards, Matthias

>thank you for proposing a fix which allows building with old awk on AIX. Works 
>fine.
>
>Here's the webrev:
>http://cr.openjdk.java.net/~mdoerr/8244756_AIX_fix_awk_expr/webrev.00/
>

RE: RFR: 8241996: on linux set full relro in the linker flags

[Baesken, Matthias]

Thanks for the review !

-Original Message-
From: Erik Joelsson  
Sent: Donnerstag, 2. April 2020 15:31
To: Baesken, Matthias ; 
'hotspot-...@openjdk.java.net' ; 
'build-dev@openjdk.java.net' 
Subject: Re: RFR: 8241996: on linux set full relro in the linker flags

Looks good to me.

/Erik

On 2020-04-02 00:41, Baesken, Matthias wrote:
> Hi Erik, that's a good point .
> New webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8241996.1/
>
>
> Best regards, Matthias
>
>
>> Hello Matthias,
>>
>> We are currently setting -z now for slowdebug builds. That should be
>> removed if it's now set by default for all configs.
>

RE: RFR: 8241996: on linux set full relro in the linker flags

[Baesken, Matthias]

Hi Erik, that's a good point .
New webrev :

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


Best regards, Matthias


> Hello Matthias,
>
> We are currently setting -z now for slowdebug builds. That should be 
> removed if it's now set by default for all configs.

RFR: 8241996: on linux set full relro in the linker flags

[Baesken, Matthias]

Hello, please review this binary hardening related change.

To improve binary hardening, we should enable full relro in the OpenJDK builds. 
Currently
our build settings enable only partial relro (they miss z,now).
See 
https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro

"Both partial and full RELRO reorder the ELF internal data sections to protect 
them from being overwritten in the event of a buffer-overflow,
but only full RELRO mitigates the above mentioned popular technique of 
overwriting the GOT entry to get control of program execution."

See also :
https://wiki.debian.org/Hardening

Some documentations/blogs mention slight performance impact of full relro (for 
startup performance) .

My quick checks on an example Linux server show not much impact (checked on 
linux x86_64) .
1)time on a   java HelloWorld  varies   (for both a patched and  unpatched  
JDK)between 0,6 and 0,7 seconds  ;
2) perf - runs on a java HelloWorld   show  a bit less  cycles (not clear why) 
but more  instructions :


> "normal  JVM" :

> 185,085,660  cycles#2.424 GHz 
>  ( +-  0.54% )  (83.18%)

> 128,415,594  stalled-cycles-frontend   #   69.38% frontend cycles 
> idle ( +-  0.80% )  (80.98%)

>  84,990,433  stalled-cycles-backend#   45.92% backend  cycles 
> idle ( +-  1.78% )  (65.38%)

> 102,950,894  instructions  #0.56  insns per cycle

>#1.25  stalled cycles 
> per insn  ( +-  1.48% )  (86.90%)

>

> Changed JVM with z,now  set :

>

> 182,514,813  cycles#2.394 GHz 
>  ( +-  0.58% )  (80.14%)

> 126,879,112  stalled-cycles-frontend   #   69.52% frontend cycles 
> idle ( +-  0.81% )  (81.24%)

>  82,691,295  stalled-cycles-backend#   45.31% backend  cycles 
> idle ( +-  1.72% )  (69.16%)

> 103,958,399  instructions  #0.57  insns per cycle

>#1.22  stalled cycles 
> per insn  ( +-  1.21% )  (89.47%)


Bug/webrev :

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

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


Best regards, Matthias

RFR [jdk11]: 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3

[Baesken, Matthias]

Hello, please review this small downport of  8201349 .
Reason is that we run into  warnings as errors, when building  jdk11 on Linux 
with gcc-7.X  and  with-zlib=bundled .
This adds  the  compiler options

-Wno-unused-function -Wno-implicit-fallthrough

To some compilations e.g. zlib-files   ; these 2 flags are at least supported 
with gcc-4.7 , gcc-4.8 ,gcc-7 and gcc-8 .



Bug :

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

jdk/jdk webrev :

https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084


adjusted Jdk11 webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8201349.0_jdk11/


Thanks, Matthias

jdk11 LIBZIP build and 8201349: build broken when configured with --with-zlib=bundled on gcc 7.3

[Baesken, Matthias]

Hello,  we were running into  build errors  recently  when using gcc-7   and  
with-zlib=bundledin jdk11u-dev .
This combination worked nicely in jdk/jdk .

Reason is that in jdk11 we do not have :

8201349: build broken when configured with --with-zlib=bundled on gcc 7.3

https://hg.openjdk.java.net/jdk/jdk/rev/c35eac313084

which unfortunately has a predecessor

8211029: Have a common set of enabled warnings for all native libraries

https://hg.openjdk.java.net/jdk/jdk/rev/ec62d6cab037


I'd like to have   the  gcc - warning disablements for   LIBJLI  / LIBZIP ,  
but taking over the large patch   8211029to  11   looks a bit too much .

Should I just post a separate patch  for jdk11u-dev  with the gcc warning 
disablements  for  LIBJLI / LIBZIP :

DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \


? This fixes our build issues and sounds reasonable and small .

Thanks, Matthias

Re: Is anyone still building multiple JVMs?

[Baesken, Matthias]

Hello,   in the combination minimal+server ,   you can jlink   smaller  target 
images using  "minimal"  because of the much smaller libjvm.so .
Just an example , target image size is sometimes important too .

Best regards, Matthias


> I am just wondering, what are the practical reasons for including two
> libjvms in the same JDK?
>
> We had server/client VMs in the past so we can use the same JDK for
> running "throughput" jobs vs "desktop/interactive" jobs. But that's no
> longer needed with advances in tier compilation, etc.
>
> Thanks
> - Ioi
>

RE: Is anyone still building multiple JVMs?

[Baesken, Matthias]

> run a separate task with "configure --with-jvm-variants=minimal &&
> make hotspot".

Hello,   this would , as far as I know, not produce  the same result  jdk  
image  with both  minimal+server  libjvm in the image .
So the proposed change sounds a bit like a  workaround, but  not a real 
replacement to what we have currently .

Best Regards, Matthias


> 
> On 2020-02-19 16:59, Baesken, Matthias wrote:
> > Hi Magnus,  yes we do.  We build (on Linux only currently)   "--with-jvm-
> variants=minimal,server"   in our central builds to test that  minimal is 
> still
> working  and that is was not destroyed by recent changes .
> >
> > Best Regards, Matthias
> Is this just to test that minimal is working? If so, you could just as
> well run a separate task with "configure --with-jvm-variants=minimal &&
> make hotspot". Unless you are actually shipping this configuration, that
> does not seem like a solid reason for keeping this functionality in the
> build.
> 
> /Magnus

RE: Is anyone still building multiple JVMs?

[Baesken, Matthias]

Hi Magnus,  yes we do.  We build (on Linux only currently)   
"--with-jvm-variants=minimal,server"   in our central builds to test that  
minimal is still working  and that is was not destroyed by recent changes .

Best Regards, Matthias


> 
> Message: 2
> Date: Wed, 19 Feb 2020 13:26:35 +0100
> From: Magnus Ihse Bursie 
> To: build-dev@openjdk.java.net
> Subject: Is anyone still building multiple JVMs?
> Message-ID: <3916a515-d67f-4f20-b149-a50408e13...@oracle.com>
> Content-Type: text/plain; charset=utf-8
> 
> Are there still any realistic scenarios where anyone builds multiple variants 
> of
> Hotspot in the same configuration?
> 
> This was basically introduced for 32-bit builds, where both the server and the
> client variant of Hotspot were built. In Oracle at least, we stopped building
> multiple JVM variants a long time ago.
> 
> Since the build system is taxed with convoluted logic in places just to 
> support
> this, I?d prefer to remove it if it is not used anymore. So, is there anyone 
> out
> there, still doing this?
> 
> /Magnus
> 

RE: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

> > Hello , please review  the downport of   "8234525: enable link-time section-
> gc for linux s390x to remove unused code"   to jdk11 .
> >
> > My change from jdk/jdk  did not apply directly and I had to adjust it 
> > slightly .
> >
> >
> >
> >
> > Bug  and  jdk/jdk change :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8234525
> > https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd
> >
> >
> > Adjusted change for jdk11u-dev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/
> >
> >
> > Original review thread :
> >
> > https://mail.openjdk.java.net/pipermail/build-dev/2019-
> November/026326.html
> >
> >
> > Thanks, Matthias
> >
> 
> In the original patch, the lines are added after
> TOOLCHAIN_CFLAGS_JDK_CONLY. In the 11u version, they seem to have
> needlessly moved above it.
> 
> Otherwise, looks good.
> 
> Regarding the patch itself, are these flags only useful when the s390x
> port is present or would they be advantageous on older versions where
> s390x is still using the Zero assembler port?
> 


Hello Andrew, thanks for the review .
I did not check the zero based ports .
However as long as  gcc and ld  support  the flags used , it should work  with 
zero too .

Best regards, Matthias

RE: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Ping - any reviews ?

Thanks, Matthias

From: Baesken, Matthias
Sent: Dienstag, 11. Februar 2020 10:24
To: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net' 

Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to 
remove unused code

Hello , please review  the downport of   "8234525: enable link-time section-gc 
for linux s390x to remove unused code"   to jdk11 .

My change from jdk/jdk  did not apply directly and I had to adjust it slightly .




Bug  and  jdk/jdk change :

https://bugs.openjdk.java.net/browse/JDK-8234525
https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd


Adjusted change for jdk11u-dev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/


Original review thread :

https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html


Thanks, Matthias

RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hello , please review  the downport of   "8234525: enable link-time section-gc 
for linux s390x to remove unused code"   to jdk11 .

My change from jdk/jdk  did not apply directly and I had to adjust it slightly .




Bug  and  jdk/jdk change :

https://bugs.openjdk.java.net/browse/JDK-8234525
https://hg.openjdk.java.net/jdk/jdk/rev/c04fa10636fd


Adjusted change for jdk11u-dev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8234525.0_jdk11/


Original review thread :

https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026326.html


Thanks, Matthias

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

so without this, nothing
> > will change.
> >
> I think it needs to be a separate option as it's all orthogonal to the
> main debug symbols file creation.
> > * The code need to make sure to separate stripped.pdb and normal pdb
> > files, when enabled.
> >
> > * And there must not be a heavy penalty in added code complexity.
> >
> /Erik
> > /Magnus
> >
> >> Thanks
> >> Christoph
> >>
> >>> -Original Message-
> >>> From: build-dev  On Behalf Of
> Erik
> >>> Joelsson
> >>> Sent: Donnerstag, 23. Januar 2020 18:49
> >>> To: Baesken, Matthias; David Holmes
> >>> ; 'build-dev@openjdk.java.net'  >>> d...@openjdk.java.net>; 'hotspot-...@openjdk.java.net'  >>> d...@openjdk.java.net>
> >>> Subject: Re: RFR: 8237192: Generate stripped/public pdbs on Windows
> for
> >>> jdk images
> >>>
> >>>
> >>> On 2020-01-23 00:03, Baesken, Matthias wrote:
> >>>> Hi Erik,  yes true sorry for answering  your comments a bit late .
> >>>>
> >>>>> If a user runs jlink and includes all the jmods we ship with the JDK, 
> >>>>> the
> >>> result
> >>>>> should be essentially equivalent to the original JDK image. The way
> the
> >>>>> stripped pdb files are included in the bundles sort of at the last
> >>>>> second of the build here breaks this property.
> >>>> I think we should address this in a separate bug/CR .
> >>> Maybe. I realize that my proposal below is quite a big task. But on the
> >>> other hand, I don't think breaking the relationship between the jmods
> >>> and the distribution bundles is on the table really.
> >>>> Looking for example  into a Linux  build, I see  a lot of debuginfo 
> >>>> files  in
> the
> >>> jdk image (more or less for every shared lib)  .
> >>>> But when looking into the jmods  of that jdk image ,  no debuginfo files
> are
> >>> in there ( I checked the java.base jmod).
> >>>> So  putting  the  files with debug information into the jmods  seems to
> be
> >>> something that was not done so far  cross platform  (or is there some
> build
> >>> switch  for it that I did not check?) .
> >>>> Maybe to keep the jmods as small as possible .
> >>> No, we do not put the debuginfo files in the jmods nor the bundles
> >>> because those are not intended to be shipped to customers. We are
> >>> currently overlaying them into images/jdk in the build output to make
> >>> them available for local debugging. (This is convoluted and I would very
> >>> much like to get away from this practice at some point so that there is
> >>> a 1-1 mapping between images/jdk and bundles/jdk*-bin.tar.gz.) The
> >>> stripped pdb files you are proposing are on the contrary intended for
> >>> shipping to customers (as I understand your proposal) so comparing
> them
> >>> with the debuginfo files is not relevant.
> >>>
> >>> Now if MS had been kind enough to define a separate file type for the
> >>> stripped pdbs, so that they could live alongside the full pdbs, we
> >>> wouldn't have this issue. The heart of the problem is that only one set
> >>> of files (either stripped or full) can be present and usable in
> >>> images/jdk at a time. We have 2 main uses for images/jdk.
> >>>
> >>> 1. Developer running and debugging locally
> >>>
> >>> 2. Serve as the source for generating the distribution bundles
> >>>
> >>> We currently have one image serving both of these purposes, which is
> >>> already creating complicated and convoluted build steps. To properly
> >>> solve this I would argue for splitting these two apart into two
> >>> different images for the two different purposes. The build procedure
> >>> would then be, first build the images for distribution, only containing
> >>> what should go into each bundle. Then create the developer jdk image
> by
> >>> copying files from the distribution images. On Windows, the first image
> >>> would contain the stripped pdbs and when building the second, those
> >>> would get overwritten with the full pdbs.
> >>>
> >>> Now that I figured out a working model that would solve a bunch of
> other
> >>> problems as well, I would love to implement it,

RE: RFR [XS]: 8238530: OPT_SPEED_SRC list misses some files with cpu-dependend file names

[Baesken, Matthias]

Hi Clas / Magnus, thanks for the reviews !

Best regards, Matthias


> 
> 
> On 2020-02-05 11:43, Magnus Ihse Bursie wrote:
> > I'm fine with the fix.
> 
> Me too, looks good and more consistent.
> 
> /Claes

RE: RFR [XS]: 8238530: OPT_SPEED_SRC list misses some files with cpu-dependend file names

[Baesken, Matthias]

Hi Magnus ,  putting those  files into  OPT_SPEED_SRC  means using  -O3 on 
them,  while  the other  cpp  files are built with -Os 
( the list   comes only into play when the jvm-feature "minimal" was been 
configured   ,  see  the  ifeq ($(call check-jvm-feature, minimal), true)   
  ).

But we built those files in the normal/regular productive make already with 
-O3, and this works fine  so I would not  see any issues here ...

Best regards , Matthias


> 
> On 2020-02-05 10:49, Baesken, Matthias wrote:
> > Hello,  please review this small change .
> >
> > The OPT_SPEED_SRC list (for files to be built optimized for speed) in
> JVMFeatures.gmk includes a few files with cpu-dependend names for arm
> > but misses the corresponding files for other cpus (e.g. frame_arm.cpp).
> The change adds those files .
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8238530
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8238530.0/
> (cc:ing our resident optimization expert Claes)
> 
> As usual, Oracle does not care much about ppc, s390 and aarch64. You can
> optimize them however you want. :)
> 
> But you have also added frame_x86.cpp and icache_x86.cpp. How does this
> affect performance and correctness on the x64 platform? I'd like you to
> either answer that question, or remove the x86 files from this patch.
> Changes in optimization in frame files sounds like scary stuff without
> proper verification.
> 
> /Magnus
> >
> > Best Regards, Matthias
> >

RFR [XS]: 8238530: OPT_SPEED_SRC list misses some files with cpu-dependend file names

[Baesken, Matthias]

Hello,  please review this small change .

The OPT_SPEED_SRC list (for files to be built optimized for speed) in 
JVMFeatures.gmk includes a few files with cpu-dependend names for arm
but misses the corresponding files for other cpus (e.g. frame_arm.cpp).  The 
change adds those files .

Bug/webrev :

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

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

Best Regards, Matthias

Re: RFR: JDK-8238281 Raise minimum gcc version needed to 5.0

[Baesken, Matthias]

Hi Magnus, looks good to me !


> Date: Tue, 4 Feb 2020 22:48:07 +0100
> From: Magnus Ihse Bursie 
> To: build-dev@openjdk.java.net, hotspot-dev
>   
> Subject: Re: RFR: JDK-8238281 Raise minimum gcc version needed to 5.0
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Can I have one more hotspot reviewer, please?
> 
> /Magnus
> 
> On 2020-02-03 09:02, Magnus Ihse Bursie wrote:
> > JEP 347 "Adopt C++14 Language Features in HotSpot" (JDK-8208089) will
> > require that all compilers support the C++14 language extension. The
> > first gcc version to fully support C++14 is 5.0. We need to raise the
> > bar from 4.8 to 5.0.
> >
> > Since removing support for old compilers, especially gcc, can be
> > tricky to handle for some on old and odd setups, I think it's best to
> > do this as a separate step from the C++14 upgrade.
> >
> > On the way, this will allow us to remove some workarounds/close some
> > bugs for really old gcc versions.
> >
> > For hotspot, most notably this means:
> >
> > ?* The workarounds for no ATTRIBUTE_PRINTF are not needed anymore.
> >
> > * The workaround for ATTRIBUTE_ALIGNED is no longer needed.
> >
> > * The workaround in offset_of is not needed anymore. Instead, the
> > appropriate warning is disabled. (In fact, now only xlc need special
> > treatment for offset_of; if that could be fixed now, it would mean
> > that offset_of can be replaced by offsetof in hotspot.)
> >
> > * [Bug fix] The define CAN_USE_NAN_DEFINE (which is used only in
> > share/runtime/sharedRuntimeTrans.cpp), is now always defined for gcc.
> > This was previously done only for gcc >= 4.3 and < 5. I believe this
> > was a bug, and the intention was to allow for old-style NaN behavior
> > in gcc 4.2 and older.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8238281
> > WebRev:
> > http://cr.openjdk.java.net/~ihse/JDK-8238281-make-gcc-5-
> minimum/webrev.01
> >

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

> 
> Hi Erik, maybe we can just rename the configure option to
> 
> --enable-stripped-pdbs-for-bundle
> 
> AND make the default  = no/false .
> Then without setting the configure flag,   everything stays as it is  for JDK
> vendors/distributors  who do not want  the stripped pdbs in the bundle.
> 
> Others who set the flag,  have to "teach"  the developers that the bundle
> already contains stripped pdbs that need to be replaced by full/"private"
> pdbs  in case better  symbols/stacks are wanted .
> I think that’s a good compromise.
> 
> > Now if MS had been kind enough to define a separate file type for the
> > stripped pdbs, so that they could live alongside the full pdbs, we
> > wouldn't have this issue.
> 
> Unfortunately that seems not to work,  I tried to use the stripped pdb-files
> with another extension  but no success ☹  .
> 
> An alternative could be to create 2 bundles  when  "--enable-stripped-pdbs-
> for-bundle" is set to yes , one with one without   stripped pdbs .
> 

Hello, any more comment on this ?

What about the option to create 2 bundles , one with one without  stripped pdbs 
 (should be very compatible to what we have and "nondisruptive" ) ?

Best regards, Matthias

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

Hi Erik, maybe we can just rename the configure option to

--enable-stripped-pdbs-for-bundle

AND make the default  = no/false .
Then without setting the configure flag,   everything stays as it is  for JDK 
vendors/distributors  who do not want  the stripped pdbs in the bundle.

Others who set the flag,  have to "teach"  the developers that the bundle 
already contains stripped pdbs that need to be replaced by full/"private" pdbs  
in case better  symbols/stacks are wanted .
I think that’s a good compromise.

> Now if MS had been kind enough to define a separate file type for the
> stripped pdbs, so that they could live alongside the full pdbs, we
> wouldn't have this issue.

Unfortunately that seems not to work,  I tried to use the stripped pdb-files 
with another extension  but no success ☹  .

An alternative could be to create 2 bundles  when  
"--enable-stripped-pdbs-for-bundle" is set to yes , one with one without   
stripped pdbs . 

Best regards, Matthias


> 
> On 2020-01-23 00:03, Baesken, Matthias wrote:
> > Hi Erik,  yes true sorry for answering  your comments a bit late .
> >
> >> If a user runs jlink and includes all the jmods we ship with the JDK, the
> result
> >> should be essentially equivalent to the original JDK image. The way the
> >> stripped pdb files are included in the bundles sort of at the last
> >> second of the build here breaks this property.
> > I think we should address this in a separate bug/CR .
> Maybe. I realize that my proposal below is quite a big task. But on the
> other hand, I don't think breaking the relationship between the jmods
> and the distribution bundles is on the table really.
> > Looking for example  into a Linux  build, I see  a lot of debuginfo files  
> > in the
> jdk image (more or less for every shared lib)  .
> > But when looking into the jmods  of that jdk image ,  no debuginfo files are
> in there ( I checked the java.base jmod).
> > So  putting  the  files with debug information into the jmods  seems to be
> something that was not done so far  cross platform  (or is there some build
> switch  for it that I did not check?) .
> > Maybe to keep the jmods as small as possible .
> 
> No, we do not put the debuginfo files in the jmods nor the bundles
> because those are not intended to be shipped to customers. We are
> currently overlaying them into images/jdk in the build output to make
> them available for local debugging. (This is convoluted and I would very
> much like to get away from this practice at some point so that there is
> a 1-1 mapping between images/jdk and bundles/jdk*-bin.tar.gz.) The
> stripped pdb files you are proposing are on the contrary intended for
> shipping to customers (as I understand your proposal) so comparing them
> with the debuginfo files is not relevant.
> 
> Now if MS had been kind enough to define a separate file type for the
> stripped pdbs, so that they could live alongside the full pdbs, we
> wouldn't have this issue. The heart of the problem is that only one set
> of files (either stripped or full) can be present and usable in
> images/jdk at a time. We have 2 main uses for images/jdk.
> 
> 1. Developer running and debugging locally
> 
> 2. Serve as the source for generating the distribution bundles
> 
> We currently have one image serving both of these purposes, which is
> already creating complicated and convoluted build steps. To properly
> solve this I would argue for splitting these two apart into two
> different images for the two different purposes. The build procedure
> would then be, first build the images for distribution, only containing
> what should go into each bundle. Then create the developer jdk image by
> copying files from the distribution images. On Windows, the first image
> would contain the stripped pdbs and when building the second, those
> would get overwritten with the full pdbs.
> 
> Now that I figured out a working model that would solve a bunch of other
> problems as well, I would love to implement it, but I doubt I will have
> time in the near future.
> 
> /Erik
> 
> >
> >> To properly implement this, care will need to be taken to juggle the two
> >> sets of pdb files around, making sure each build and test use case has
> >> the correct one in place where and when it's needed. Quite possibly, we
> >> cannot cover all use cases with one build configuration. Developers
> >> needing the full debug symbols when debugging locally would likely need
> >> to disable the stripped symbols so they get the full symbols everywhere.
> >> Possibly this would need to be the default for debug builds and
> >> configurable for release builds.
> >  From 

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Thanks for the review !
Erik,  are you fine with the latest change too ?

Best regards, Matthias



> On 2020-01-24 10:27, Baesken, Matthias wrote:
> > Hi Erik, thanks for the comments, new webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.7/
> Looks good to me. Sorry for not being able to provide an example in a
> timely matter. Good thing you found one yourself. :)
> 
> /Magnus
> >
> > Best regards, Matthias

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik, thanks for the comments, new webrev :

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

Best regards, Matthias



> Hello,
> 
> That's better, but there are still some issues.
> 
> flags-cflags.m4
> 
> Code is repeated in both if and else block.
> 
> jdk-options.m4
> 
> The default is now true for all platforms. I would suggest moving the
> s390x conditional down into an elif after the elif for "no".
> 
> LibCommon.gmk
> 
> Please revert whole file.
> 
> /Erik
> 
> On 2020-01-23 05:15, Baesken, Matthias wrote:
> > Hi Erik,  new webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.6/
> >
> > I moved the settings back into the  m4 files .
> >
> > Best regards, Matthias
> >
> >> Hello Matthias,
> >>
> >> You can keep the setting up of all the flags in flags-cflags.m4 and
> >> flags-ldflags.m4 based on the value of ENABLE_LINKTIME_GC. You can
> also
> >> default the value of this new parameter to true for s390x to keep the
> >> current behavior for that platform. As it is in this patch, the JVM
> >> flags for s390x are setup in configure while the JDK flags are in make,
> >> which gets confusing I think.
> >>
> >> /Erik
> >>
> >>
> >> On 2020-01-22 05:33, Baesken, Matthias wrote:
> >>> Hi Magnus / David,  here is a new webrev :
> >>>
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.4/
> >>>
> >>>
> >>> it supports now a  configure switch  --enable-linktime-gc=yes  that needs
> to
> >> be set  to enable the link time section gc  .
> >>> Exception is linuxs390x  where we already have the  feature enabled
> (and
> >> keep it enabled always for LIB_JVM).
> >>> Best regards, Matthias
> >>>
> >>>
> >>>
> >>> From: Baesken, Matthias
> >>> Sent: Freitag, 17. Januar 2020 12:44
> >>> To: Magnus Ihse Bursie ; David
> Holmes
> >> ; 'build-dev@openjdk.java.net'  >> d...@openjdk.java.net>; 'hotspot-...@openjdk.java.net'  >> d...@openjdk.java.net>
> >>> Subject: RE: RFR: 8236714: enable link-time section-gc for linux to
> remove
> >> unused code
> >>>
> >>>
> >>> *   Matthias: Have a look at some recently added option to get an
> >> indication of the best practice in adding new options. There are some
> ways to
> >> easily make this incorrect
> >>> Hi Magnus, do you have a good/”best practice”  example  (not that I
> catch a
> >> bad one  )  ?
> >>> Best regards, Matthias
> >>>

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik,  new webrev :

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

I moved the settings back into the  m4 files .

Best regards, Matthias

> 
> Hello Matthias,
> 
> You can keep the setting up of all the flags in flags-cflags.m4 and
> flags-ldflags.m4 based on the value of ENABLE_LINKTIME_GC. You can also
> default the value of this new parameter to true for s390x to keep the
> current behavior for that platform. As it is in this patch, the JVM
> flags for s390x are setup in configure while the JDK flags are in make,
> which gets confusing I think.
> 
> /Erik
> 
> 
> On 2020-01-22 05:33, Baesken, Matthias wrote:
> > Hi Magnus / David,  here is a new webrev :
> >
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.4/
> >
> >
> > it supports now a  configure switch  --enable-linktime-gc=yes  that needs to
> be set  to enable the link time section gc  .
> >
> > Exception is linuxs390x  where we already have the  feature enabled  (and
> keep it enabled always for LIB_JVM).
> >
> > Best regards, Matthias
> >
> >
> >
> > From: Baesken, Matthias
> > Sent: Freitag, 17. Januar 2020 12:44
> > To: Magnus Ihse Bursie ; David Holmes
> ; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>; 'hotspot-...@openjdk.java.net'  d...@openjdk.java.net>
> > Subject: RE: RFR: 8236714: enable link-time section-gc for linux to remove
> unused code
> >
> >
> >
> >*   Matthias: Have a look at some recently added option to get an
> indication of the best practice in adding new options. There are some ways to
> easily make this incorrect
> >
> > Hi Magnus, do you have a good/”best practice”  example  (not that I catch a
> bad one  )  ?
> >
> > Best regards, Matthias
> >

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

Hi Erik,  yes true sorry for answering  your comments a bit late .

> If a user runs jlink and includes all the jmods we ship with the JDK, the 
> result 
> should be essentially equivalent to the original JDK image. The way the 
> stripped pdb files are included in the bundles sort of at the last 
> second of the build here breaks this property.

I think we should address this in a separate bug/CR .
Looking for example  into a Linux  build, I see  a lot of debuginfo files  in 
the jdk image (more or less for every shared lib)  .
But when looking into the jmods  of that jdk image ,  no debuginfo files are in 
there ( I checked the java.base jmod).
So  putting  the  files with debug information into the jmods  seems to be 
something that was not done so far  cross platform  (or is there some build 
switch  for it that I did not check?) .
Maybe to keep the jmods as small as possible .


> To properly implement this, care will need to be taken to juggle the two 
> sets of pdb files around, making sure each build and test use case has 
> the correct one in place where and when it's needed. Quite possibly, we 
> cannot cover all use cases with one build configuration. Developers 
> needing the full debug symbols when debugging locally would likely need 
> to disable the stripped symbols so they get the full symbols everywhere. 
> Possibly this would need to be the default for debug builds and 
> configurable for release builds.

From my limited experience , the developers  do not work with the bundles (that 
 would contain now after my patch the stripped pds)  but with a "normal" jdk 
image that  is created my make all.

Best regards, Matthias



> 
> This still does not address anything in my objection.
> 
> /Erik
> 
> On 2020-01-22 07:46, Baesken, Matthias wrote:
> > Hello,  here is an updated version  :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8237192.3/
> >
> > this one supports a configure switch  "--enable-stripped-pdbs"to enable
> the feature .
> >
> > Best regards, Matthias
> >
> >
> >> -Original Message-
> >> From: Baesken, Matthias
> >> Sent: Dienstag, 21. Januar 2020 11:03
> >> To: 'David Holmes' ; 'build-
> >> d...@openjdk.java.net' ; 'hotspot-
> >> d...@openjdk.java.net' 
> >> Subject: RE: RFR: 8237192: Generate stripped/public pdbs on Windows for
> >> jdk images
> >>
> >>
> >> Hi David ,  yes I think it makes sense to have a configure option for this 
> >> .
> >> Not everyone would like to have a larger JDK (even it is only a bit 
> >> larger).
> >>

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik, okay I'll check that .
I had the impression I would have ordering  issues of the m4 files and how they 
end up in the generated-configure.sh  but  looks like that’s not the case .

Best regards, Matthias


> 
> Hello Matthias,
> 
> You can keep the setting up of all the flags in flags-cflags.m4 and
> flags-ldflags.m4 based on the value of ENABLE_LINKTIME_GC. You can also
> default the value of this new parameter to true for s390x to keep the
> current behavior for that platform. As it is in this patch, the JVM
> flags for s390x are setup in configure while the JDK flags are in make,
> which gets confusing I think.
> 
> /Erik
> 

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

Hello,  here is an updated version  :

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

this one supports a configure switch  "--enable-stripped-pdbs"to enable the 
feature .

Best regards, Matthias


> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 21. Januar 2020 11:03
> To: 'David Holmes' ; 'build-
> d...@openjdk.java.net' ; 'hotspot-
> d...@openjdk.java.net' 
> Subject: RE: RFR: 8237192: Generate stripped/public pdbs on Windows for
> jdk images
> 
> 
> Hi David ,  yes I think it makes sense to have a configure option for this .
> Not everyone would like to have a larger JDK (even it is only a bit larger).
> 

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Magnus / David,  here is a new webrev :


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


it supports now a  configure switch  --enable-linktime-gc=yes  that needs to be 
set  to enable the link time section gc  .

Exception is linuxs390x  where we already have the  feature enabled  (and keep 
it enabled always for LIB_JVM).

Best regards, Matthias



From: Baesken, Matthias
Sent: Freitag, 17. Januar 2020 12:44
To: Magnus Ihse Bursie ; David Holmes 
; 'build-dev@openjdk.java.net' 
; 'hotspot-...@openjdk.java.net' 

Subject: RE: RFR: 8236714: enable link-time section-gc for linux to remove 
unused code



  *   Matthias: Have a look at some recently added option to get an indication 
of the best practice in adding new options. There are some ways to easily make 
this incorrect

Hi Magnus, do you have a good/”best practice”  example  (not that I catch a bad 
one  )  ?

Best regards, Matthias

RE: RFR [XS]: 8237374: configuring with --with-jvm-variants=minimal,server makes cds disappear in server

[Baesken, Matthias]

Hi Erik, new webrev :

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

Best regards, Matthias

-Original Message-
From: Erik Joelsson  
Sent: Freitag, 17. Januar 2020 15:18
To: Baesken, Matthias ; 'build-dev@openjdk.java.net' 
; 'hotspot-...@openjdk.java.net' 

Subject: Re: RFR [XS]: 8237374: configuring with 
--with-jvm-variants=minimal,server makes cds disappear in server

Hello Matthias,

Using BUILDING_MULTIPLE_JVM_VARIANTS as condition is clever and happens 
to coincide with the set of variants that also support CDS, but I would 
say this correlation is incidental. I would still prefer an explicit 
test for if any of the variants that do support CDS is in the set of 
variants being built. This will make it much easier to read and 
understand the logic. Simply:

if ! HOTSPOT_CHECK_JVM_VARIANT(server) && ! 
HOTSPOT_CHECK_JVM_VARIANT(client); then
   ENABLE_CDS="false"
   ...

/Erik

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

Hi David ,  yes I think it makes sense to have a configure option for this .
Not everyone would like to have a larger JDK (even it is only a bit larger).

Best regards, Matthias


> 
> Hi Matthias,
> 
> This also needs to be a configurable option not one done by default as
> there can be non-technical issues relating to shipping symbol files in a
> product.
> 
> Thanks,
> David
> 
> On 17/01/2020 6:44 pm, Baesken, Matthias wrote:
> > Hello, please review this change related to stripped/"public" pdb file
> generation on Windows .
> >
> > Currently the JDK bundle on Windows does not contain pdb files (full pdb
> files are in a separate symbols bundle).
> > This leads currently to bad native stack traces e.g. when crashes occur.
> > One reason not to deliver the full pdb files might be the large size of 
> > these
> files.
> >
> > However there exist also "public" or stripped pdb files on Windows, see :
> >
> > https://docs.microsoft.com/en-us/cpp/build/reference/pdbstripped-strip-
> private-symbols?view=vs-2017
> >
> > Those are much smaller (often only 10-20% of the full pdb files) and they
> offer a good compromise (no "file:linenumber" info in the native stacks but
> at least the function name+hex-offset is visible)
> > to delivering full pdbs in the JDK.
> >
> > Example sizes for the currently built full pdbs / stripped pdbs from VS2017
> based 64bit build of jdk/jdk :
> > jvm.pdb : 73,1 MB / 9,46 MB
> > awt.pdb : 7,05 MB / 1,48 MB
> >
> > The patch  adds  generation  of stripped  pdb files  to the Windows  build.
> > Additionally those files are put into the JDK  bundle(while the symbols
> bundle still gets the full pdb files ) .
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8237192
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8237192.0/
> >
> >
> > Thanks, Matthias
> >

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

  *   Matthias: Have a look at some recently added option to get an indication 
of the best practice in adding new options. There are some ways to easily make 
this incorrect

Hi Magnus, do you have a good/”best practice”  example  (not that I catch a bad 
one  )  ?

Best regards, Matthias



On 2020-01-16 10:30, David Holmes wrote:
Hi Matthias,

On 16/01/2020 6:10 pm, Baesken, Matthias wrote:

Hi David, sure we can introduce a way to switch this on/off.

Thanks.


There is already something similar for the link-time optimization (flto) , see 
the feature

JvmFeatures.gmk
180 ifeq ($(call check-jvm-feature, link-time-opt), true)
190 ifeq ($(call check-jvm-feature, link-time-opt), false)

hotspot.m4
29 static-build link-time-opt aot jfr"
502 JVM_FEATURES_link_time_opt="link-time-opt"

Yep familiar with that from Minimal VM and SE Embedded days :)


Should we have  "link-time-gc"  additionally to   " link-time-opt"  ?   
(however it  would  be a  bit misleading   that it is a "JVM" feature , but 
except linux s390x  it is only changing the build of the JDK libs) .

I agree the definition of this as a "JVM" feature is a bit odd/misleading. 
Perhaps the build folk have a suggestion on how to refactor this kind of option 
into something more general? In the meantime having link-time-gc sit alongside 
link-time-opt seems acceptable to me.

We don't have the concept of "JDK features", akin to "JVM features". Maybe we 
should have. It's an idea worth exploring, anyway.

The way we currently do on/off features for the entire JDK is by using autoconf 
options. So, in this case, --enable-link-time-gc, or something like that. It 
might just as well be on by default, which gives us a --disable-link-time-gc 
instead. (I understand David's reservation not about this being the default, 
just that it is not possible to simply turn off.)

Matthias: Have a look at some recently added option to get an indication of the 
best practice in adding new options. There are some ways to easily make this 
incorrect, and our code is full of old examples that does this unnecessary 
complex, or downright wrong. (These should be fixed, and we should probably 
introduce a simpler API for doing this, and so on... I'll address those as soon 
as time permits.)

/Magnus

RE: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

Hello,  my example product build (64 bit Windows / VS2017) shows the following 
sizes for the uncompressed pdb files :
sum of size of all full pdbs : 117 MB (jvm.pdb is 73,1 MB )
sum of size of all stripped pdbs: 18,2 MB (jvm.pdb is 9,46 MB = ~ 50 % of all)

Best regards, Matthias


On 2020-01-17 09:44, Baesken, Matthias wrote:

Hello, please review this change related to stripped/"public" pdb file 
generation on Windows .



Currently the JDK bundle on Windows does not contain pdb files (full pdb files 
are in a separate symbols bundle).

This leads currently to bad native stack traces e.g. when crashes occur.

One reason not to deliver the full pdb files might be the large size of these 
files.



However there exist also "public" or stripped pdb files on Windows, see :



https://docs.microsoft.com/en-us/cpp/build/reference/pdbstripped-strip-private-symbols?view=vs-2017



Those are much smaller (often only 10-20% of the full pdb files) and they offer 
a good compromise (no "file:linenumber" info in the native 
stacks but at least the function name+hex-offset is visible)

to delivering full pdbs in the JDK.



Example sizes for the currently built full pdbs / stripped pdbs from VS2017 
based 64bit build of jdk/jdk :

jvm.pdb : 73,1 MB / 9,46 MB

awt.pdb : 7,05 MB / 1,48 MB



The patch  adds  generation  of stripped  pdb files  to the Windows  build.

Additionally those files are put into the JDK  bundle(while the symbols 
bundle still gets the full pdb files ) .





Bug/webrev :



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



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

What is the extra payload of all the *.stripped.pdb files together?

RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

[Baesken, Matthias]

Hello, please review this change related to stripped/"public" pdb file 
generation on Windows .

Currently the JDK bundle on Windows does not contain pdb files (full pdb files 
are in a separate symbols bundle).
This leads currently to bad native stack traces e.g. when crashes occur.
One reason not to deliver the full pdb files might be the large size of these 
files.

However there exist also "public" or stripped pdb files on Windows, see :

https://docs.microsoft.com/en-us/cpp/build/reference/pdbstripped-strip-private-symbols?view=vs-2017

Those are much smaller (often only 10-20% of the full pdb files) and they offer 
a good compromise (no "file:linenumber" info in the native stacks but at least 
the function name+hex-offset is visible)
to delivering full pdbs in the JDK.

Example sizes for the currently built full pdbs / stripped pdbs from VS2017 
based 64bit build of jdk/jdk :
jvm.pdb : 73,1 MB / 9,46 MB
awt.pdb : 7,05 MB / 1,48 MB

The patch  adds  generation  of stripped  pdb files  to the Windows  build.
Additionally those files are put into the JDK  bundle(while the symbols 
bundle still gets the full pdb files ) .


Bug/webrev :

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

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


Thanks, Matthias

RFR [XS]: 8237374: configuring with --with-jvm-variants=minimal,server makes cds disappear in server

[Baesken, Matthias]

Hello, please review  this small patch .

When building 2 VM variants   minimal and server  in one build and using

  --with-jvm-variants=minimal,server

to configure this setup  , the build works nicely. But I notice that in the 
server VM, cds is removed.
Instead of

checking if cds should be enabled... yes

I get (with some tracing added ) :

configure: WARNING: ENABLE_CDS set to false because we found a minimal, core or 
zero JVM.
checking if cds should be enabled... no

The checks in hotspot.m4 disables cds by error for the server v,  because it 
matches to minimal  in the string  "minimal,server"  .

The configure option  --with-jvm-variants=minimal,server   enables  a  
multi-JVM variants build  (variable BUILDING_MULTIPLE_JVM_VARIANTS in 
hotspot.m4) .
This   special build is only  supported  for   
VALID_MULTIPLE_JVM_VARIANTS="server client minimal" .
So  we  better do not  disable  cds  in  a  BUILDING_MULTIPLE_JVM_VARIANTS - 
build   (means minimal + server/client ) ;   minimal has cds disabled by 
default anyway.


Bug/webrev :

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


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


Thanks, Matthias

RFR [XXS]: 8237382: Cleanup the OPT_SPEED_SRC file list in JvmFeatures.gmk

[Baesken, Matthias]

Hello, please review this very small change .

It removes file that are not present any more from the  OPT_SPEED_SRC file list 
in JvmFeatures.gmk  .

( this is a list of files to be optimized for speed when we otherwise optimize 
for size  in the minimal-JVM build)


Bug/webrev :

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

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

Thanks, Matthias

RE: configuring with --with-jvm-variants=minimal,server makes cds disappear in server

[Baesken, Matthias]

Hello, thanks for looking into it .
Should I do a check just looking into single JVM configs,   something like

AC_DEFUN([HOTSPOT_IS_JVM_VARIANT],
[ [ [[ " $JVM_VARIANTS " == " $1 " ]] ] ])

if HOTSPOT_IS_JVM_VARIANT(zero) ||  HOTSPOT_IS_JVM_VARIANT(minimal) ||  
HOTSPOT_IS_JVM_VARIANT(core); then

instead of

AC_DEFUN([HOTSPOT_CHECK_JVM_VARIANT],
[ [ [[ " $JVM_VARIANTS " =~ " $1 " ]] ] ])

if HOTSPOT_CHECK_JVM_VARIANT(zero) ||  HOTSPOT_CHECK_JVM_VARIANT(minimal) ||  
HOTSPOT_CHECK_JVM_VARIANT(core); then


This should  remove the error in case of multi-JVM configs .
Or maybe  the whole check ( if HOTSPOT_CHECK_JVM_VARIANT(zero) ||  
HOTSPOT_CHECK_JVM_VARIANT(minimal) ||  HOTSPOT_CHECK_JVM_VARIANT(core); then 
 fi )
 might be removed , I see not so much value in it  because  in case one sets 
--enable-jvm-features   directly the check isn’t done .

I opened  bug :

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

JDK-8237374 :  configuring with --with-jvm-variants=minimal,server makes cds 
disappear in server


Best regards, Matthias




> 
> This does indeed look like a bug to me. At least at Oracle, we no longer
> build any multi JVM configs regularly, so things like this falls through
> the cracks.
> 
> /Erik
> 
> On 2020-01-16 02:18, Baesken, Matthias wrote:
> > Hello, I noticed the following  strange "feature" (or is it a bug?) .
> > When  building 2 VM variants in one build  and  using
> >
> >--with-jvm-variants=minimal,server
> >
> > For this, the build works nicely. But I notice that  in the server VM, cds  
> > is
> removed.
> > Instead of
> >
> > checking if cds should be enabled... yes
> >
> > I get ( with the following patch that adds tracing)  :
> >
> > configure: WARNING: ENABLE_CDS set to false because we found a
> minimal, core or zero JVM.
> > checking if cds should be enabled... no
> >...
> >
> > * JVM features:   minimal: 'compiler1 minimal serialgc'   server: 
> > 'compiler1
> compiler2 epsilongc g1gc jfr jni-check jvmti management nmt parallelgc
> serialgc services vm-structs'
> >
> > (patch is
> >
> > --- a/make/autoconf/hotspot.m4  Wed Jan 15 21:20:40 2020 -0800
> > +++ b/make/autoconf/hotspot.m4  Thu Jan 16 10:24:43 2020 +0100
> > @@ -528,6 +528,7 @@
> >if HOTSPOT_CHECK_JVM_VARIANT(zero) ||
> HOTSPOT_CHECK_JVM_VARIANT(minimal) ||
> HOTSPOT_CHECK_JVM_VARIANT(core); then
> >   # ..except when the user explicitely requested it with --enable-jvm-
> features
> >   if ! HOTSPOT_CHECK_JVM_FEATURE(cds); then
> > ENABLE_CDS="false"
> > +  AC_MSG_WARN([ENABLE_CDS set to false because we found a
> minimal, core or zero JVM.])
> > if test "x$enable_cds" = "xyes"; then
> >   AC_MSG_ERROR([CDS not implemented for variants zero, minimal,
> core. Remove --enable-cds.])
> > Fi
> >
> >
> > Is it expected that  cds goes away in "server"   when  configuring  "--with-
> jvm-variants=minimal,server"   ?   Looks like a bug to me,  should it be fixed
> (so that cds stays in the server   jvm-feature list) ?
> >
> >
> > Thanks, Matthias
> >

configuring with --with-jvm-variants=minimal,server makes cds disappear in server

[Baesken, Matthias]

Hello, I noticed the following  strange "feature" (or is it a bug?) .
When  building 2 VM variants in one build  and  using

  --with-jvm-variants=minimal,server

For this, the build works nicely. But I notice that  in the server VM, cds  is 
removed.
Instead of

checking if cds should be enabled... yes

I get ( with the following patch that adds tracing)  :

configure: WARNING: ENABLE_CDS set to false because we found a minimal, core or 
zero JVM.
checking if cds should be enabled... no
  ...

* JVM features:   minimal: 'compiler1 minimal serialgc'   server: 
'compiler1 compiler2 epsilongc g1gc jfr jni-check jvmti management nmt 
parallelgc serialgc services vm-structs'

(patch is

--- a/make/autoconf/hotspot.m4  Wed Jan 15 21:20:40 2020 -0800
+++ b/make/autoconf/hotspot.m4  Thu Jan 16 10:24:43 2020 +0100
@@ -528,6 +528,7 @@
  if HOTSPOT_CHECK_JVM_VARIANT(zero) || HOTSPOT_CHECK_JVM_VARIANT(minimal) || 
HOTSPOT_CHECK_JVM_VARIANT(core); then
 # ..except when the user explicitely requested it with 
--enable-jvm-features
 if ! HOTSPOT_CHECK_JVM_FEATURE(cds); then
   ENABLE_CDS="false"
+  AC_MSG_WARN([ENABLE_CDS set to false because we found a minimal, core or 
zero JVM.])
   if test "x$enable_cds" = "xyes"; then
 AC_MSG_ERROR([CDS not implemented for variants zero, minimal, core. 
Remove --enable-cds.])
   Fi


Is it expected that  cds goes away in "server"   when  configuring  
"--with-jvm-variants=minimal,server"   ?   Looks like a bug to me,  should it 
be fixed   (so that cds stays in the server   jvm-feature list) ?


Thanks, Matthias

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi David, sure we can introduce a way to switch this on/off.
There is already something similar for the link-time optimization (flto) , see 
the feature 

JvmFeatures.gmk
180 ifeq ($(call check-jvm-feature, link-time-opt), true)
190 ifeq ($(call check-jvm-feature, link-time-opt), false)

hotspot.m4
29 static-build link-time-opt aot jfr"
502 JVM_FEATURES_link_time_opt="link-time-opt"


Should we have  "link-time-gc"  additionally to   " link-time-opt"  ?   
(however it  would  be a  bit misleading   that it is a "JVM" feature , but 
except linux s390x  it is only changing the build of the JDK libs) .

Best regards, Matthias



> 
> Hi Matthias,
> 
> I have reservations about turning this on by default and with no way to
> control it. This seems like it should be something you have to opt-in to
> initially while we gain some experience with it and ensure there are no
> unexpected side-effects. After that it could be enabled by default.
> 

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik, I did not notice  slowdowns in our night makes .

Looking at a specific  test machine  I use  (x86_64,  build JOBS hardwired  set 
 to 12 )   I  get around  6 minutes build time  with and without the feature .

( but you have to take into account  that  the  link-time section-gc   on  
x86_64in my patch is only enabled  for the smaller JDK libs and not 
libjvm.so  )  

Best regards, Matthias


> 
> Given the discussion regarding lto on hotspot and the extreme increased
> build time, have you noticed any difference in build times with this patch?
> 
> /Erik
> 

RE: serviceability agent : problems when using gcc LTO (link time optimization)

[Baesken, Matthias]

Hello,here is another  comparison for the larger  JDK  shared libs,  this 
time  with the sizes  of   build with linktime-gc (--gc-sections)   added .
( just for the larger libs )
(  I had not  enabled  linktime-gc  for libjvm   in our  test build , just for 
the JDK libs . )

Linuxx86_64 / gcc7

normal / with -flto / with linktime-gc (--gc-sections)
---
752K / 760K / 752K   ./lib/libawt.so<-- this one 
gets a bit larger but only with flto
472K / 456K / 468K   ./lib/libawt_xawt.so   <-- small gain
1.5M / 824K / 900K   ./lib/libfontmanager.so <-- HUGE gain 
, not as good with ltgc but still good
784K / 792K / 784K  ./lib/libfreetype.so<-- this one 
gets a bit larger  (but not with ltgc)
260K / 244K / 252K   ./lib/libjavajpeg.so <- small gain
196K / 188K / 196K   ./lib/libjava.so
280K / 256K / 276K   ./lib/libjdwp.so <- small gain
144K / 140K / 136K   ./lib/libjimage.so
564K / 420K / 404K   ./lib/liblcms.so <- large gain 
,  even better with  ltgc
576K / 496K / 556K   ./lib/libmlib_image.so   <- large gain 
with flto , small one with ltgc
368K / 212K / 236K   ./lib/libsplashscreen.so <- large gain
320K / 296K / 300K   ./lib/libsunec.so<- medium gain
23M / 17M   /  --not enabled---./lib/server/libjvm.so
<- big gain maybe because it is C++ ?


So   one can see,  that   flto   is usually  a bit better  than link-time-gc  
when it comes to  improving lib sizes, but not always .
However  linktime-gc   seems to be faster when comparing build times   , I did 
not really notice much  build  time slowdown because of it .
( we have it enabled  for linux  s390x  for some time in OpenJDK ).
The  linktime-gc   also offers a nice feature  to print out the eliminated 
stuff ,   that can be used  to remove  unused code cross-platform .
e.g.  the removed symbols  from   
https://bugs.openjdk.java.net/browse/JDK-8234629has been found this way .


Best regards, Matthias



Aleksei, Matthias,

thanks for the numbers. The size reduction on libjvm.so looks not bad, indeed.

Do you know if newer versions of GCC use the gold linker by default? I remember 
from some experiments which I did many years ago that gold was considerably 
faster compared to the default ld linker.

Unfortunately, the documentation I found about LTO/ld/gold [1,2] seems to be 
quite old and not very precise. Do you have gained any experience with LTO/gold 
and know if gold could maybe improve linking times with LTO?

[1] https://gcc.gnu.org/wiki/LinkTimeOptimization
[2] https://stackoverflow.com/questions/31688069/requirements-to-use-flto


Baesken, Matthias mailto:matthias.baes...@sap.com>> 
schrieb am Mi., 15. Jan. 2020, 07:02:
Hello , I can comment on   the  code size .  This is what I get when comparing  
a build  without  and  with  -flto .

gcc7 linux x86_64  product build, normal / with -flto
--

du -sh on the *.so files gives :

16K / 16K  ./lib/libattach.so
48K / 44K  ./lib/libawt_headless.so
752K / 760K./lib/libawt.so<-- this one gets a 
bit larger with flto
472K / 456K./lib/libawt_xawt.so   <-- small gain
36K / 32K  ./lib/libdt_socket.so
16K /16K   ./lib/libextnet.so
1.5M / 824K./lib/libfontmanager.so <-- HUGE gain
784K / 792K./lib/libfreetype.so<-- this one gets a 
bit larger with flto
56K / 56K  ./lib/libinstrument.so
52K / 52K  ./lib/libj2gss.so
20K / 20K  ./lib/libj2pcsc.so
92K / 84K  ./lib/libj2pkcs11.so
12K / 12k  ./lib/libjaas.so
260K / 244K./lib/libjavajpeg.so <- small gain
196K / 188K./lib/libjava.so
12K / 12K  ./lib/libjawt.so
280K / 256K./lib/libjdwp.so <- small gain
144K / 140K./lib/libjimage.so
84K / 76K  ./lib/libjli.so
16K / 16K  ./lib/libjsig.so
88K / 80K  ./lib/libjsound.so
564K / 420K./lib/liblcms.so <- large gain
12K / 12K  ./lib/libmanagement_agent.so
40K / 36K  ./lib/libmanagement_ext.so
36K / 32K  ./lib/libmanagement.so
576K / 496K./lib/libmlib_image.so   <- large gain
112K / 108K./lib/libnet.so
100K / 100K./lib/libnio.so
16K  / 16K ./lib/libprefs.so
8.0K / 8.0K./lib/librmi.so
60K / 60K  ./lib/libsaproc.so
36K / 32K  ./lib/libsctp.so
368K / 212K./lib/libsplashscreen.so <- large gain
320K / 296K./lib/libsunec.so<- medium gain
72K / 72K  ./lib/libverify.so
44K / 44K  ./lib/

RE: serviceability agent : problems when using gcc LTO (link time optimization)

[Baesken, Matthias]

Hello, I  used  the  "normal"  linker so I think  what 

https://stackoverflow.com/questions/31688069/requirements-to-use-flto

says is true ,  one can use  also the "normal"  linker .
Haven't checked  for any performance  (or other) improvements   when using gold 
 instead .  



Best regards, Matthias


> On 2020-01-15 07:29, Volker Simonis wrote:
> > Do you know if newer versions of GCC use the gold linker by default? I
> > remember from some experiments which I did many years ago that gold
> was
> > considerably faster compared to the default ld linker.
> 
> The default linker is system configured so it depends on your Linux
> distro. The devkits generated by the current devkit makefiles configures
> gold as default.
> 
> /Erik
> 

RE: serviceability agent : problems when using gcc LTO (link time optimization)

[Baesken, Matthias]

Hello , I can comment on   the  code size .  This is what I get when comparing  
a build  without  and  with  -flto .

gcc7 linux x86_64  product build, normal / with -flto
--

du -sh on the *.so files gives :

16K / 16K  ./lib/libattach.so
48K / 44K  ./lib/libawt_headless.so
752K / 760K./lib/libawt.so<-- this one gets a 
bit larger with flto
472K / 456K./lib/libawt_xawt.so   <-- small gain
36K / 32K  ./lib/libdt_socket.so
16K /16K   ./lib/libextnet.so
1.5M / 824K./lib/libfontmanager.so <-- HUGE gain
784K / 792K./lib/libfreetype.so<-- this one gets a 
bit larger with flto
56K / 56K  ./lib/libinstrument.so
52K / 52K  ./lib/libj2gss.so
20K / 20K  ./lib/libj2pcsc.so
92K / 84K  ./lib/libj2pkcs11.so
12K / 12k  ./lib/libjaas.so
260K / 244K./lib/libjavajpeg.so <- small gain
196K / 188K./lib/libjava.so
12K / 12K  ./lib/libjawt.so
280K / 256K./lib/libjdwp.so <- small gain
144K / 140K./lib/libjimage.so
84K / 76K  ./lib/libjli.so
16K / 16K  ./lib/libjsig.so
88K / 80K  ./lib/libjsound.so
564K / 420K./lib/liblcms.so <- large gain
12K / 12K  ./lib/libmanagement_agent.so
40K / 36K  ./lib/libmanagement_ext.so
36K / 32K  ./lib/libmanagement.so
576K / 496K./lib/libmlib_image.so   <- large gain
112K / 108K./lib/libnet.so
100K / 100K./lib/libnio.so
16K  / 16K ./lib/libprefs.so
8.0K / 8.0K./lib/librmi.so
60K / 60K  ./lib/libsaproc.so
36K / 32K  ./lib/libsctp.so
368K / 212K./lib/libsplashscreen.so <- large gain
320K / 296K./lib/libsunec.so<- medium gain
72K / 72K  ./lib/libverify.so
44K / 44K  ./lib/libzip.so
16K / 16K  ./lib/server/libjsig.so
23M / 17M  ./lib/server/libjvm.so<- big gain maybe 
because it is C++ ?


So  for  some libs  you see  10% and more , but not for all .   But  most  
large  libs  like   libjvm.so,  libfontmanager.so  or   liblcms.sowe 
see good results regarding reduced code size.

I Cannot say much about performance improvements , probably it would be small .

For SPEC  you find something at

http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html

(not that these results would say too much about  JVM performance ).


Best regards, Matthias

From: Volker Simonis 
Sent: Mittwoch, 15. Januar 2020 14:40
To: Aleksei Voitylov 
Cc: Baesken, Matthias ; Magnus Ihse Bursie 
; serviceability-...@openjdk.java.net; build-dev 
; hotspot-...@openjdk.java.net
Subject: Re: serviceability agent : problems when using gcc LTO (link time 
optimization)

While we are speaking about all the drawbacks of LTO, it's still not clear what 
the benefits are? In the very first mail Matthias mentioned that there might be 
performance improvements but that performance is not the main driving factor 
behind this initiative. So is it the reduced code size (Matthias mentioned 
something around ~10%)?

It would be nice to see some real numbers on various platform for both, the 
performance improvements for native parts like JIT/GC as well as for the size 
reduction.
Aleksei Voitylov 
mailto:aleksei.voity...@bell-sw.com>> schrieb am 
Di., 14. Jan. 2020, 09:54:

On 14/01/2020 19:57, Baesken, Matthias wrote:
> Hello  Magnus and Aleksei,  thanks for the input .
>
> The times you  provided really look like they make a big difference  at least 
> for people  often  building   minimal-vm  .
> Guess I have to measure myself a bit  (maybe the difference is not that big 
> on our linux s390x / ppc64(le) ) .
>
>> If the change to enable lto by default is proposed, what would be the
>> recommended strategy for development?
>>
> Probably  we should a)   do not enable it by default but just make sure it 
> can be enabled easily and works  for  the minimal-vm
That would be welcome. I have high hopes to LTO the VM some time by
default, and the tendency observed is that the compiler time overhead
for GCC becomes smaller. At the same time there is no reason why vendors
that invested in testing and can absorb the build time hit could provide
binaries with LTO built VMs by passing an additional option flag.
>   or  b)  take it easy to disable it for local development.
>
> Best regards, Matthias
>
>
>
>> Magnus, Matthias,
>>
>> for me, lto is a little heavyweight for development. x86_64 build time
>> with gcc 7:
>>
>> Server 1m32.484s
>> Server+Minimal 1m42.166s
>> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s
>>
>> If the change to enable lto by 

RE: RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hi Erik, thanks for the review and for forwarding ,  you are correct  
corelibs-dev is probably  interested in this as well .

Best regards, Matthias


> (adding core-libs-dev)
> 
> Change looks good to me, but would like input from at least someone in
> core-libs.
> 
> /Erik
> 
> On 2020-01-14 06:07, Baesken, Matthias wrote:
> > Hello,  the following change enables the  link-time section-gc for linux .
> >
> > gcc and ld support enabling "garbage collection" of unused input sections.
> > This can be used to eliminate unused coding from native libraries
> (especially when already compiling the objects with compiler flags -ffunction-
> sections -fdata-sections .
> > See for details the --gc-sections and --print-gc-sections parts of the ld
> documentation :
> >
> > https://linux.die.net/man/1/ld
> >
> >
> > We had this enabled already  for  linux s390x ,  with
> https://bugs.openjdk.java.net/browse/JDK-8234525
> > 8234525: enable link-time section-gc for linux s390x to remove unused code
> .
> >
> > This  time we enable it too for  the other linux platforms .
> >
> > For the other platforms I do not enable it for JVM, just for the JDK libs.  
> > The
> reason is that the serviceability agent  (not supported on linux s390x )
> is not
> (yet) ready for the optimization .
> > Below you see the results , for some libraries  a significant  size 
> > reduction
> can be achieved .
> >
> >
> > Results from linux x86_64 product builds :
> >
> > without / with ltgc
> >
> > 320K / 300K/images/jdk/lib/libsunec.so   <-
> > 36K  / 36K /images/jdk/lib/libdt_socket.so
> > 280K / 276K   /images/jdk/lib/libjdwp.so
> > 23M  / 23M/images/jdk/lib/server/libjvm.so< not set for 
> > libjvm.so
> for x86_64
> > 16K  / 16K/images/jdk/lib/server/libjsig.so
> > 72K  / 72M/images/jdk/lib/libverify.so
> > 84K  / 84M   /images/jdk/lib/libjli.so
> > 16K  / 16K/images/jdk/lib/libjsig.so
> > 196K / 196K   /images/jdk/lib/libjava.so
> > 44K  / 44K/images/jdk/lib/libzip.so
> > 144K / 136K   /images/jdk/lib/libjimage.so
> > 112K / 112K   /images/jdk/lib/libnet.so
> > 100K / 100K   /images/jdk/lib/libnio.so
> > 36K  / 36K/images/jdk/lib/libsctp.so
> > 576K / 556K   /images/jdk/lib/libmlib_image.so
> > 752K / 752K   /images/jdk/lib/libawt.so
> > 260K / 252K   /images/jdk/lib/libjavajpeg.so
> > 784K / 784K   /images/jdk/lib/libfreetype.so
> > 368K / 236K /images/jdk/lib/libsplashscreen.so   <-
> > 88K / 88K/images/jdk/lib/libjsound.so
> > 472K / 468K/images/jdk/lib/libawt_xawt.so
> > 564K / 404K   /images/jdk/lib/liblcms.so <--
> > 48K / 48K/images/jdk/lib/libawt_headless.so
> > 12K / 12K/images/jdk/lib/libjawt.so
> > 1.5M / 900K   /images/jdk/lib/libfontmanager.so  
> > <--
> > 12K / 12K/images/jdk/lib/libjaas.so
> > 92K / 92K/images/jdk/lib/libj2pkcs11.so
> > 16K / 16K/images/jdk/lib/libattach.so
> > 8.0K / 8.0K   /images/jdk/lib/librmi.so
> > 56K / 56K/images/jdk/lib/libinstrument.so
> > 16K / 16K/images/jdk/lib/libprefs.so
> > 52K / 52K/images/jdk/lib/libj2gss.so
> > 12K / 12K/images/jdk/lib/libmanagement_agent.so
> > 36K / 32K/images/jdk/lib/libmanagement.so
> > 16K / 16K/images/jdk/lib/libextnet.so
> > 20K / 20K/images/jdk/lib/libj2pcsc.so
> > 40K / 40K/images/jdk/lib/libmanagement_ext.so
> > 60K / 60K/images/jdk/lib/libsaproc.so
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8236714
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.2/
> >
> >
> > Thanks, Matthias

RE: serviceability agent : problems when using gcc LTO (link time optimization)

[Baesken, Matthias]

Hello  Magnus and Aleksei,  thanks for the input .

The times you  provided really look like they make a big difference  at least 
for people  often  building   minimal-vm  .
Guess I have to measure myself a bit  (maybe the difference is not that big on 
our linux s390x / ppc64(le) ) .

>
> If the change to enable lto by default is proposed, what would be the
> recommended strategy for development?
>

Probably  we should a)   do not enable it by default but just make sure it can 
be enabled easily and works  for  the minimal-vm or  b)  take it easy to 
disable it for local development.

Best regards, Matthias



> 
> Magnus, Matthias,
> 
> for me, lto is a little heavyweight for development. x86_64 build time
> with gcc 7:
> 
> Server 1m32.484s
> Server+Minimal 1m42.166s
> Server+Minimal (--with-jvm-features="link-time-opt") 5m29.422s
> 
> If the change to enable lto by default is proposed, what would be the
> recommended strategy for development?
> 
> For ARM32 Minimal, please keep in mind that it's not uncommon to disable
> LTO plugin in commodity ARM32 gcc compiler distributions, so for some it
> does not matter what settings we have in OpenJDK. I believe there could
> be other reasons for that on top of build time (bugs?).
> 

RFR: 8236714: enable link-time section-gc for linux to remove unused code

[Baesken, Matthias]

Hello,  the following change enables the  link-time section-gc for linux .

gcc and ld support enabling "garbage collection" of unused input sections.
This can be used to eliminate unused coding from native libraries (especially 
when already compiling the objects with compiler flags -ffunction-sections 
-fdata-sections .
See for details the --gc-sections and --print-gc-sections parts of the ld 
documentation :

https://linux.die.net/man/1/ld


We had this enabled already  for  linux s390x ,  with 
https://bugs.openjdk.java.net/browse/JDK-8234525
8234525: enable link-time section-gc for linux s390x to remove unused code .

This  time we enable it too for  the other linux platforms .

For the other platforms I do not enable it for JVM, just for the JDK libs.  The 
reason is that the serviceability agent  (not supported on linux s390x )is 
not  (yet) ready for the optimization .
Below you see the results , for some libraries  a significant  size reduction 
can be achieved .


Results from linux x86_64 product builds :

without / with ltgc

320K / 300K/images/jdk/lib/libsunec.so   <-
36K  / 36K /images/jdk/lib/libdt_socket.so
280K / 276K   /images/jdk/lib/libjdwp.so
23M  / 23M/images/jdk/lib/server/libjvm.so< not set for libjvm.so 
for x86_64
16K  / 16K/images/jdk/lib/server/libjsig.so
72K  / 72M/images/jdk/lib/libverify.so
84K  / 84M   /images/jdk/lib/libjli.so
16K  / 16K/images/jdk/lib/libjsig.so
196K / 196K   /images/jdk/lib/libjava.so
44K  / 44K/images/jdk/lib/libzip.so
144K / 136K   /images/jdk/lib/libjimage.so
112K / 112K   /images/jdk/lib/libnet.so
100K / 100K   /images/jdk/lib/libnio.so
36K  / 36K/images/jdk/lib/libsctp.so
576K / 556K   /images/jdk/lib/libmlib_image.so
752K / 752K   /images/jdk/lib/libawt.so
260K / 252K   /images/jdk/lib/libjavajpeg.so
784K / 784K   /images/jdk/lib/libfreetype.so
368K / 236K /images/jdk/lib/libsplashscreen.so   <-
88K / 88K/images/jdk/lib/libjsound.so
472K / 468K/images/jdk/lib/libawt_xawt.so
564K / 404K   /images/jdk/lib/liblcms.so <--
48K / 48K/images/jdk/lib/libawt_headless.so
12K / 12K/images/jdk/lib/libjawt.so
1.5M / 900K   /images/jdk/lib/libfontmanager.so  <--
12K / 12K/images/jdk/lib/libjaas.so
92K / 92K/images/jdk/lib/libj2pkcs11.so
16K / 16K/images/jdk/lib/libattach.so
8.0K / 8.0K   /images/jdk/lib/librmi.so
56K / 56K/images/jdk/lib/libinstrument.so
16K / 16K/images/jdk/lib/libprefs.so
52K / 52K/images/jdk/lib/libj2gss.so
12K / 12K/images/jdk/lib/libmanagement_agent.so
36K / 32K/images/jdk/lib/libmanagement.so
16K / 16K/images/jdk/lib/libextnet.so
20K / 20K/images/jdk/lib/libj2pcsc.so
40K / 40K/images/jdk/lib/libmanagement_ext.so
60K / 60K/images/jdk/lib/libsaproc.so


Bug/webrev :

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

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


Thanks, Matthias

RE: serviceability agent : problems when using gcc LTO (link time optimization)

[Baesken, Matthias]

Hi Magnus, thanks for the info , I already noticed yesterday the setting for 
arm-32 in the minimal build .
Do you think  we could set it too for the other Linux platforms  in the minimal 
build  ( serviceability agent is not supported there as well so the  observed 
issue wouldn’t be a problem).

Best regards, Matthias




On 2020-01-10 11:01, Baesken, Matthias wrote:

Hello,   I recently looked into  the  gcc  lto  optimization mode (see for some 
details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html  and  
http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html  
).

This mode can lead to more compact binaries (~10% smaller)  , it also might 
bring  small performance improvements  but that wasn't my (main)  goal  .



The changes for this are rather small , one needs to use a recent gcc  , add  
-flto   to the compile flags  , for example



--- a/make/autoconf/flags-cflags.m4  Wed Jan 01 03:08:45 2020 +0100

+++ b/make/autoconf/flags-cflags.m4   Wed Jan 08 17:39:10 2020 +0100

@@ -530,8 +530,13 @@

   fi

   if test "x$TOOLCHAIN_TYPE" = xgcc; then

-TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector"

-TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector"

+TOOLCHAIN_CFLAGS_JVM="$TOOLCHAIN_CFLAGS_JVM -fcheck-new -fstack-protector 
-flto"

+TOOLCHAIN_CFLAGS_JDK="-pipe -fstack-protector -flto"



   and you have to make sure  to use  gcc-ar  and  gcc-nm instead   of  ar 
/ nm .

Build and test(s)  work,  however with  one exception.

The  serviceability   tests like  serviceability/sa   seems to rely   heavily  
on the "normal"   structure  of   libjvm.so   (from what I   understand  e.g. 
in  LinuxVtblAccess  it is attempted to access  internal symbols  like  _ZTV ).



Errors in the sa  tests look like :





java.lang.InternalError: Metadata does not appear to be polymorphic

 at 
jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:279)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:96)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)

 at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:262)

 at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:225)

 at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)

 at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:176)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:321)

 at 
jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406)



Has anyone experimented with LTO optimization ?

Hi Matthias,

We used to have LTO enabled on the old, closed-source Oracle arm-32 builds. 
There is still a "link-time-opt" JVM feature present; afaik it still works and 
adds the -flto flag. The main drawback of this is the *extremely* long link 
times of libjvm.so.

I don't think servicability was ever supported for that platform, so I'm not 
surprised this does not work.

/Magnus







And to the  serviceability   agent experts -  any idea  how to make the  
jdk.hotspot.agent   more independent from  optimization settings ?





Best regards, Matthias

RE: RFR [XS]: 8236274: remove obsolete -d2Zi+ debug flag in MSVC builds

[Baesken, Matthias]

Thanks for the reviews !


Best regards, Matthias


> 
> Hi,
> 
> I don't think another review is needed, but FWIW this looks good to
> me!
> 
> /Claes
> 
> On 2019-12-20 11:03, Baesken, Matthias wrote:
> > Hi Erik,   thanks for the review !  I'll remove the comment line .
> >
> > May I get a second review ?
> >
> > Best regards, Matthias
> >
> >>
> >> Hello Matthias,
> >>
> >> Looks good except for the comment. There is no need to add a comment
> for
> >> something that has been removed, it will just look confusing.
> >> Documenting it in the JBS issue is enough.
> >>
> >> Thanks for cleaning this up!

RE: RFR [XS]: 8236274: remove obsolete -d2Zi+ debug flag in MSVC builds

[Baesken, Matthias]

Hi Erik,   thanks for the review !  I'll remove the comment line .

May I get a second review ?

Best regards, Matthias

> 
> Hello Matthias,
> 
> Looks good except for the comment. There is no need to add a comment for
> something that has been removed, it will just look confusing.
> Documenting it in the JBS issue is enough.
> 
> Thanks for cleaning this up!
> 
> /Erik
> 
> On 2019-12-20 09:37, Baesken, Matthias wrote:
> > Hello, please review this small MSVC related change .
> >
> > The MSVC based builds still have the old flag -d2Zi+ set; this is  an
> undocumented flag , the name of the flag  for enhanced optimized
> debugging  is since VS2013 -Zo .
> > However the flag (-Zo)  is enabled by default for a long time , so   the old
> undocumented version  of it ("-d2Zi+") should be  removed completely.
> >
> >
> > See the VS2017 documentation :
> > https://docs.microsoft.com/en-us/cpp/build/reference/zo-enhance-
> optimized-debugging?view=vs-2017
> >
> > "The /Zo option is enabled by default in Visual Studio when you specify
> debugging information with /Zi or /Z7. Specify /Zo- to explicitly disable this
> compiler option.
> > The /Zo switch is available starting in Visual Studio 2013 Update 3, and it
> replaces the previously undocumented /d2Zi+ switch."
> >
> >
> > Bug/webrev :
> > https://bugs.openjdk.java.net/browse/JDK-8236274
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236274.0/
> >
> >
> > Thanks, Matthias
> >
> >
> >

RFR [XS]: 8236274: remove obsolete -d2Zi+ debug flag in MSVC builds

[Baesken, Matthias]

Hello, please review this small MSVC related change .

The MSVC based builds still have the old flag -d2Zi+ set; this is  an 
undocumented flag , the name of the flag  for enhanced optimized debugging  is 
since VS2013 -Zo .
However the flag (-Zo)  is enabled by default for a long time , so   the old  
undocumented version  of it ("-d2Zi+") should be  removed completely.


See the VS2017 documentation :
https://docs.microsoft.com/en-us/cpp/build/reference/zo-enhance-optimized-debugging?view=vs-2017

"The /Zo option is enabled by default in Visual Studio when you specify 
debugging information with /Zi or /Z7. Specify /Zo- to explicitly disable this 
compiler option.
The /Zo switch is available starting in Visual Studio 2013 Update 3, and it 
replaces the previously undocumented /d2Zi+ switch."


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

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


Thanks, Matthias

RFR [XS] jdk11 - 8234809: set relro in linker flags when building with gcc

[Baesken, Matthias]

Hello,  please review  the jdk11 downport of  8234809 .

The patch form jdk/jdk  did not apply  directly   so  
make/autoconf/flags-ldflags.m4   had to be adjusted a little bit for jdk11 .

Original discussion :

https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026347.html

+

https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026365.html



Bug/ jdk11 webrev :

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

http://cr.openjdk.java.net/~mbaesken/webrevs/8234809_jdk11.0/

Thanks, Matthias

RE: RE: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

  *   I compiled with clang since I'm on Mac.
  *

Thanks for clarifying, that’s what I thought .

(btw I wonder how much effect  profile guided optimization would bring in your 
experiments )



  *   My opinion is that there are probably more compelling alternatives if 
reducing binary size is the goal. Even if the tests show that Os/O2 is no 
different than O3,
  *   who knows if this will be true in the future.
  *

What alternatives do you have in mind ?

Best regards, Matthias


From: August Nagro 
Sent: Mittwoch, 18. Dezember 2019 14:42
To: Baesken, Matthias 
Cc: claes.redes...@oracle.com; Doerr, Martin ; 
erik.joels...@oracle.com; build-dev@openjdk.java.net; 
hotspot-...@openjdk.java.net
Subject: Re: RE: building libjvm with -Os for space optimization - was : RE: 
RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

I compiled with clang since I'm on Mac.

The Renaissance benchmark suite is also a good one that I learned about 
recently.

My opinion is that there are probably more compelling alternatives if reducing 
binary size is the goal. Even if the tests show that Os/O2 is no different than 
O3, who knows if this will be true in the future.

Regards,

- August

On Wed, Dec 18, 2019, 1:58 AM Baesken, Matthias 
mailto:matthias.baes...@sap.com>> wrote:
Hi August , thanks for pointing to your webpage,  very interesting !

We did our builds+tests/benchmarks  with  gcc  7.4.0   , what compiler+version 
did you use?

Probably I should look a bit more into Dacapo (we used that one in the past too 
sometimes).

Best regards, Matthias


>
> I published some benchmarks of OpenJDK on Mac with Ofast and O3 [1].
> Some microbenchmarks like Netty’s HttpObjectEncoder experienced >100%
> speedup with O3, and the more real-world Dacapo suite was ~15%
> improvement over O2 (which is exactly the same as Os). I did include a few
> other flags, however the speedup was primarily due to optimization level.
>
> Building with Os is the old wisdom. It used to be the case that many programs
> would be faster with the smaller binary size, but this is almost never the 
> case
> nowadays.
>
> - August
>
> [1]: http://august.nagro.us/optimized-openjdk.html

RE: RE: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hi August , thanks for pointing to your webpage,  very interesting !  

We did our builds+tests/benchmarks  with  gcc  7.4.0   , what compiler+version 
did you use?

Probably I should look a bit more into Dacapo (we used that one in the past too 
sometimes).

Best regards, Matthias


> 
> I published some benchmarks of OpenJDK on Mac with Ofast and O3 [1].
> Some microbenchmarks like Netty’s HttpObjectEncoder experienced >100%
> speedup with O3, and the more real-world Dacapo suite was ~15%
> improvement over O2 (which is exactly the same as Os). I did include a few
> other flags, however the speedup was primarily due to optimization level.
> 
> Building with Os is the old wisdom. It used to be the case that many programs
> would be faster with the smaller binary size, but this is almost never the 
> case
> nowadays.
> 
> - August
> 
> [1]: http://august.nagro.us/optimized-openjdk.html

RE: building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hello,  a small update from my side .   I had  (on Linux)  for a couple of days 
our  jdk11u  tests + benchmarks  running with -Os instead of  the usual 
settings (-O3) .
With have  (independent of  -Os  /  -O3)   a bit of variance in our benchmarks  
( jbb15  , jvm2008, jvm98 ) .

However the benchmark results  of  -Os  vs.  -O3 were comparable .


>we discussed doing the opposite for Mac OS X recently, where builds are
>currently set to -Os by default. -O3 helped various networking
>(micro)benchmarks by up to 20%.


What microbenchmarks do you have in mind  that show  much better performance 
with -O3  compared to -Os  ?

Best regards, Matthias

> 
> Hi Martin,
> 
> On 2019-11-27 19:03, Doerr, Martin wrote:
> > Hi Claes,
> >
> > that kind of surprises me. I'd expect files which rather benefit from -O3 to
> be far less than those which benefit from -Os.
> > Most performance critical code lives inside the code cache and is not
> dependent on C++ compiler optimizations.
> > I'd expect GC code, C2's register allocation and a few runtime files to be 
> > the
> most performance critical C++ code.
> > So the list of files for -Os may become long.
> 
> that might very well be the end result, and once/if we've gone down this
> path long enough to see that -O3 becomes the exception, we can re-
> examine the default. Changing the default and then trying to recuperate
> would be hard/impossible to do incrementally.
> 
> >
> > Yeah, I think we should use native profiling information to find out what's
> really going on >
> > Your idea to change file by file and check for performance regression
> makes sense to me, though
> Hopefully we don't have to do one RFE per file.. :-)
> 
> /Claes

building libjvm with -Os for space optimization - was : RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hello Martin,  I checked  building  libjvm.so  with -Os  (instead of -O3) .

I used gcc-7  on linux x86_64 .
The size  of  libjvm.so   dropped   from24M  (normal night make with -O3)  
to   18M   ( test make with -Os)   .
 (adding the link-time gc might  reduce the size by another ~ 10 % ,  but those 
2 builds were without the ltgc )

Cannot say much so far about performance impact .

Best regards, Matthias



> 
> Hi Matthias and Erik,
> 
> I also think this is an interesting option.
> 
> I like the idea to generate smaller libraries. In addition to that, I could 
> also
> imagine building with -Os (size optimized) by default and only select -O3 for
> performance critical files (e.g. C2's register allocation, some gc code, ...).
> 
> If we want to go into such a direction for all linux platforms and want to use
> this s390 only change as some kind of pipe cleaner, I think this change is 
> fine
> and can get pushed.
> Otherwise, I think building s390 differently and not intending to do the same
> for other linux platforms would be not so good.
> 
> We should only make sure the exported symbols are set up properly to avoid
> that this optimization throws out too much.
> 
> My 50 Cents.
> 
> Best regards,
> Martin
> 

RE: RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro)

[Baesken, Matthias]

Thanks !

Florian, may I add you as reviewer  ?


Best regards, Matthias



> Looks good.
> 
> /Erik
> 
> On 2019-11-26 05:07, Baesken, Matthias wrote:
> >> Hello Erik, Florian ,  currently   relro  is set already  for libjvm.
> >> I think if this works nicely  for libjvm, it shouldn't do any harm to set 
> >> it as
> well
> >> in the BASIC_LDFLAGS  for other binaries .
> >> I would propose a patch like :
> > Hello,  here is my webrev , please review .
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8234809
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8234809.0/
> >
> >
> > Thanks, Matthias
> >
> >>> I would  involve at least hotspot-dev for a wider discussion on this as
> libjvm
> >> is
> >>> the most affected library.
> >> Hello Erik, Florian ,  currently   relro  is set already  for libjvm.
> >> I think if this works nicely  for libjvm, it shouldn't do any harm to set 
> >> it as
> well
> >> in the BASIC_LDFLAGS  for other binaries .
> >> I would propose a patch like :
> >>
> >> diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4
> >> --- a/make/autoconf/flags-ldflags.m4Fri Nov 22 09:06:35 2019 -0500
> >> +++ b/make/autoconf/flags-ldflags.m4Tue Nov 26 13:05:42 2019 +0100
> >> @@ -70,10 +70,9 @@
> >>   fi
> >>
> >>   # Add -z defs, to forbid undefined symbols in object files.
> >> -BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
> >> -
> >> -BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"
> >> -
> >> +# add relro (mark relocations read only) for all libs
> >> +BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro"
> >> +BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1"
> >>
> >>
> >> If I understand
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1571359
> >> correct, RedHat is setting those flags already  via the build system .
> >>
> >> Regarding  "bindnow"  (ld -z now) ,   this might be set  additionally   by
> using --
> >> with-extra-ldflags .
> >>
> >>
> >> Best regards, Matthias
> >>
> >>
> >>> Hello,
> >>>
> >>> I wasn't directly involved in introducing these flags, but my
> >>> understanding is that it's always a performance compromise. I would
> >>> involve at least hotspot-dev for a wider discussion on this as libjvm is
> >>> the most affected library.
> >>>
> >>> /Erik
> >>>
> >>> On 2019-11-25 06:42, Baesken, Matthias wrote:
> >>>> Hello,   I wonder why  the  binary hardening  on linux  using Relocation
> >>> Read-Only (relro)  is not enabled by default.
> >>>> Some info can be found here :
> >>>>
> >>>> https://wiki.debian.org/Hardening
> >>>>
> >>>> https://www.redhat.com/en/blog/hardening-elf-binaries-using-
> >>> relocation-read-only-relro
> >>>>
> >>>> Currently I  notice  the settings only  for debug  / fastdebug builds , 
> >>>> see
> >>> flags-ldflags.m4 :
> >>>> # Setup debug level-dependent LDFLAGS
> >>>> if test "x$TOOLCHAIN_TYPE" = xgcc; then
> >>>>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
> >>>> if test x$DEBUG_LEVEL = xrelease; then
> >>>>
> >>>
> DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY -
> >>> Wl,-O1"
> >>>> else
> >>>>   # mark relocations read only on (fast/slow) debug builds
> >>>>   DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro"
> >>>> fi
> >>>> if test x$DEBUG_LEVEL = xslowdebug; then
> >>>>   # do relocations at load
> >>>>   DEBUGLEVEL_LDFLAGS="-Wl,-z,now"
> >>>> fi
> >>>>   fi
> >>>>
> >>>> Shouldn't we use  at least  "-Wl,-z,relro" also on product builds ?
> >>>>
> >>>> For  "-Wl,-z,now"   some  startup  performance hits are mentioned in
> >>> articles/blogs -  any experiences / performance-measurements   with
> this
> >> in
> >>> the OpenJDK  context ?
> >>>> Best regards, Matthias
> >>>>

RFR [XS] 8234809: set relro in linker flags when building with gcc - was RE: binary Hardening on linux using Relocation Read-Only (relro)

[Baesken, Matthias]

> Hello Erik, Florian ,  currently   relro  is set already  for libjvm.
> I think if this works nicely  for libjvm, it shouldn't do any harm to set it 
> as well
> in the BASIC_LDFLAGS  for other binaries .
> I would propose a patch like :

Hello,  here is my webrev , please review .

Bug/webrev :

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

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


Thanks, Matthias

> 
> > I would  involve at least hotspot-dev for a wider discussion on this as 
> > libjvm
> is
> > the most affected library.
> 
> Hello Erik, Florian ,  currently   relro  is set already  for libjvm.
> I think if this works nicely  for libjvm, it shouldn't do any harm to set it 
> as well
> in the BASIC_LDFLAGS  for other binaries .
> I would propose a patch like :
> 
> diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4
> --- a/make/autoconf/flags-ldflags.m4Fri Nov 22 09:06:35 2019 -0500
> +++ b/make/autoconf/flags-ldflags.m4Tue Nov 26 13:05:42 2019 +0100
> @@ -70,10 +70,9 @@
>  fi
> 
>  # Add -z defs, to forbid undefined symbols in object files.
> -BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
> -
> -BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"
> -
> +# add relro (mark relocations read only) for all libs
> +BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro"
> +BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1"
> 
> 
> If I understand
> https://bugzilla.redhat.com/show_bug.cgi?id=1571359
> correct, RedHat is setting those flags already  via the build system .
> 
> Regarding  "bindnow"  (ld -z now) ,   this might be set  additionally   by 
> using --
> with-extra-ldflags .
> 
> 
> Best regards, Matthias
> 
> 
> > Hello,
> >
> > I wasn't directly involved in introducing these flags, but my
> > understanding is that it's always a performance compromise. I would
> > involve at least hotspot-dev for a wider discussion on this as libjvm is
> > the most affected library.
> >
> > /Erik
> >
> > On 2019-11-25 06:42, Baesken, Matthias wrote:
> > > Hello,   I wonder why  the  binary hardening  on linux  using Relocation
> > Read-Only (relro)  is not enabled by default.
> > >
> > > Some info can be found here :
> > >
> > > https://wiki.debian.org/Hardening
> > >
> > > https://www.redhat.com/en/blog/hardening-elf-binaries-using-
> > relocation-read-only-relro
> > >
> > >
> > > Currently I  notice  the settings only  for debug  / fastdebug builds , 
> > > see
> > flags-ldflags.m4 :
> > >
> > ># Setup debug level-dependent LDFLAGS
> > >if test "x$TOOLCHAIN_TYPE" = xgcc; then
> > >  if test "x$OPENJDK_TARGET_OS" = xlinux; then
> > >if test x$DEBUG_LEVEL = xrelease; then
> > >
> > DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY -
> > Wl,-O1"
> > >else
> > >  # mark relocations read only on (fast/slow) debug builds
> > >  DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro"
> > >fi
> > >if test x$DEBUG_LEVEL = xslowdebug; then
> > >  # do relocations at load
> > >  DEBUGLEVEL_LDFLAGS="-Wl,-z,now"
> > >fi
> > >  fi
> > >
> > > Shouldn't we use  at least  "-Wl,-z,relro" also on product builds ?
> > >
> > > For  "-Wl,-z,now"   some  startup  performance hits are mentioned in
> > articles/blogs -  any experiences / performance-measurements   with this
> in
> > the OpenJDK  context ?
> > >
> > > Best regards, Matthias
> > >

RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hi Martin , 

> Hi Matthias and Erik,
> 
> I also think this is an interesting option.
> 
> I like the idea to generate smaller libraries. In addition to that, I could 
> also
> imagine building with -Os (size optimized) by default and only select -O3 for
> performance critical files (e.g. C2's register allocation, some gc code, ...).
> 

This is a good idea .   However I would like to look into this separately in 
another change .
 ( Maybe  there should also be a configure setting  to select for size vs. 
speed optimization )


> If we want to go into such a direction for all linux platforms and want to use
> this s390 only change as some kind of pipe cleaner, I think this change is 
> fine
> and can get pushed.

Yes , that  was my intention.
Erik, may I add you as  a reviewer too  ?

Best regards, Matthias


> Otherwise, I think building s390 differently and not intending to do the same
> for other linux platforms would be not so good.
> 
> We should only make sure the exported symbols are set up properly to avoid
> that this optimization throws out too much.
> 
> My 50 Cents.
> 
> Best regards,
> Martin
> 

RE: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system

[Baesken, Matthias]

Thanks for the update on this .
Do you plan to push it  today or tomorrow ?

Best regards, Matthias


> -Original Message-
> From: Prasanta Sadhukhan 
> Sent: Dienstag, 26. November 2019 10:26
> To: Baesken, Matthias ; Erik Joelsson
> ; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>
> Cc: 2d-...@openjdk.java.net; Lindenmaier, Goetz
> 
> Subject: Re: RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after
> 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with
> backslashes on macOS/JIS keyboard: Java ignores system settings
> 
> I have already raised a similar fix sometime back for JDK-8234786
> 
> Regards
> 
> Prasanta
> 
> On 26-Nov-19 2:49 PM, Baesken, Matthias wrote:
> > Hello,  here is a small adjustment  that uses the typealias  for
> NSTextInputSourceIdentifier .   This fixes the build on macOS  < 10.13 .
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8234795
> >
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8234795.0/
> >
> >
> > Thanks, Matthias
> >
> >
> >> If there is a simple fix, I would very much like to see it done. I'm not
> >> familiar enough with this area to know what the implications would be
> >> though.
> >>
> >> /Erik
> >>
> >> On 2019-11-25 04:48, Baesken, Matthias wrote:
> >>> Hello,  any comments on the issue ?
> >>>
> >>> Could we maybe switch from using
> >>>
> >>> NSTextInputSourceIdentifier
> >>>
> >>> to
> >>>
> >>> String  (NSString* ?)   , because
> >>
> https://developer.apple.com/documentation/appkit/nstextinputsourceiden
> >> tifier
> >>> says  NSTextInputSourceIdentifieris a typealias for String  ?
> >>>
> >>> Best regards ,Matthias
> >>>
> >>>
> >>>
> >>>
> >>> Hello, I noticed  that since today our  jdk/jdk  build fails on macOS . We
> run
> >> it on macOS 10.12 .
> >>> It seems
> >>> https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33
> >>>
> >>> 8214578: [macos] Problem with backslashes on macOS/JIS keyboard:
> Java
> >> ignores system settings
> >>> Brought a  dependency on 10.13.  Was that intended ? Could we keep
> 10.12
> >> compatibility ?
> >>> At least  the doc of  NSTextInputSourceIdentifier  :
> >>
> https://developer.apple.com/documentation/appkit/nstextinputsourceiden
> >> tifier
> >>> mentions  macOS 10.13+  .
> >>>
> >>>
> >>>
> >>> Build errors are :
> >>> 
> >>>
> >>>
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5:
> >> error: unknown type name 'NSTextInputSourceIdentifier'
> >>>   NSTextInputSourceIdentifier kbdLayout;
> >>>   ^
> >>>
> >>
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23:
> >> error: assignment to readonly property
> >>>   self.cglLayer = windowLayer;
> >>>   ~ ^ ~~~
> >>>
> >>
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1
> >> 9: error: assignment to readonly property
> >>>   self.cglLayer = nil;
> >>>   ~ ^ ~~~
> >>> 3 errors generated.
> >>>
> >>>
> >>> ...
> >>>
> >>
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45
> >> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL'
> (aka
> >> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion]
> >>>   BOOL mouseIsOver = [[window contentView] mouseIsOver];
> >>>^ ~~
> >>> 2 errors generated.
> >>>
> >>>
> >>>
> >>> Best regards, Matthias

RE: binary Hardening on linux using Relocation Read-Only (relro)

[Baesken, Matthias]

> I would  involve at least hotspot-dev for a wider discussion on this as 
> libjvm is
> the most affected library.

Hello Erik, Florian ,  currently   relro  is set already  for libjvm.
I think if this works nicely  for libjvm, it shouldn't do any harm to set it as 
well   in the BASIC_LDFLAGS  for other binaries .
I would propose a patch like :

diff -r 80e1201f6c9a make/autoconf/flags-ldflags.m4
--- a/make/autoconf/flags-ldflags.m4Fri Nov 22 09:06:35 2019 -0500
+++ b/make/autoconf/flags-ldflags.m4Tue Nov 26 13:05:42 2019 +0100
@@ -70,10 +70,9 @@
 fi
 
 # Add -z defs, to forbid undefined symbols in object files.
-BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs"
-
-BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1 -Wl,-z,relro"
-
+# add relro (mark relocations read only) for all libs
+BASIC_LDFLAGS="$BASIC_LDFLAGS -Wl,-z,defs -Wl,-z,relro"
+BASIC_LDFLAGS_JVM_ONLY="-Wl,-O1"


If I understand 
https://bugzilla.redhat.com/show_bug.cgi?id=1571359
correct, RedHat is setting those flags already  via the build system .

Regarding  "bindnow"  (ld -z now) ,   this might be set  additionally   by 
using --with-extra-ldflags .


Best regards, Matthias


> Hello,
> 
> I wasn't directly involved in introducing these flags, but my
> understanding is that it's always a performance compromise. I would
> involve at least hotspot-dev for a wider discussion on this as libjvm is
> the most affected library.
> 
> /Erik
> 
> On 2019-11-25 06:42, Baesken, Matthias wrote:
> > Hello,   I wonder why  the  binary hardening  on linux  using Relocation
> Read-Only (relro)  is not enabled by default.
> >
> > Some info can be found here :
> >
> > https://wiki.debian.org/Hardening
> >
> > https://www.redhat.com/en/blog/hardening-elf-binaries-using-
> relocation-read-only-relro
> >
> >
> > Currently I  notice  the settings only  for debug  / fastdebug builds , see
> flags-ldflags.m4 :
> >
> ># Setup debug level-dependent LDFLAGS
> >if test "x$TOOLCHAIN_TYPE" = xgcc; then
> >  if test "x$OPENJDK_TARGET_OS" = xlinux; then
> >if test x$DEBUG_LEVEL = xrelease; then
> >
> DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY -
> Wl,-O1"
> >else
> >  # mark relocations read only on (fast/slow) debug builds
> >  DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro"
> >fi
> >if test x$DEBUG_LEVEL = xslowdebug; then
> >  # do relocations at load
> >  DEBUGLEVEL_LDFLAGS="-Wl,-z,now"
> >fi
> >  fi
> >
> > Shouldn't we use  at least  "-Wl,-z,relro" also on product builds ?
> >
> > For  "-Wl,-z,now"   some  startup  performance hits are mentioned in
> articles/blogs -  any experiences / performance-measurements   with this in
> the OpenJDK  context ?
> >
> > Best regards, Matthias
> >

RFR [XS]: 8234795: ix build fails on macOS lower than 10.13 after 8214578 was: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system se

[Baesken, Matthias]

Hello,  here is a small adjustment  that uses the typealias  for 
NSTextInputSourceIdentifier .   This fixes the build on macOS  < 10.13 .
   

Bug/webrev :

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


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


Thanks, Matthias


> 
> If there is a simple fix, I would very much like to see it done. I'm not
> familiar enough with this area to know what the implications would be
> though.
> 
> /Erik
> 
> On 2019-11-25 04:48, Baesken, Matthias wrote:
> > Hello,  any comments on the issue ?
> >
> > Could we maybe switch from using
> >
> > NSTextInputSourceIdentifier
> >
> > to
> >
> > String  (NSString* ?)   , because
> https://developer.apple.com/documentation/appkit/nstextinputsourceiden
> tifier
> >
> > says  NSTextInputSourceIdentifieris a typealias for String  ?
> >
> > Best regards ,Matthias
> >
> >
> >
> >
> > Hello, I noticed  that since today our  jdk/jdk  build fails on macOS . We 
> > run
> it on macOS 10.12 .
> >
> > It seems
> > https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33
> >
> > 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java
> ignores system settings
> >
> > Brought a  dependency on 10.13.  Was that intended ? Could we keep 10.12
> compatibility ?
> > At least  the doc of  NSTextInputSourceIdentifier  :
> https://developer.apple.com/documentation/appkit/nstextinputsourceiden
> tifier
> > mentions  macOS 10.13+  .
> >
> >
> >
> > Build errors are :
> > 
> >
> > /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5:
> error: unknown type name 'NSTextInputSourceIdentifier'
> >  NSTextInputSourceIdentifier kbdLayout;
> >  ^
> >
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23:
> error: assignment to readonly property
> >  self.cglLayer = windowLayer;
> >  ~ ^ ~~~
> >
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:1
> 9: error: assignment to readonly property
> >  self.cglLayer = nil;
> >  ~ ^ ~~~
> > 3 errors generated.
> >
> >
> > ...
> >
> /jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:45
> 4:18: error: incompatible pointer to integer conversion initializing 'BOOL' 
> (aka
> 'signed char') with an expression of type 'id' [-Werror,-Wint-conversion]
> >  BOOL mouseIsOver = [[window contentView] mouseIsOver];
> >   ^ ~~
> > 2 errors generated.
> >
> >
> >
> > Best regards, Matthias

binary Hardening on linux using Relocation Read-Only (relro)

[Baesken, Matthias]

Hello,   I wonder why  the  binary hardening  on linux  using Relocation 
Read-Only (relro)  is not enabled by default.

Some info can be found here :

https://wiki.debian.org/Hardening

https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro


Currently I  notice  the settings only  for debug  / fastdebug builds , see  
flags-ldflags.m4 :

  # Setup debug level-dependent LDFLAGS
  if test "x$TOOLCHAIN_TYPE" = xgcc; then
if test "x$OPENJDK_TARGET_OS" = xlinux; then
  if test x$DEBUG_LEVEL = xrelease; then
DEBUGLEVEL_LDFLAGS_JDK_ONLY="$DEBUGLEVEL_LDFLAGS_JDK_ONLY -Wl,-O1"
  else
# mark relocations read only on (fast/slow) debug builds
DEBUGLEVEL_LDFLAGS_JDK_ONLY="-Wl,-z,relro"
  fi
  if test x$DEBUG_LEVEL = xslowdebug; then
# do relocations at load
DEBUGLEVEL_LDFLAGS="-Wl,-z,now"
  fi
fi

Shouldn't we use  at least  "-Wl,-z,relro" also on product builds ?

For  "-Wl,-z,now"   some  startup  performance hits are mentioned in 
articles/blogs -  any experiences / performance-measurements   with this in the 
OpenJDK  context ?

Best regards, Matthias

RE: build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings

[Baesken, Matthias]

Hello,  any comments on the issue ?

Could we maybe switch from using

NSTextInputSourceIdentifier

to

String  (NSString* ?)   , because 
https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier

says  NSTextInputSourceIdentifieris a typealias for String  ?

Best regards ,Matthias




Hello, I noticed  that since today our  jdk/jdk  build fails on macOS . We run 
it on macOS 10.12 .

It seems
https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33

8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores 
system settings

Brought a  dependency on 10.13.  Was that intended ? Could we keep 10.12  
compatibility ?
At least  the doc of  NSTextInputSourceIdentifier  :   
https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier
mentions  macOS 10.13+  .



Build errors are :


/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: error: 
unknown type name 'NSTextInputSourceIdentifier'
NSTextInputSourceIdentifier kbdLayout;
^
/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: error: 
assignment to readonly property
self.cglLayer = windowLayer;
~ ^ ~~~
/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:19: error: 
assignment to readonly property
self.cglLayer = nil;
~ ^ ~~~
3 errors generated.


...
/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:454:18: error: 
incompatible pointer to integer conversion initializing 'BOOL' (aka 'signed 
char') with an expression of type 'id' [-Werror,-Wint-conversion]
BOOL mouseIsOver = [[window contentView] mouseIsOver];
 ^ ~~
2 errors generated.



Best regards, Matthias

RE: RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hi Erik, 
   yes it makes the build more chatty -
our   linux s390   product   build  log  of  jdk/jdk   goes from  ~ 60.000  
lines to  ~ 123.000  lines with the patch. 

However the change  is  linux s390 only so I guess it will not disturb other 
people ( in case we bring it to more platforms later on, we could remove the 
printing or make it configurable ).

Additionally the "chatty" output  is used currently for eliminating   unused  
functions + datacross-platform  
(see for example   https://bugs.openjdk.java.net/browse/JDK-8234629  ).

Best regards, Matthias



> 
> Hello Matthias,
> 
> This looks like an interesting change. If you want to enable this for
> s390x, I'm ok with it. If it works out well, perhaps we can find a way
> to expand this to other architectures.
> 
> Do you really want to set --print-gc-sections by default? I would assume
> that makes the build quite chatty.
> 
> /Erik
> 
> On 2019-11-21 00:54, Baesken, Matthias wrote:
> > Hello,
> >
> > gcc and ld can be instructed to work together to "garbage collect" unused
> input sections.
> > This feature eliminates unused code from native libraries. As a prerequisite
> to take full advantage of the feature,
> > the source files need to be compiled with "-ffunction-sections -fdata-
> sections".
> >
> > Details on what happens can be found in the ld documentation:
> https://linux.die.net/man/1/ld .
> > See the description of --gc-sections and --print-gc-sections therein.
> > For more detailed insights there is a talk available from ELC2010:
> https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
> >
> > My change enables the unused code elimination on linux s390x .
> > (on the other Linux platforms, there are still issues to be solved with the
> serviceability agent, but we do not have the serviceability agent  on linux
> s390x).
> >
> > The change has 2 benefits :
> > - native libs with unused code get smaller (some get alot smaller)
> > some example lib sizes  from  linuxs390x (product build) :
> >  default settings  / link-time gc-sections
> > libmlib_image.so556K 536K
> > libjavajpeg.so  300K 292K
> > libsplashscreen.so  412K 268K
> > libfontmanager.so   1.4M 864K
> > libjvm.so19M  17M
> >
> > - the flag --print-gc-sections  outputs the removed sections when calling
> the linker;
> > this helps a lot to find coding "waiting for" cross-platform removal.
> >
> >
> > Here is an example output of --print-gc-sections for the libnet-build (linux
> s390x) :
> >
> > /bin/ld: Removing unused section '.bss.my_gconf_init_func' in file
> '/builddir/support/native/java.base/libnet/DefaultProxySelector.o'  <---
> seems to be dead
> > /bin/ld: Removing unused section '.text.NET_ReadV' in file
> '/builddir/support/native/java.base/libnet/linux_close.o'   
> <--- seems
> to be dead, I requested cross-platform removal with
> https://bugs.openjdk.java.net/browse/JDK-8234501
> > /bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in
> file '/builddir/support/native/java.base/libnet/net_util.o'<--- seems to 
> be
> dead
> > /bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in
> file '/builddir/support/native/java.base/libnet/net_util.o'<--- seems to 
> be
> dead
> > /bin/ld: Removing unused section '.text.getInetAddress_hostName' in file
> '/builddir/support/native/java.base/libnet/net_util.o'<--- seems to be
> dead
> > /bin/ld: Removing unused section '.text.setDefaultScopeID' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'   <--- 
> seems to
> be dead indeed
> > /bin/ld: Removing unused section '.text.getDefaultScopeID' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'   <--- 
> seems to
> be dead indeed
> > /bin/ld: Removing unused section '.text.kernelIsV24' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o' <---
> seems to be dead indeed
> > /bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'   <--- only used
> in getDefaultScopeID , which is dead
> > /bin/ld: Removing unused section '.bss.ni_class.8721' in file
> '/builddir/support/native/java.base/libnet/net_util_md.o'<--- 
> only
> used in getDefaultScopeID , which is dead
> > /bin/ld: Removing unused section '.bss.vinit2

build fails on macOS 10.12 after 8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings

[Baesken, Matthias]

Hello, I noticed  that since today our  jdk/jdk  build fails on macOS . We run 
it on macOS 10.12 .

It seems
https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33

8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores 
system settings

Brought a  dependency on 10.13.  Was that intended ? Could we keep 10.12  
compatibility ?
At least  the doc of  NSTextInputSourceIdentifier  :   
https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier
mentions  macOS 10.13+  .



Build errors are :


/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h:41:5: error: 
unknown type name 'NSTextInputSourceIdentifier'
NSTextInputSourceIdentifier kbdLayout;
^
/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:93:23: error: 
assignment to readonly property
self.cglLayer = windowLayer;
~ ^ ~~~
/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m:110:19: error: 
assignment to readonly property
self.cglLayer = nil;
~ ^ ~~~
3 errors generated.


...
/jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m:454:18: error: 
incompatible pointer to integer conversion initializing 'BOOL' (aka 'signed 
char') with an expression of type 'id' [-Werror,-Wint-conversion]
BOOL mouseIsOver = [[window contentView] mouseIsOver];
 ^ ~~
2 errors generated.



Best regards, Matthias

RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

[Baesken, Matthias]

Hello,

gcc and ld can be instructed to work together to "garbage collect" unused input 
sections.
This feature eliminates unused code from native libraries. As a prerequisite to 
take full advantage of the feature,
the source files need to be compiled with "-ffunction-sections -fdata-sections".

Details on what happens can be found in the ld documentation: 
https://linux.die.net/man/1/ld .
See the description of --gc-sections and --print-gc-sections therein.
For more detailed insights there is a talk available from ELC2010: 
https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf

My change enables the unused code elimination on linux s390x .
(on the other Linux platforms, there are still issues to be solved with the 
serviceability agent, but we do not have the serviceability agent  on linux 
s390x).

The change has 2 benefits :
- native libs with unused code get smaller (some get alot smaller)
some example lib sizes  from  linuxs390x (product build) :
default settings  / link-time gc-sections
libmlib_image.so556K 536K
libjavajpeg.so  300K 292K
libsplashscreen.so  412K 268K
libfontmanager.so   1.4M 864K
libjvm.so19M  17M

- the flag --print-gc-sections  outputs the removed sections when calling the 
linker;
this helps a lot to find coding "waiting for" cross-platform removal.


Here is an example output of --print-gc-sections for the libnet-build (linux 
s390x) :

/bin/ld: Removing unused section '.bss.my_gconf_init_func' in file 
'/builddir/support/native/java.base/libnet/DefaultProxySelector.o'  <--- seems 
to be dead
/bin/ld: Removing unused section '.text.NET_ReadV' in file 
'/builddir/support/native/java.base/libnet/linux_close.o'   
<--- seems to be dead, I requested cross-platform removal with 
https://bugs.openjdk.java.net/browse/JDK-8234501
/bin/ld: Removing unused section '.text.getInet6Address_scopeifname' in file 
'/builddir/support/native/java.base/libnet/net_util.o'<--- seems to be dead
/bin/ld: Removing unused section '.text.getInet6Address_scopeid_set' in file 
'/builddir/support/native/java.base/libnet/net_util.o'<--- seems to be dead
/bin/ld: Removing unused section '.text.getInetAddress_hostName' in file 
'/builddir/support/native/java.base/libnet/net_util.o'<--- seems to be 
dead
/bin/ld: Removing unused section '.text.setDefaultScopeID' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o'   <--- seems 
to be dead indeed
/bin/ld: Removing unused section '.text.getDefaultScopeID' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o'   <--- seems 
to be dead indeed
/bin/ld: Removing unused section '.text.kernelIsV24' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o' <--- 
seems to be dead indeed
/bin/ld: Removing unused section '.bss.ni_defaultIndexID.8722' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o'   <--- only used 
in getDefaultScopeID , which is dead
/bin/ld: Removing unused section '.bss.ni_class.8721' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o'<--- 
only used in getDefaultScopeID , which is dead
/bin/ld: Removing unused section '.bss.vinit24' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o'  
<--- only used in kernelIsV24 which is dead
/bin/ld: Removing unused section '.bss.kernelV24' in file 
'/builddir/support/native/java.base/libnet/net_util_md.o'
<--- only used in kernelIsV24 which is dead

bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8234525

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

Thanks, Matthias

RE: 8233078 : fix minimal VM build on Linux ppc64(le)

[Baesken, Matthias]

Thanks for the reviews !

> One minor thing: do you really want to keep the old code (as comment) in
> sharedRuntime_ppc.cpp:2853?

I remove it .

Best regards, Matthias


> -Original Message-
> From: Schmidt, Lutz 
> Sent: Freitag, 1. November 2019 15:11
> To: Baesken, Matthias ; Doerr, Martin
> ; 'hotspot-...@openjdk.java.net'  d...@openjdk.java.net>
> Cc: 'build-dev@openjdk.java.net' 
> Subject: Re: 8233078 : fix minimal VM build on Linux ppc64(le)
> 
> Hi Matthias,
> 
> your changes look good to me. Please note, however, that I'm not a
> Reviewer.
> 
> One minor thing: do you really want to keep the old code (as comment) in
> sharedRuntime_ppc.cpp:2853?
> 
> Thanks for putting this straight.
> 
> Regards,
> Lutz
> 
> On 29.10.19, 14:32, "hotspot-dev on behalf of Baesken, Matthias"  dev-boun...@openjdk.java.net on behalf of matthias.baes...@sap.com>
> wrote:
> 
> Thanks .
> May I have a second review please ?
> 
> Best regards, Matthias
> 
> From: Doerr, Martin 
> Sent: Dienstag, 29. Oktober 2019 13:48
> To: Baesken, Matthias ; 'hotspot-
> d...@openjdk.java.net' 
> Cc: 'build-dev@openjdk.java.net' 
> Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
> 
> Hi Matthias,
> 
> > Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?
> This question is not related to this issue.
> Commenting out parts of it is not a good style.
> 
> Thank you for your update. The new webrev looks good to me.
> 
> Best regards,
> Martin
> 
> 
> From: Baesken, Matthias
> mailto:matthias.baes...@sap.com>>
> Sent: Dienstag, 29. Oktober 2019 13:25
> To: Doerr, Martin
> mailto:martin.do...@sap.com>>; 'hotspot-
> d...@openjdk.java.net' mailto:hotspot-
> d...@openjdk.java.net>>
> Cc: 'build-dev@openjdk.java.net'  d...@openjdk.java.net<mailto:build-dev@openjdk.java.net>>
> Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
> 
> Hi Martin,  thanks for the input .
> I  did the adjustments you suggested;  new webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.1/
> 
> Regarding  : stubGenerator_ppc.cpp: "Code should better be protected by
> #ifdef COMPILER2 than commenting out."
> Currently  the  if (OptimizeFill) { ... }coding  is dead on ppc  .
> 
> See  :
> c2_globals.hpp
> 
> 234 /* OptimizeFill not yet supported on PowerPC. */ \
> 235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \
> 
> c2_init_ppc.cpp
> 
> 53 if (OptimizeFill) {
> 54   warning("OptimizeFill is not supported on this CPU.");
> 55   FLAG_SET_DEFAULT(OptimizeFill, false);
> 
> 
> Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?
> 
> Best regards, Matthias
> 
> 
> 
> 
> Hi Matthias,
> 
> thanks for fixing it. I have a few requests:
> 
> disassembler_ppc.cpp:
> Please remove includes completely if no longer needed (instead of
> commenting out).
> 
> sharedRuntime_ppc.cpp:
> I think it's better to remove the 2 align(InteriorEntryAlignment).
> Succeeding code is not performance critical.
> 
> stubGenerator_ppc.cpp:
> Code should better be protected by #ifdef COMPILER2 than commenting
> out.
> 
> Otherwise, looks good to me.
> 
> Thanks,
> Martin
> 
> 
> From: Baesken, Matthias
> mailto:matthias.baes...@sap.com>>
> Sent: Dienstag, 29. Oktober 2019 12:42
> To: 'hotspot-...@openjdk.java.net'  d...@openjdk.java.net<mailto:hotspot-...@openjdk.java.net>>
> Cc: 'build-dev@openjdk.java.net'  d...@openjdk.java.net<mailto:build-dev@openjdk.java.net>>; Doerr,
> Martin mailto:martin.do...@sap.com>>
> Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
> 
> Hello, please review the following fix .
> I recently  experimented a bit with the  minimal  VM  build  on  linux 
> x86_64
> (--with-jvm-features=minimal --with-jvm-variants=minimal) .
> This worked fine .
> 
> However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le , 
>   I
> noticed that it fails  because of a few  wrong dependencies .
> Thanks to Martin for the advice regarding
> 
> Register ic = as_Register(Matcher::inline_cache_reg_encode());
> 
> Replacement with
> 
> 
> Register ic = R19_inline_cache_reg;
> 
> In
> http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu
> /ppc/sharedRuntime_ppc.cpp.frames.html
> 
> 
> Bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8233078
> http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/
> 
> 
> Thanks, Matthias
> 
> 
> 
> 

RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when compiling with xlc16/legacy-xlc

[Baesken, Matthias]

Hello, please review the following small  AIX related fix.
It is a JDK11 only change ,  and  fixes issues  when building JDK11  with 
xlc16/legacy xlc .
Currently the product build of jdk11   already works with xlc16 ; however  
without this change ,  the (fast)debug build  still fails
  because  we call into  operator new   ( operator_new.cpp) from   
Iostream_init::Iostream_init()()   and this  leads to  a failing build .

( The described  issue   was not seen  when  using  the old  xlc12  for the 
build . )


Bug/webrev :

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

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

Thanks, Matthias

RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

[Baesken, Matthias]

Thanks .
May I have a second review please ?

Best regards, Matthias

From: Doerr, Martin 
Sent: Dienstag, 29. Oktober 2019 13:48
To: Baesken, Matthias ; 
'hotspot-...@openjdk.java.net' 
Cc: 'build-dev@openjdk.java.net' 
Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hi Matthias,

> Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?
This question is not related to this issue.
Commenting out parts of it is not a good style.

Thank you for your update. The new webrev looks good to me.

Best regards,
Martin


From: Baesken, Matthias 
mailto:matthias.baes...@sap.com>>
Sent: Dienstag, 29. Oktober 2019 13:25
To: Doerr, Martin mailto:martin.do...@sap.com>>; 
'hotspot-...@openjdk.java.net' 
mailto:hotspot-...@openjdk.java.net>>
Cc: 'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>
Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hi Martin,  thanks for the input .
I  did the adjustments you suggested;  new webrev :

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

Regarding  : stubGenerator_ppc.cpp: "Code should better be protected by #ifdef 
COMPILER2 than commenting out."
Currently  the  if (OptimizeFill) { ... }coding  is dead on ppc  .

See  :
c2_globals.hpp

234 /* OptimizeFill not yet supported on PowerPC. */ \
235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \

c2_init_ppc.cpp

53 if (OptimizeFill) {
54   warning("OptimizeFill is not supported on this CPU.");
55   FLAG_SET_DEFAULT(OptimizeFill, false);


Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?

Best regards, Matthias




Hi Matthias,

thanks for fixing it. I have a few requests:

disassembler_ppc.cpp:
Please remove includes completely if no longer needed (instead of commenting 
out).

sharedRuntime_ppc.cpp:
I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding 
code is not performance critical.

stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.

Otherwise, looks good to me.

Thanks,
Martin


From: Baesken, Matthias 
mailto:matthias.baes...@sap.com>>
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-...@openjdk.java.net' 
mailto:hotspot-...@openjdk.java.net>>
Cc: 'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>; Doerr, Martin 
mailto:martin.do...@sap.com>>
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64   
 (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I 
noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In 
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias

RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

[Baesken, Matthias]

Hi Martin,  thanks for the input .
I  did the adjustments you suggested;  new webrev :

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

Regarding  : stubGenerator_ppc.cpp: "Code should better be protected by #ifdef 
COMPILER2 than commenting out."
Currently  the  if (OptimizeFill) { ... }coding  is dead on ppc  .

See  :
c2_globals.hpp

234 /* OptimizeFill not yet supported on PowerPC. */ \
235 product(bool, OptimizeFill, true PPC64_ONLY(&& false), \

c2_init_ppc.cpp

53 if (OptimizeFill) {
54   warning("OptimizeFill is not supported on this CPU.");
55   FLAG_SET_DEFAULT(OptimizeFill, false);


Not sure if there are any plans to  support  OptimizeFill  on ppc64 ?

Best regards, Matthias




Hi Matthias,

thanks for fixing it. I have a few requests:

disassembler_ppc.cpp:
Please remove includes completely if no longer needed (instead of commenting 
out).

sharedRuntime_ppc.cpp:
I think it's better to remove the 2 align(InteriorEntryAlignment). Succeeding 
code is not performance critical.

stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.

Otherwise, looks good to me.

Thanks,
Martin


From: Baesken, Matthias 
mailto:matthias.baes...@sap.com>>
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-...@openjdk.java.net' 
mailto:hotspot-...@openjdk.java.net>>
Cc: 'build-dev@openjdk.java.net' 
mailto:build-dev@openjdk.java.net>>; Doerr, Martin 
mailto:martin.do...@sap.com>>
Subject: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64   
 (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I 
noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In 
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias

RFR: 8233078 : fix minimal VM build on Linux ppc64(le)

[Baesken, Matthias]

Hello, please review the following fix .
I recently  experimented a bit with the  minimal  VM  build  on  linux x86_64   
 (--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .

However  when I tried  the minimal vm build   on linux  ppc64 / ppc64le ,   I 
noticed that it fails  because of a few  wrong dependencies .
Thanks to Martin for the advice regarding

Register ic = as_Register(Matcher::inline_cache_reg_encode());

Replacement with


Register ic = R19_inline_cache_reg;

In 
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp.frames.html


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8233078
http://cr.openjdk.java.net/~mbaesken/webrevs/8233078.0/


Thanks, Matthias

RFR: [XS] 8230485: add handling of aix tar in configure

[Baesken, Matthias]

Hello,  please review this small AIX related change .

I noticed that  configure does not recognize  AIX tar  correctly .   This leads 
 in the jdk/jdk AIX  - build   to a message :

checking what type of tar was found...
(without an info about the found tar )

Also the flag setting for aix tar is not correct .



Thanks, Matthias


Bug/webrev :

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

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

RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler

[Baesken, Matthias]

Hi David , thanks  for forwarding to build-dev + your comments . May I add you 
as reviewer?

New webrev :

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

-adjusted  the copyright year in make/autoconf/toolchain.m4
-removed the comment  as suggested by you

> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
> needed in ./share/runtime/vm_version.cpp as well.

-removed  __IBMCPP__  from  share/runtime/vm_version.cpp(more a cleanup 
than something that is really needed) ;
reason is that  xlc16/xlclang++   comes with a very rich set   of  compiler - 
macros,   especially  the "usual"  clang and GNUC macros are all set ; see :

$fgrep GNUC xclangplus.txt
#define __GNUC_MINOR__ 2
#define __GNUC_PATCHLEVEL__ 1
#define __GNUC_STDC_INLINE__ 1
#define __GNUC__ 4

$ fgrep clang xclangplus.txt
#define __clang__ 1
#define __clang_major__ 4
#define __clang_minor__ 0
#define __clang_patchlevel__ 1
#define __clang_version__ "4.0.1 (tags/RELEASE_401/final)"


$ fgrep __VERSION__ xclangplus.txt
#define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1"

So we  would run into the clang -case  in  vm_version.cppand there use  the 
__VERSION__ info  that is pretty  good IMHO .

Best regards, Matthias


> 
> Hi Matthias,
> 
> cc'ing build-dev for build changes.
> 
> But they look fine to me as do the main changes.
> 
> A couple of nits:
> 
> - ensure all copyright headers are updated for 2019
> 
> - in globalDefinitions_xlc.hpp this comment seems no longer necessary
> 
>// __IBMCPP__ is not defined any more with xlclang++
> 
> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
> needed in ./share/runtime/vm_version.cpp as well.
> 
> Cheers,
> David
> 
> On 30/08/2019 1:41 am, Baesken, Matthias wrote:
> > Hi Martin, I agree  about the m4 files .
> > New webrev , this additionally touchestoolchain.m4  and flags-cflags.m4
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/
> >
> > Thanks, Matthias
> >
> >> -Original Message-
> >> From: Doerr, Martin 
> >> Sent: Donnerstag, 29. August 2019 16:19
> >> To: Baesken, Matthias ; 'hotspot-
> >> d...@openjdk.java.net' ; 'ppc-aix-port-
> >> d...@openjdk.java.net' 
> >> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
> >>
> >> Hi Matthias,
> >>
> >> nice cleanup. Looks good to me.
> >>
> >> We can also require availability of xlclang++ in toolchain.m4. I think some
> of
> >> the changes only work with this compiler.
> >>
> >> Thanks,
> >> Martin
> >>
> >>
> >>> -Original Message-
> >>> From: hotspot-dev  On
> Behalf
> >> Of
> >>> Baesken, Matthias
> >>> Sent: Donnerstag, 29. August 2019 15:41
> >>> To: 'hotspot-...@openjdk.java.net' ;
> >>> 'ppc-aix-port-...@openjdk.java.net'  >> d...@openjdk.java.net>
> >>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler
> >>>
> >>> Hello, please review the following change .
> >>> For OpenJDK 13 we've moved to XLC 16 as required compiler.
> >>> However  we have still   a lot of workarounds and checks in the codebase
> >> for
> >>> the older xlc  compilers.
> >>> This changes removes such changes .
> >>>
> >>> Additionally  it  adjusts   the compiler version check in
> >>> hotspot/share/utilities/globalDefinitions_xlc.hpp
> >>> and 2 typos in os_aix  are fixed .
> >>>
> >>>
> >>> When  8224214   was created a while ago ,  it was discussed on the
> mailing
> >> list
> >>> :
> >>>
> >>> "we still set some '-qlanglvl' options for C++ which aren't supported by
> the
> >>> new compiler [xlc16/xlclang++] either" .
> >>> Those options  generated lots of warnings ,   so they  were removed
> >> already
> >>> so  no need to remove them  in  this change .
> >>>
> >>> (  In jdk11  which is built  with xlc12   they can still be found :
> >>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default 
> >>> -qlanglvl=c99vla
> \
> >>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno"
> >>> )
> >>>
> >>>
> >>> Bug/webrev :
> >>>
> >>> https://bugs.openjdk.java.net/browse/JDK-8224214
> >>>
> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/
> >>>
> >>>
> >>> Thanks, Matthias

RE: RFR: 8228426: xlc: switch to clang-style warning disabling

[Baesken, Matthias]

Thanks for the review !
May I have a second reviewer please?

Best regards, Matthias

> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 22. Juli 2019 12:43
> To: Baesken, Matthias ; Baesken, Matthias
> ; 'build-dev@openjdk.java.net'  d...@openjdk.java.net>; 'ppc-aix-port-...@openjdk.java.net'  port-...@openjdk.java.net>
> Subject: RE: RFR: 8228426: xlc: switch to clang-style warning disabling
> 
> Hi Matthias,
> 
> looks good to me. I think this makes sense for jdk14 where we only support
> xlclang++ on AIX.
> 
> Best regards,
> Martin
> 
> 
> > -Original Message-
> > From: build-dev  On Behalf Of
> > Baesken, Matthias
> > Sent: Montag, 22. Juli 2019 12:03
> > To: Baesken, Matthias ; 'build-
> > d...@openjdk.java.net' ; 'ppc-aix-port-
> > d...@openjdk.java.net' 
> > Subject: RE: RFR: 8228426: xlc: switch to clang-style warning
> > disabling
> >
> > Hello, any comments please ?
> >
> > From: ppc-aix-port-dev 
> On
> > Behalf Of Baesken, Matthias
> > Sent: Freitag, 19. Juli 2019 12:20
> > To: 'build-dev@openjdk.java.net' ; 'ppc-aix-
> > port-...@openjdk.java.net' 
> > Subject: [CAUTION] RFR: 8228426: xlc: switch to clang-style warning
> disabling
> >
> > Please review the following change that switches to  clang-style warning
> > disabling  on AIX,  and  adjusts the warning  disabling to current needs .
> >
> > Recently the jdk/jdk build on AIX switched to xlc16/xlclang.
> >
> > This means we can now use the standard clang-style warning disabling (the
> > old legacy qsuppress warning disablings from legacy xlc
> > might not fully work any more).
> >
> > I think we are pretty close in reducing the compiler warnings to 0 on AIX,
> > which would make it possible to build with warnings as errors at some point
> > in the future .
> >
> > In a first step I would disable these warnings in HS for xlc16/xlclang :
> >
> > tautological-compare : (seen in os_aix.cpp)
> >
> > /jdk/src/hotspot/os/aix/os_aix.cpp:2400:15: warning: comparison of
> > unsigned expression >= 0 is always true [-Wtautological-compare]
> > if (bytes >= Use64KPagesThreshold) {
> > ~ ^  
> > /jdk/src/hotspot/os/aix/os_aix.cpp:2607:15: warning: comparison of
> > unsigned expression >= 0 is always true [-Wtautological-compare]
> > if (bytes >= Use64KPagesThreshold) {
> >
> > In the product  build   the   "Use64KPagesThreshold"   is a constant  so 
> > clang
> > complains .  However  in the  (fast)debug  builds one can set
> > Use64KPagesThreshold  with an -XX setting.
> > So I think it is best to disable the warning.
> >
> >
> > shift-negative-value : (seen in c1_LIRGenerator_ppc.cpp)
> >
> > /jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:429:97: warning:
> > shifting a negative signed value is undefined [-Wshift-negative-value]
> >   (x->op() == Bytecodes::_lsub && right.value()->type()-
> > >as_LongConstant()->value() == ((-1)<<15)) ) {
> > 
> > ^
> > /jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:483:96: warning:
> > shifting a negative signed value is undefined [-Wshift-negative-value]
> >   (x->op() == Bytecodes::_isub && right.value()->type()-
> >as_IntConstant()-
> > >value() == ((-1)<<15)) ) {
> >
> > We could probably replace  the -1 shift by a constant but I think it  is 
> > nicely
> > readable .
> >
> >
> >
> > Bug/webrev :
> >
> > https://bugs.openjdk.java.net/browse/JDK-8228426
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8228426.0/
> >
> >
> > Thanks, Matthias

RE: RFR: 8228426: xlc: switch to clang-style warning disabling

[Baesken, Matthias]

Hello, any comments please ?

From: ppc-aix-port-dev  On Behalf Of 
Baesken, Matthias
Sent: Freitag, 19. Juli 2019 12:20
To: 'build-dev@openjdk.java.net' ; 
'ppc-aix-port-...@openjdk.java.net' 
Subject: [CAUTION] RFR: 8228426: xlc: switch to clang-style warning disabling

Please review the following change that switches to  clang-style warning 
disabling  on AIX,  and  adjusts the warning  disabling to current needs .

Recently the jdk/jdk build on AIX switched to xlc16/xlclang.

This means we can now use the standard clang-style warning disabling (the old 
legacy qsuppress warning disablings from legacy xlc
might not fully work any more).

I think we are pretty close in reducing the compiler warnings to 0 on AIX,
which would make it possible to build with warnings as errors at some point in 
the future .

In a first step I would disable these warnings in HS for xlc16/xlclang :

tautological-compare : (seen in os_aix.cpp)

/jdk/src/hotspot/os/aix/os_aix.cpp:2400:15: warning: comparison of unsigned 
expression >= 0 is always true [-Wtautological-compare]
if (bytes >= Use64KPagesThreshold) {
~ ^  
/jdk/src/hotspot/os/aix/os_aix.cpp:2607:15: warning: comparison of unsigned 
expression >= 0 is always true [-Wtautological-compare]
if (bytes >= Use64KPagesThreshold) {

In the product  build   the   "Use64KPagesThreshold"   is a constant  so clang  
complains .  However  in the  (fast)debug  builds one can set  
Use64KPagesThreshold  with an -XX setting.
So I think it is best to disable the warning.


shift-negative-value : (seen in c1_LIRGenerator_ppc.cpp)

/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:429:97: warning: shifting a 
negative signed value is undefined [-Wshift-negative-value]
  (x->op() == Bytecodes::_lsub && 
right.value()->type()->as_LongConstant()->value() == ((-1)<<15)) ) {

^
/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:483:96: warning: shifting a 
negative signed value is undefined [-Wshift-negative-value]
  (x->op() == Bytecodes::_isub && 
right.value()->type()->as_IntConstant()->value() == ((-1)<<15)) ) {

We could probably replace  the -1 shift by a constant but I think it  is nicely 
readable .



Bug/webrev :

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

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


Thanks, Matthias

RFR: 8228426: xlc: switch to clang-style warning disabling

[Baesken, Matthias]

Please review the following change that switches to  clang-style warning 
disabling  on AIX,  and  adjusts the warning  disabling to current needs .

Recently the jdk/jdk build on AIX switched to xlc16/xlclang.

This means we can now use the standard clang-style warning disabling (the old 
legacy qsuppress warning disablings from legacy xlc
might not fully work any more).

I think we are pretty close in reducing the compiler warnings to 0 on AIX,
which would make it possible to build with warnings as errors at some point in 
the future .

In a first step I would disable these warnings in HS for xlc16/xlclang :

tautological-compare : (seen in os_aix.cpp)

/jdk/src/hotspot/os/aix/os_aix.cpp:2400:15: warning: comparison of unsigned 
expression >= 0 is always true [-Wtautological-compare]
if (bytes >= Use64KPagesThreshold) {
~ ^  
/jdk/src/hotspot/os/aix/os_aix.cpp:2607:15: warning: comparison of unsigned 
expression >= 0 is always true [-Wtautological-compare]
if (bytes >= Use64KPagesThreshold) {

In the product  build   the   "Use64KPagesThreshold"   is a constant  so clang  
complains .  However  in the  (fast)debug  builds one can set  
Use64KPagesThreshold  with an -XX setting.
So I think it is best to disable the warning.


shift-negative-value : (seen in c1_LIRGenerator_ppc.cpp)

/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:429:97: warning: shifting a 
negative signed value is undefined [-Wshift-negative-value]
  (x->op() == Bytecodes::_lsub && 
right.value()->type()->as_LongConstant()->value() == ((-1)<<15)) ) {

^
/jdk/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:483:96: warning: shifting a 
negative signed value is undefined [-Wshift-negative-value]
  (x->op() == Bytecodes::_isub && 
right.value()->type()->as_IntConstant()->value() == ((-1)<<15)) ) {

We could probably replace  the -1 shift by a constant but I think it  is nicely 
readable .



Bug/webrev :

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

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


Thanks, Matthias

RFR [XS] 8227834: build.log output from failing commands : include the hs_error file path in case of crashes in build - was :RE: build.log: Output from failing command(s) repeated here - do not miss

[Baesken, Matthias]

Hello I prepared a small change to address the mentioned issue .
Please review !

Bug/webrev :

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

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


Best regards, Matthias



> Hi Matthias,
> 
> I would second that.
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: build-dev  On Behalf Of
> > Baesken, Matthias
> > Sent: Dienstag, 16. Juli 2019 16:40
> > To: 'build-dev@openjdk.java.net' 
> > Subject: [CAUTION] build.log: Output from failing command(s) repeated
> > here - do not miss the hs_error file in case of crashes
> >
> > Hello,   In case  of JVM crashes in the build  (yes they happen in
> development
> >  )  , we  print some info about the crash  at the end of the build log file
> >  In the   Output from failing command(s) repeated here  … section  .
> > This looks like  the following   (from a recent crash on AIX )  :
> >
> > === Output from failing command(s) repeated here ===
> > /opt/freeware/bin/printf "* For target jdk__optimize_image_exec:\n"
> > * For target jdk__optimize_image_exec:
> > (/opt/freeware/bin/grep -v -e "^Note: including file:" <   /nightly/output-
> jdk-
> > test/make-support/failure-logs/jdk__optimize_image_exec.log || true) |
> > /opt/freeware/bin/head -n 12
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  SIGSEGV (0xb) at pc=0x3c0009003cc0a080, pid=34341128, tid=258
> > #
> > # JRE version: OpenJDK Runtime Environment (14.0.1) (build 14.0.0.1-
> > internal+0-adhoc.openjdk.jdk)
> > # Java VM: OpenJDK 64-Bit Server VM (14.0.0.1-internal+0-
> > adhoc.openjdk.jdk, mixed mode, tiered, compressed oops, serial gc, aix-
> > ppc64)
> > # Problematic frame:
> > # C  0x3c0009003cc0a080
> > #
> > # Core dump will be written. Default location:/nightly/jdk/make/core or
> > core.34341128
> > #
> >
> > Unfortunately ,  we miss  the path to the hs_error file   which  is a pity
> > because  this  is a VERY important  info  in the  error analysis .
> >
> > The reason seems to be  that  we currently only  print  12 lines   (head -n 
> > 12)
> > and  this is not ehought to get the line with the hs_error file .
> > Could we switch to  15 lines ,  this would include  the hs_error file .
> >
> > Change  would be done in  jdk/make/InitSupport.gmk where
> > PrintFailureReports   is  done .
> >
> >
> > Best regards, Matthias
> >

build.log: Output from failing command(s) repeated here - do not miss the hs_error file in case of crashes

[Baesken, Matthias]

Hello,   In case  of JVM crashes in the build  (yes they happen in development 
 )  , we  print some info about the crash  at the end of the build log file
 In the   Output from failing command(s) repeated here  … section  .
This looks like  the following   (from a recent crash on AIX )  :

=== Output from failing command(s) repeated here ===
/opt/freeware/bin/printf "* For target jdk__optimize_image_exec:\n"
* For target jdk__optimize_image_exec:
(/opt/freeware/bin/grep -v -e "^Note: including file:" <   
/nightly/output-jdk-test/make-support/failure-logs/jdk__optimize_image_exec.log 
|| true) | /opt/freeware/bin/head -n 12
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x3c0009003cc0a080, pid=34341128, tid=258
#
# JRE version: OpenJDK Runtime Environment (14.0.1) (build 
14.0.0.1-internal+0-adhoc.openjdk.jdk)
# Java VM: OpenJDK 64-Bit Server VM (14.0.0.1-internal+0-adhoc.openjdk.jdk, 
mixed mode, tiered, compressed oops, serial gc, aix-ppc64)
# Problematic frame:
# C  0x3c0009003cc0a080
#
# Core dump will be written. Default location:/nightly/jdk/make/core or 
core.34341128
#

Unfortunately ,  we miss  the path to the hs_error file   which  is a pity 
because  this  is a VERY important  info  in the  error analysis .

The reason seems to be  that  we currently only  print  12 lines   (head -n 12) 
   and  this is not ehought to get the line with the hs_error file .
Could we switch to  15 lines ,  this would include  the hs_error file .

Change  would be done in  jdk/make/InitSupport.gmk where  
PrintFailureReports   is  done .


Best regards, Matthias

8227389: Remove unsupported xlc16 compile options on aix - was : RE: AIX xlc16 options langlvl=c99vla / langlvl=noredefmac is not supported

[Baesken, Matthias]

Hello,  here is a small webrev  removing  the  2 mentioned options .

When compiling jdk/jdk on AIX (using current xlc16 / xlclang) we run into these 
warnings :

warning: 1540-5200 The option "langlvl=c99vla" is not supported. :
This option controls variable length arrays / Enables or disables support for 
C99-type variable length arrays.
warning: 1540-5200 The option "langlvl=noredefmac" is not supported. :
Controls whether a macro can be redefined without a prior #undef or undefine() 
statement.

see 
https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.compilers.aix.doc/compiler.pdf


The mentioned options are only available with the legacy xlc (non xlclang).
I propose to remove these options, because xlc16 / xlclang is now the default 
compiler.


Bug/webrev :

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

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



Thanks and best regards, Matthias



I think this is fine for 14.

Cheers, Thomas

On Mon, Jul 8, 2019 at 9:23 AM Baesken, Matthias 
mailto:matthias.baes...@sap.com>> wrote:
Hello,   when building   jdk/jdk  on AIX  (using the current default xlc16)   I 
get a ton of warnings  :

warning: 1540-5200 The option "langlvl=c99vla" is not supported.
warning: 1540-5200 The option "langlvl=noredefmac" is not supported.


The 2  options seem  to be gone with the current xlc16  / xlclang++  .   I 
would like to remove them -  any objections ?
(removing them might be bad for older xlc  versions but I think we  probably  
cannot compile with older versions  any more  ) .


Best regards, Matthias

AIX xlc16 options langlvl=c99vla / langlvl=noredefmac is not supported

[Baesken, Matthias]

Hello,   when building   jdk/jdk  on AIX  (using the current default xlc16)   I 
get a ton of warnings  :

warning: 1540-5200 The option "langlvl=c99vla" is not supported.
warning: 1540-5200 The option "langlvl=noredefmac" is not supported.


The 2  options seem  to be gone with the current xlc16  / xlclang++  .   I 
would like to remove them -  any objections ?
(removing them might be bad for older xlc  versions but I think we  probably  
cannot compile with older versions  any more  ) .


Best regards, Matthias

RE: RFR: [XS] 8227171: provide function names in native stack trace on aix with xlc16

[Baesken, Matthias]

Hello, any more reviews ?
May I push the change ?

Best regards, Matthias



From: Thomas Stüfe 
Sent: Mittwoch, 3. Juli 2019 14:09
To: Baesken, Matthias 
Cc: build-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR: [XS] 8227171: provide function names in native stack trace on 
aix with xlc16

Looks good and trivial. Thanks for fixing.

..Thomas

On Wed, Jul 3, 2019 at 2:02 PM Baesken, Matthias 
mailto:matthias.baes...@sap.com>> wrote:
Hello please review this small fix for AIX (needed  with  the new xlc16) .

Currently  we miss function names in the hs_err file  :

0x000115098660 - 0x09000f629a4c libjvm.so::+0x6c 
(C++ saves_lr stores_bc gpr_saved:4 )
0x0001150986f0 - 0x0900113594bc libjvm.so::+0x95c 
(C++ saves_lr stores_bc gpr_saved:18 )

The output contains "nameless function"  instead of the  (member) function 
names .
Looks like this unwanted behavior  was introduced when switching to the  xlc16  
compiler.

With xlc16, it looks like we have to  configure  the traceback table generation 
to get the output we need.

The -qtbtable=full   setting can be used for this _

https://www.ibm.com/support/knowledgecenter/SSGH4D_16.1.0/com.ibm.xlf161.aix.doc/compiler_ref/tbtable.html



Bug / webrev :

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

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


Thanks, Matthias

RE: RFR: [XS] 8227171: provide function names in native stack trace on aix with xlc16

[Baesken, Matthias]

Thanks for the review !

From: Thomas Stüfe 
Sent: Mittwoch, 3. Juli 2019 14:09
To: Baesken, Matthias 
Cc: build-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR: [XS] 8227171: provide function names in native stack trace on 
aix with xlc16

Looks good and trivial. Thanks for fixing.

..Thomas

On Wed, Jul 3, 2019 at 2:02 PM Baesken, Matthias 
mailto:matthias.baes...@sap.com>> wrote:
Hello please review this small fix for AIX (needed  with  the new xlc16) .

Currently  we miss function names in the hs_err file  :

0x000115098660 - 0x09000f629a4c libjvm.so::+0x6c 
(C++ saves_lr stores_bc gpr_saved:4 )
0x0001150986f0 - 0x0900113594bc libjvm.so::+0x95c 
(C++ saves_lr stores_bc gpr_saved:18 )

The output contains "nameless function"  instead of the  (member) function 
names .
Looks like this unwanted behavior  was introduced when switching to the  xlc16  
compiler.

With xlc16, it looks like we have to  configure  the traceback table generation 
to get the output we need.

The -qtbtable=full   setting can be used for this _

https://www.ibm.com/support/knowledgecenter/SSGH4D_16.1.0/com.ibm.xlf161.aix.doc/compiler_ref/tbtable.html



Bug / webrev :

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

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


Thanks, Matthias

RFR: [XS] 8227171: provide function names in native stack trace on aix with xlc16

[Baesken, Matthias]

Hello please review this small fix for AIX (needed  with  the new xlc16) .

Currently  we miss function names in the hs_err file  :

0x000115098660 - 0x09000f629a4c libjvm.so::+0x6c 
(C++ saves_lr stores_bc gpr_saved:4 )
0x0001150986f0 - 0x0900113594bc libjvm.so::+0x95c 
(C++ saves_lr stores_bc gpr_saved:18 )

The output contains "nameless function"  instead of the  (member) function 
names .
Looks like this unwanted behavior  was introduced when switching to the  xlc16  
compiler.

With xlc16, it looks like we have to  configure  the traceback table generation 
to get the output we need.

The -qtbtable=full   setting can be used for this _

https://www.ibm.com/support/knowledgecenter/SSGH4D_16.1.0/com.ibm.xlf161.aix.doc/compiler_ref/tbtable.html



Bug / webrev :

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

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


Thanks, Matthias

RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx

[Baesken, Matthias]

Hello please review this  small fix for a compile issue  on OSX .
Today I  compiled   jdk/jdk   on a machine  with   XCode 10.2  . It worked 
pretty well .
However this small issue showed up .


In file included from 
/open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33:
/open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14:
 error:
comparison of two values with different enumeration types in switch statement 
('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') 
[-Werror,-Wenum-compare-switch]


And here XCode 10 is correct ,JVMTI_REFERENCE_ARRAY_ELEMENT   is from a 
different  enumeration type  and should be replaced  with the value  from the 
correct  enumeration type   .

Bug / webrev :

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

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


Thanks, Matthias

RE: jdk/jdk (+jdk12) Build failure on OSX 10.11

[Baesken, Matthias]

Hello,  it comes  from the  MacOSX SDK,  the value

NSWindow.h:61:NSWindowStyleMaskDocModalWindow   = 1 << 6,

can be found  in   MacOSX10.12.sdk   andMacOSX10.13.sdk  .
From the info I found here :

https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_11.x_(since_Free_On-Device_Development)

XCode 8 and higher   come with at least   MacOSX  SDK   10.12  .
So checking for  the Xcode version might make more sense .


Best regards, Matthias


> -Original Message-
> From: Erik Joelsson 
> Sent: Mittwoch, 19. Juni 2019 19:30
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' 
> Cc: Schuenemann, Rene 
> Subject: Re: jdk/jdk (+jdk12) Build failure on OSX 10.11
> 
> Are you sure it's 10.11 that is the problem and not the version of Xcode?
> 
> /Erik
> 
> On 2019-06-19 00:51, Baesken, Matthias wrote:
> > Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  
> > that
> NSWindowStyleMaskDocModalWindow  is used since :
> >
> > https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189
> >
> > 8208543: [macos] Support for apple.awt.documentModalSheet incomplete
> >
> > Which is 10.12+ functionality . See
> >
> >
> https://developer.apple.com/documentation/appkit/nswindowstylemask/n
> swindowstylemaskdocmodalwindow?language=objc
> >
> > NSWindowStyleMaskDocModalWindow
> > The window is a document-modal panel (or a subclass of
> NSPanel<https://developer.apple.com/documentation/appkit/nspanel?lang
> uage=objc>).
> > macOS 10.12+
> >
> >
> >
> > I would prefer to test for  minimum  10.12  already  in  configure  , what 
> > do
> you think ?
> >
> > Best regards, Matthias
> >

RE: jdk/jdk (+jdk12) Build failure on OSX 10.11

[Baesken, Matthias]

We could add a check  for  the existing OS_VERSION_MAJOR  variable   ,   this 
shows the kernel version but from my understanding the  kernel  to OSX mapping 
is pretty stable
e.g.  something like :


diff -r 7cf925f385fe make/autoconf/toolchain.m4
--- a/make/autoconf/toolchain.m4Wed Jun 19 08:43:23 2019 +0200
+++ b/make/autoconf/toolchain.m4Wed Jun 19 13:28:37 2019 +0200
@@ -224,6 +224,11 @@
   VALID_TOOLCHAINS=${!toolchain_var_name}
   if test "x$OPENJDK_TARGET_OS" = xmacosx; then
+# check for min. OSX 10.12 (kernel version 16.X from uname)
+if test $OS_VERSION_MAJOR -lt 16; then
+  AC_MSG_ERROR([OSX version 10.12 / kernel version 16 or higher is 
required])
+fi
+
 if test -n "$XCODEBUILD"; then
   # On Mac OS X, default toolchain to clang after Xcode 5
   XCODE_VERSION_OUTPUT=`"$XCODEBUILD" -version 2>&1 | $HEAD -n 1`


(  or  use  the  sw_vers command  and check the output

sw_vers -productVersion
10.12.6

)

What do you think ?


Best regards, Matthias


From: Baesken, Matthias
Sent: Mittwoch, 19. Juni 2019 09:51
To: 'build-dev@openjdk.java.net' 
Cc: Schuenemann, Rene 
Subject: jdk/jdk (+jdk12) Build failure on OSX 10.11

Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  that 
  NSWindowStyleMaskDocModalWindow  is used since :

https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189

8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Which is 10.12+ functionality . See

https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskdocmodalwindow?language=objc

NSWindowStyleMaskDocModalWindow
The window is a document-modal panel (or a subclass of 
NSPanel<https://developer.apple.com/documentation/appkit/nspanel?language=objc>).
macOS 10.12+



I would prefer to test for  minimum  10.12  already  in  configure  , what do 
you think ?

Best regards, Matthias

jdk/jdk (+jdk12) Build failure on OSX 10.11

[Baesken, Matthias]

Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  that 
  NSWindowStyleMaskDocModalWindow  is used since :

https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189

8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Which is 10.12+ functionality . See

https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskdocmodalwindow?language=objc

NSWindowStyleMaskDocModalWindow
The window is a document-modal panel (or a subclass of 
NSPanel).
macOS 10.12+



I would prefer to test for  minimum  10.12  already  in  configure  , what do 
you think ?

Best regards, Matthias

RE: zlib configuration : system vs. bundled

[Baesken, Matthias]

Hi Alan,   thanks for the  info .
Are you aware of  a way to  reliably   see  the info   (e.g. in hs_err  file)   
what version of  libz  was used  at runtime ?

On linux (with some luck )   we see it in hs_err  , at least a lot of distros  
put the version into the libname , and then it is displayed  in the hs_err 
section 

Dynamic libraries:

 ...   /lib64/libz.so.1.2.8
.../lib64/libz.so.1.2.8
...   /lib64/libz.so.1.2.8

On macOSX   you see nothing just because the version is not in the libname :


Dynamic libraries:

 ...  /usr/lib/libz.1.dylib


Best regards, Matthias




> -Original Message-
> From: Alan Bateman 
> Sent: Freitag, 17. Mai 2019 09:47
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' 
> Subject: Re: zlib configuration : system vs. bundled
> 
> On 16/05/2019 15:18, Baesken, Matthias wrote:
> > Hello Alan,
> >
> > I found
> >
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-
> March/032106.html
> >
> > and
> >
> > http://mail.openjdk.java.net/pipermail/build-dev/2016-
> February/thread.html#16602
> >
> > but without much details  on   real  or potential  performance
> improvements .
> >
> > Both discussion  threads are pretty old.  I do not think they cover  the
> changes  done in the meantime in   jdk9 and higherin the java.util.zip
> package .
> > I think a lot of coding there moved  from C  to  Java ,  so  the libz   is 
> > used in
> JDK  less these days than  in  the "old times " .
> Yes, the ZipFile implementation has changed significantly (many of the
> motivations are listed in JDK-8142508) but the compression and checksum
> (except CRC32C) will use libz. You'll see hotspot using it too, say when
> running with -Xbootclasspath/a to add a JAR file to the boot class path.
> There has many threads here and on core-libs-dev about using the bundled
> vs. system zlib. It was an issue for the Linux distros in the early days
> of OpenJDK as they have policies to not include copies of libraries that
> the OS provides. At one point there was a patch proposing a XX option to
> select the system vs. bundled zlib at run-time, the motivation being to
> be able to switch to the Intel IPP implementation. It's impossible to
> please everyone but I think the default that we settled on is probably
> the best.
> 
> -Alan

RE: zlib configuration : system vs. bundled

[Baesken, Matthias]

Hello Alan, 

I found 

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032106.html

and

http://mail.openjdk.java.net/pipermail/build-dev/2016-February/thread.html#16602

but without much details  on   real  or potential  performance improvements .

Both discussion  threads are pretty old.  I do not think they cover  the  
changes  done in the meantime in   jdk9 and higherin the java.util.zip 
package .
I think a lot of coding there moved  from C  to  Java ,  so  the libz   is used 
in JDK  less these days than  in  the "old times " .

>
> Sure but the opposite can arise too, say where someone is using a JDK
> release that bundles an older version of zlib.
>

True ,  unfortunately  the  old JDK  with bundled  libz   would  not use the  
"great new  current   libz"  from the distro (in case there is such a recent 
version available ),
People would need to patch the JDK .

At least we have the freedom to  choose with the configure-flags .

Best regards, Matthias 


> On 15/05/2019 09:16, Baesken, Matthias wrote:
> > Hi Alan,   thanks for pointing me  at the old discussion .
> >
> > http://mail.openjdk.java.net/pipermail/build-dev/2016-
> February/016602.html
> >
> > talks about performance benefits .  Are you aware of some  benchmarks
> that showed the improvements ?
> If you can find the mails that references the Intel IPP library then you
> might have links to performance data comparing the different
> implementations. There is also mails somewhere in the archive with a
> proposal or patch to have the JDK select an alternative implementation
> at run-time, equivalent to LD_PRELOAD. I think we ended up with the
> right default.
> 
> >
> > In reality,  if you have the latest  distro versions you might be lucky and 
> > you
> have a nice recent zlib 1.2.11  .
> > However on older distros , you run in reality  into older zlibs  (often I 
> > see
> 1.2.8).  I don't think that this is a very good status .
> Sure but the opposite can arise too, say where someone is using a JDK
> release that bundles an older version of zlib.
> 
> I agree with the comment that the building instructions need to be
> sync'ed up.
> 
> -Alan.

RE: zlib configuration : system vs. bundled

[Baesken, Matthias]

Hello,   the updated webrev  is here :


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


Best regards, Matthias



> 
> 
> On 2019-05-15 01:16, Baesken, Matthias wrote:
> > Hi Alan,   thanks for pointing me  at the old discussion .
> >
> > http://mail.openjdk.java.net/pipermail/build-dev/2016-
> February/016602.html
> >
> > talks about performance benefits .  Are you aware of some  benchmarks
> that showed the improvements ?
> >
> > In reality,  if you have the latest  distro versions you might be lucky and 
> > you
> have a nice recent zlib 1.2.11  .
> > However on older distros , you run in reality  into older zlibs  (often I 
> > see
> 1.2.8).  I don't think that this is a very good status .
> >
> >
> > At least I think  building.md  should be fixed to  state the real status , 
> > the
> current  info is wrong :
> >
> >
> > "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, 
> > lcms
> > and zlib) are included in the JDK repository. The default behavior of the
> > JDK build is to use this version of these libraries, but they might be
> > replaced by an external version. To do so, specify `system` as the
> ``
> > option in these arguments. (The default is `bundled`)."
> >
> >
> >
> > Btw  how is building.html  generated ,  is this coming from  building.md  ?
> 
> Yes, you need to configure with pandoc. Then you run "make
> update-build-docs".
> 
> /Erik
> 

8223944: fix zlib related building docu and comments - was : RE: zlib configuration : system vs. bundled

[Baesken, Matthias]

Btw I adjusted the build docu  and  some  m4  file comments  regarding the zlib 
usage :

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

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


Best regards, Matthias



> -Original Message-
> From: Baesken, Matthias
> Sent: Mittwoch, 15. Mai 2019 10:16
> To: 'Alan Bateman' ; 'build-
> d...@openjdk.java.net' 
> Subject: RE: zlib configuration : system vs. bundled
> 
> Hi Alan,   thanks for pointing me  at the old discussion .
> 
> http://mail.openjdk.java.net/pipermail/build-dev/2016-
> February/016602.html
> 
> talks about performance benefits .  Are you aware of some  benchmarks that
> showed the improvements ?
> 
> In reality,  if you have the latest  distro versions you might be lucky and 
> you
> have a nice recent zlib 1.2.11  .
> However on older distros , you run in reality  into older zlibs  (often I see
> 1.2.8).  I don't think that this is a very good status .
> 
> 
> At least I think  building.md  should be fixed to  state the real status , the
> current  info is wrong :
> 
> 
> "Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms
> and zlib) are included in the JDK repository. The default behavior of the
> JDK build is to use this version of these libraries, but they might be
> replaced by an external version. To do so, specify `system` as the ``
> option in these arguments. (The default is `bundled`)."
> 
> 
> 
> Btw  how is building.html  generated ,  is this coming from  building.md  ?
> 
> Best regards, Matthias
> 
> 
> 
> 
> > -Original Message-
> > From: Alan Bateman 
> > Sent: Dienstag, 14. Mai 2019 17:47
> > To: Baesken, Matthias ; 'build-
> > d...@openjdk.java.net' 
> > Subject: Re: zlib configuration : system vs. bundled
> >
> > On 14/05/2019 15:58, Baesken, Matthias wrote:
> > > :
> > >
> > > On the other OS platforms, in case a zlib is found on the system :
> > >
> > >if test "x${ZLIB_FOUND}" != "xyes"; then
> > >  # If we don't find any system...set default to bundled
> > >  DEFAULT_ZLIB=bundled
> > >fi
> > >
> > > we use it from the system .
> > > Wouldn't  it be more  consistent to  have  zlib=bundled as well as default
> for
> > the other UNIX platforms + MacOSX ?
> > > ( people who wish to use  the system zlib still can configure it )
> > >
> > > Otherwise we often run into using old zlib installations at build time 
> > > which
> > might not be desired.
> > >
> > It was a deliberate change in JDK 9 to use the system zlib if possible.
> > Windows is the outlier. If you through the archives of core-libs-dev
> > then you should find several discussions about this, I think the most
> > recent was in 2016, subject line "JDK-8031767 Support system or
> > alternative implementations of zlib".
> >
> > -Alan

RE: zlib configuration : system vs. bundled

[Baesken, Matthias]

Hi Alan,   thanks for pointing me  at the old discussion .

http://mail.openjdk.java.net/pipermail/build-dev/2016-February/016602.html

talks about performance benefits .  Are you aware of some  benchmarks that 
showed the improvements ?

In reality,  if you have the latest  distro versions you might be lucky and you 
have a nice recent zlib 1.2.11  .
However on older distros , you run in reality  into older zlibs  (often I see 
1.2.8).  I don't think that this is a very good status .


At least I think  building.md  should be fixed to  state the real status , the 
current  info is wrong :


"Certain third-party libraries used by the JDK (libjpeg, giflib, libpng, lcms
and zlib) are included in the JDK repository. The default behavior of the
JDK build is to use this version of these libraries, but they might be
replaced by an external version. To do so, specify `system` as the ``
option in these arguments. (The default is `bundled`)."



Btw  how is building.html  generated ,  is this coming from  building.md  ?

Best regards, Matthias




> -Original Message-
> From: Alan Bateman 
> Sent: Dienstag, 14. Mai 2019 17:47
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' 
> Subject: Re: zlib configuration : system vs. bundled
> 
> On 14/05/2019 15:58, Baesken, Matthias wrote:
> > :
> >
> > On the other OS platforms, in case a zlib is found on the system :
> >
> >if test "x${ZLIB_FOUND}" != "xyes"; then
> >  # If we don't find any system...set default to bundled
> >  DEFAULT_ZLIB=bundled
> >fi
> >
> > we use it from the system .
> > Wouldn't  it be more  consistent to  have  zlib=bundled as well as default 
> > for
> the other UNIX platforms + MacOSX ?
> > ( people who wish to use  the system zlib still can configure it )
> >
> > Otherwise we often run into using old zlib installations at build time which
> might not be desired.
> >
> It was a deliberate change in JDK 9 to use the system zlib if possible.
> Windows is the outlier. If you through the archives of core-libs-dev
> then you should find several discussions about this, I think the most
> recent was in 2016, subject line "JDK-8031767 Support system or
> alternative implementations of zlib".
> 
> -Alan