Re: zlib before 1.2.12 allows memory corruption (CVE-2018-25032)

Hi Bernd, Vitaly, Amazon Corretto [1] also includes the fixes for CVE-2018-25032. This is our statement: "Based upon our analysis, OpenJDK/Corretto is not affected by CVE-2018-25032, because the zlib "memLevel" parameter is not settable and is fixed at 8, and the usage of the Z_FIXED strategy is

Re: CFV: New Build Group Member: Aleksey Shipilev

Vote: yes Magnus Ihse Bursie schrieb am Mi., 10. Nov. 2021, 15:07: > I hereby nominate Aleksey Shipilev (shade) to Membership in the Build > Group. > > Aleksey is a long standing member of the OpenJDK Members Group and the > Hotspot > Group. He is a prolific contributor, and has committed more

Re: RFR: 8256127: Add cross-compiled foreign architectures builds to submit workflow [v5]

On Thu, 12 Nov 2020 09:34:51 GMT, Aleksey Shipilev wrote: >> Maybe it would be possible to build hotspot only as this is the part where >> things often break? This would save a lot of CPU time. >> E.g. I think it'd be valueable to have at least one Big Endian platform >> included. >> I noticed

Re: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2]

On Tue, 3 Nov 2020 20:12:35 GMT, Magnus Ihse Bursie wrote: >> Ok, will do. (FWIW, you can expand the context of the diff with the arrow >> buttons on the left side of the view. Above or below the line numbers) > > (Yes, I know. I just didn't think that doing so would reveal anything about >

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

On Tue, Mar 3, 2020 at 10:26 AM Andrew Haley wrote: > > On 3/2/20 10:46 PM, Volker Simonis wrote: > > > As lead of the 8 and 11 update projects you probably know best, if this fix > > will eventually be considered for backporting and choose your means wisely > >

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

Andrew Haley schrieb am Mo., 2. März 2020, 13:00: > On 11/19/18 8:39 PM, Kim Barrett wrote: > > I don't see any benefit to making the first C++ code change that uses > > a new feature also incorporate the needed build system changes. > > Indeed, how does one develop that feature usage unless one

Re: [11u] RFR: 8240073: Fix 'test-make' build target in 11u

make/common/MakeBase.gmk" initially used "KEYWORDS" but when it was updated by "8212028: Use run-test makefile framework for testing in Oracle's Mach5" to use "SINGLE_KEYWORDS" instead, these two places were forgotten. Thanks for reviewing, Volker > > Thanks

Re: [11u] RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

On Wed, Feb 26, 2020 at 3:49 PM Andrew Hughes wrote: > > On 26/02/2020 10:59, Volker Simonis wrote: > > Hi, > > I'd like to downport the support for Visual Studio Code project > > creation to 11u. I think we will have to support 11u for quite some > > years and

Re: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK libraries"

On Thu, Feb 27, 2020 at 3:44 PM Severin Gehwolf wrote: > > Hi Andrew, > > On Thu, 2020-02-27 at 04:52 +, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232748 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/ > > > > This patch adds targets

Re: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects

On Sat, Feb 22, 2020 at 12:08 AM Langer, Christoph wrote: > Hi, > > Thanks, Volker for backporting this to JDK11 and thanks Andrew for > reviewing it. > > > On 30/12/2019 20:18, Volker Simonis wrote: > > > Hi, > > > I'd like to downport the support for Vi

Re: [11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects

On Wed, Feb 19, 2020 at 6:14 AM Andrew Hughes wrote: > > > > On 30/12/2019 20:18, Volker Simonis wrote: > > Hi, > > I'd like to downport the support for Visual Studio Code project > > creation to 11u. I think we will have to support 11u for quite some > > year

[11u] RFR: 8240073: Fix 'test-make' build target in 11u

Hi, can I please have a review for the following tiny change which fixes the 'test-make' build target in 11u: http://cr.openjdk.java.net/~simonis/webrevs/2020/8240073/ https://bugs.openjdk.java.net/browse/JDK-8240073 This is a tiny fix for a problem introduced by JDK-8212028 (which has already

[11u] RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

Hi, I'd like to downport the support for Visual Studio Code project creation to 11u. I think we will have to support 11u for quite some years and it makes sense to have as good as possible tool support in 11u as well: https://bugs.openjdk.java.net/browse/JDK-8223678

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

Looks good! Thanks, Volker On Fri, Feb 21, 2020 at 2:50 PM Baesken, Matthias wrote: > > 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

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

I've also seen this recently but haven't managed to file a bug report yet. If I remember correctly, I had to exclude two warnings, but that can also be because I've experimented with different libz version. The one proposed here is definitely required. So the change looks good to me. Erik

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

cause 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.so > we see good results regarding reduced code size. > > > > I Cannot say much about p

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

[11u] RFR: 8210459, 8218807, 8223678: Support for creating Visual Studio Code projects

Hi, I'd like to downport the support for Visual Studio Code project creation to 11u. I think we will have to support 11u for quite some years and it makes sense to have as good as possible tool support in 11u as well. This mail is especially intended to get a review from the build team that the

Result: New Build Group Member: Matthias Baesken

Voting for Matthias Baesken [1] is now closed. Yes: 5 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus voting, this is sufficient to approve the nomination. Best regards, Volker [1] https://mail.openjdk.java.net/pipermail/build-dev/2019-June/025839.html

CFV: New Build Group Member: Matthias Baesken

, see [3]. Volker Simonis [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()=100 [2] http://openjdk.java.net/census#build [3] http

Re: CFV: New Build Group Member: Matthias Baesken

Vote: yes On Wed, Jun 26, 2019 at 10:29 AM Volker Simonis wrote: > > I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build > Group. > > Matthias is a long standing member of the JVM team at SAP. He's main > areas of expertise are the build system,

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

On Wed, May 29, 2019 at 3:43 PM Robin Westberg wrote: > > Hi Volker, > > > On 28 May 2019, at 17:33, Volker Simonis wrote: > > > > Hi Robin, > > > > thanks a lot for doing this! > > > > I have just a quick question. Do you know if any of

Re: RFR: 8223678: Add Visual Studio Code workspace generation support (for native code)

Hi Robin, thanks a lot for doing this! I have just a quick question. Do you know if any of the VSC indexers (default, clangd) support call hierarchies (i.e. "called by", "callers" of a function/method) and "used by" for variables/class fields? Regards, Volker On Mon, May 27, 2019 at 6:03 PM

Re: RFR: 8224087: Compile C code for at least C99 Standard compliance

Sergey Bylokhov schrieb am Mo. 20. Mai 2019 um 20:14: > Hi, David. > Should not the minimum version of c standard mentioned in the > doc/building.html? > We actually have a Wiki page for that because it’s much easier to maintain:

Re: RFR: 8224087: Compile C code for at least C99 Standard compliance

Hi David, thanks for considering AIX in your change. With OpenJDK 13 we've moved to XLC 16 which has a new Clang based frontend. The "ucs" feature-suboption [1] you're using in your change is only supported in the old, xlc compiler but not in the new xlclang any more [2]. However, the good news

Re: RFR [XS] : 8223685: used bundled zlib on AIX by default

Looks good! Thanks, Volker On Fri, May 10, 2019 at 12:23 PM Baesken, Matthias wrote: > > Hello, please review this small AIX - specific change . > > Currently we use by default the bundled zlib (= zlib coming with OpenJDK) > on Windows, on other platforms the system zlib. > However it is

Re: RFR(XS): 8222627: Remove sneaky token 'Name' in jdk-version.m4

Looks good. Nice to see how „fault tolerant“ m4 is :) Langer, Christoph schrieb am Mi. 17. Apr. 2019 um 08:46: > Hi, > > please review this little revert of a token that accidentally sneaked in > when I pushed JDK-8222522 (Add configure options for Mac Bundle creation) > yesterday. I don't

Re: RFR(XS): 8220164: Fix build instructions for AIX

Thanks Martin! On Tue, Mar 5, 2019 at 5:06 PM Doerr, Martin wrote: > > Hi Volker, > > the wiki is already up to date, so I like your new version which just refers > to it. Reviewed. > > Best regards, > Martin > > > -Original Message- > From: build

RFR(XS): 8220164: Fix build instructions for AIX

Hi, can I please have a review for the following trivial change which updates the AIX/XLC information in the the building.{md, html} files: https://bugs.openjdk.java.net/browse/JDK-8220164 http://cr.openjdk.java.net/~simonis/webrevs/2019/8220164/ The build instructions for AIX in

Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain

When I last tried gold a few years ago on ppc64 (and ia64, just for the reference :) it didn't work because it didn't support all the required relocations. However, a current experiment with "GNU gold (GNU Binutils for Ubuntu 2.26.1) 1.11" on Ubuntu 16.04/ppc64le succeeded and improved the link

Re: Is anyone using msys to build OpenJDK?

It is a long time ago (~2012) that I added and fixed the MinGW/Msys build [1] on Windows. We at SAP used it productively for some years because at that time Cygwin was terrible slow, buggy, had no 64-bit version, wasn’t really maintained very well, etc... But things have changed to the opposite

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On Tue, Dec 11, 2018 at 11:47 PM David Holmes wrote: > > On 12/12/2018 12:34 am, Magnus Ihse Bursie wrote: > > > > > > On 2018-12-11 00:23, David Holmes wrote: > >> Hi Magnus, > >> > >> On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >>> I propose that we introduce a new define, available to

Re: Proposal: Use new JDK_EXPORT decorator instead of JNIEXPORT

On Tue, Dec 11, 2018 at 3:35 PM Magnus Ihse Bursie wrote: > > > > On 2018-12-11 00:23, David Holmes wrote: > > Hi Magnus, > > > > On 10/12/2018 11:19 pm, Magnus Ihse Bursie wrote: > >> I propose that we introduce a new define, available to all JDK native > >> files (Hotspot included), called

Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags

comments Volkar!). > > With Volkar, Erik, Matthias, and Magnus all approving the change, it sounds > like we're good to merge! > > Volkar, can you do the honours? > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. I approve the change too. ;) > > > Volker Simon

Re: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken

Cool, thanks! I'll push then... On Mon, Dec 3, 2018 at 2:37 PM Magnus Ihse Bursie wrote: > > On 2018-12-03 14:31, Volker Simonis wrote: > > Hi Magnus, Erik, > > do I understand you correctly that you both are fine with my proposed > fix and that we leave all the other en

Re: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken

ven more reproducible. But does this goal > not apply to hotspot (or is it just on the TODO list ?). > > In the end, I'm happy with the current, minimal fix which at least > gets the logs working again. > > And maybe for the follow up change we should then better m

Re: RFR(XS): 8214534: Setting of THIS_FILE in the build is broken

E__" occurrences in HotSpot to "THIS_FILE" instead of getting rid of "THIS_FILE"? Best regards, Volker > /Erik > > On 2018-11-30 09:05, Volker Simonis wrote: > > Hi, > > > > can I please have a review for the following trivial fix:

RFR(XS): 8214534: Setting of THIS_FILE in the build is broken

Hi, can I please have a review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214534/ https://bugs.openjdk.java.net/browse/JDK-8214534 DISCLAIMER: "XS" refers to the size of the fix, not the size of the explanation :) Currently the compilation of native files

Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags

On Thu, Nov 29, 2018 at 12:20 PM Magnus Ihse Bursie wrote: > > On 2018-11-27 16:33, Volker Simonis wrote: > > > Hi, > > > > can I please have a review for the following trivial change which > > simply disables the symbol visibility flags on AIX: > > > >

Re: RFR(XS): 8214063: [AIX] Disable symbol visibility flags

java.net/jdk/jdk/rev/98f57dff16f3 > > > > Now that people are starting to really use xlC 13 it turns out that there > > is more to do than just enabling the flags > > It was pretty clear from the beginning that with higher xlc versions > than 12.1 the chance that

RFR(XS): 8214063: [AIX] Disable symbol visibility flags

Hi, can I please have a review for the following trivial change which simply disables the symbol visibility flags on AIX: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214063/ https://bugs.openjdk.java.net/browse/JDK-8214063 Change "8202322: AIX: symbol visibility flags not support on xlc

RFR(S): 8214343: Handle the absence of Xrandr more generically

Hi, can I please have a review for the following trivial change which handles the absence of Xrandr more generically: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214343/ https://bugs.openjdk.java.net/browse/JDK-8214343 Change JDK-8213944 fixed the build on AIX (which has no Xrandr) by

Re: RFR(S): 8213698: Improve devkit creation and add support for linux/ppc64/ppc64le/s390x

ke you could always to RPM_ARCHS := $(ARCH) noarch, and then use > += for the few platforms that need additionals RPM archs. > Done. > There was something more I thought of when I reviewed your changes, but > it slipped my mind now. > There's still room for improvements :) For ex

Re: RFR: JDK-8214063: OpenJDK will not build on AIX while using the xlc 13.1 compiler

On Wed, Nov 21, 2018 at 12:44 PM Magnus Ihse Bursie wrote: > > > > On 2018-11-20 18:50, Volker Simonis wrote: > > On Tue, Nov 20, 2018 at 6:15 PM Thomas Stüfe > > wrote: > >> On Tue, Nov 20, 2018 at 6:12 PM Adam Farley8 > >> wrote: > >>> H

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

asks Results Summary UNABLE_TO_RUN: 0 FAILED: 0 EXECUTED_WITH_FAILURE: 1 KILLED: 0 PASSED: 75 NA: 0 Thank you and best regards, Volker On Tue, Nov 20, 2018 at 12:05 PM Magnus Ihse Bursie wrote: > > > > On 2018-11-19 18:56, Volker Simonis wrote: > > Hi Phil, > > > > I'd li

RFR(XS): 8214120: [REDO] Fix sun.awt.nativedebug on X11 platforms

Hi, so here's a reworked version of my previous change: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214120/ https://bugs.openjdk.java.net/browse/JDK-8214120 In addition to my initial change (which unfortunately broke the Solaris build) the new version has to JNIEXPORT the following

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

for me, but that would actually negate the initial purpose of "8210863: Remove Xrandr include files") Do you have a better proposal? Thank you and best regards, Volker On Fri, Nov 16, 2018 at 11:22 AM Volker Simonis wrote: > > On Thu, Nov 15, 2018 at 6:01 PM Philip Race wrote:

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

On Mon, Nov 19, 2018 at 9:00 AM Kim Barrett wrote: > > > On Nov 19, 2018, at 2:04 AM, Kim Barrett wrote: > > > >> On Nov 19, 2018, at 1:31 AM, David Holmes wrote: > >> I think it is important that all the port owners buy into this. > > > > At least one port (aix_ppc) presently seems to have no

RFR(XXS): 8214007: Fix sun.awt.nativedebug on X11 platforms

Hi, can I please have a review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8214007/ https://bugs.openjdk.java.net/browse/JDK-8214007 AWT supports some kind of native logging which can be enabled with "-Dsun.awt.nativedebug=true -Dawtdebug.ctrace=true".

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

again in an AIX-specific directory :) Thank you and best regards, Volker > -phil. > > On 11/15/18, 8:55 AM, Philip Race wrote: > > Hmm. I don't like the ifdefs. > > > > Xrandr is a requirement for the build. If its not there at runtime > > that's OK. > >

Re: [OpenJDK 2D-Dev] RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

e at runtime > that's OK. > > -phil. > > On 11/15/18, 8:06 AM, Volker Simonis wrote: > > Hi, > > > > can I please have a review for the following small change: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213944/ > > https://bugs.openjdk

Re: RFR(XS): 8213944: Fix AIX build after the removal of Xrandr.h and add a configure check for it

On Thu, Nov 15, 2018 at 5:31 PM Aleksey Shipilev wrote: > > On 11/15/2018 05:06 PM, Volker Simonis wrote: > > can I please have a review for the following small change: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213944/ > > *) I tested it on platform w

Re: RFR(S): 8213698: Improve devkit creation and add support for linux/ppc64/ppc64le/s390x

he > same in this regard. I agree that it's cleaner with a top level dir, but > in the world of automated installs, it adds yet another level of > directories to already deep paths. I'm ok with changing it however. > > /Erik > > On 2018-11-13 08:25, Volker Simonis wrote: > >

Re: RFR(S): 8213698: Improve devkit creation and add support for linux/ppc64/ppc64le/s390x

ok/autobook/autobook_17.html On Mon, Nov 12, 2018 at 12:19 PM Volker Simonis wrote: > > Hi, > > can I please have a review for the following change which ads support > for linux/ppc64/ppc64le/s390x devkits and hopefully improves the > creation of devkits a little bit :) > > h

RFR(S): 8213698: Improve devkit creation and add support for linux/ppc64/ppc64le/s390x

Hi, can I please have a review for the following change which ads support for linux/ppc64/ppc64le/s390x devkits and hopefully improves the creation of devkits a little bit :) http://cr.openjdk.java.net/~simonis/webrevs/2018/8213698/ https://bugs.openjdk.java.net/browse/JDK-8213698 With these

Re: RFR(XS): 8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x

Thanks for the quick reviews! I've removed the comment as requested by Aleksey and pushed. Regards, Volker On Thu, Nov 8, 2018 at 11:54 AM Thomas Stüfe wrote: > > +1 > > Gruss Thomas > On Thu, Nov 8, 2018 at 10:25 AM Volker Simonis > wrote: > > > > Hi, >

RFR(XS): 8213515: Improve freetype detection on linux/ppc64/ppc64le/s390x

Hi, can I please have a review for the following trivial enhancement of the freetype detection on linux/ppc64/ppc64le/s390x: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213515/ https://bugs.openjdk.java.net/browse/JDK-8213515 On some more "exotic" Linux platforms, libfreetype.so is found

Re: gcc 7.3.1 build - warnings as errors in harfbuzz

Hi Matthias, I've looked a little at this error and it is quite strange. First of all, I can't reproduce it with a default gcc 7.3.0 and there doesn't exist an official version of gcc 7.3.1 (at least I couldn't find it). Also, I can't see the real error in the objected code. The values the

Re: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

ault (not a tested configuration) > 614 # > > > Thanks! > > Jiangli > > > On 10/8/18 3:10 AM, Volker Simonis wrote: > > Hi Martin, Goetz, > > > > thanks for reviewing my patch! As Aleksey posted a similar patch for > > fixing the Zero build I've e

Re: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

espin if you do). > > /Erik > > > On 2018-10-08 03:10, Volker Simonis wrote: > > Hi Martin, Goetz, > > > > thanks for reviewing my patch! As Aleksey posted a similar patch for > > fixing the Zero build I've extended my patch to handle > > zero/minimal/cor

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

On Mon, Oct 8, 2018 at 12:49 PM Thomas Stüfe wrote: > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. > > HotSpot

Re: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

On Mon, Oct 8, 2018 at 12:59 PM Aleksey Shipilev wrote: > > On 10/08/2018 12:10 PM, Volker Simonis wrote: > > @Aleksey Shipilev : can you please check if this new version of my > > patch also works for you? > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018

Re: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives)

On Mon, Oct 8, 2018 at 10:38 AM Aleksey Shipilev wrote: > > On 10/08/2018 10:34 AM, Volker Simonis wrote: > > Instead of checking the JVM_VARIANT, I check for ENABLE_CDS. But as > > far as I see, that still doesn't help for the 'minmal' variant. I > > think the r

Re: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

would be great if this could be used to fix minimal/zero build, > too. > > Best regards, > Martin > > > -Original Message- > From: hotspot-runtime-dev On > Behalf Of Volker Simonis > Sent: Montag, 8. Oktober 2018 10:19 > To: build-dev ; > hotspot-runtime

Re: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives)

Hi Aleksey, I've just posted a fix for this issue as well (the AIX build is broken as well). http://mail.openjdk.java.net/pipermail/build-dev/2018-October/023559.html Instead of checking the JVM_VARIANT, I check for ENABLE_CDS. But as far as I see, that still doesn't help for the 'minmal'

RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS

Hi, can I please have a review for the following trivial build fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ https://bugs.openjdk.java.net/browse/JDK-8211837 It makes no sense to try to create a default CDS archive on VMs which don't support CDS at all. We already have

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

Hi Tim, Jeff, Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) https://bugs.openjdk.java.net/browse/JDK-8208089 Could you please provide a summary of which of these features are already available since

Re: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029)

Hi Lutz, the change looks good. Thanks for cleaning this up, Volker On Fri, Sep 28, 2018 at 12:30 PM Aleksey Shipilev wrote: > > On 09/27/2018 04:28 PM, Schmidt, Lutz wrote: > > re break vs. ShouldNotReachHere(), I tried to change semantics as little as > > possible. After > > discussion with

Re: RFR 8208183: update HSDIS plugin license to UPL

On Tue, Aug 21, 2018 at 12:14 PM, Magnus Ihse Bursie wrote: > >> Yes, please. And it would be absolutely fantastic to actually build it and >> ship it in default >> OpenJDK images :) > > > Am I correct in understanding that there are no more legal barriers towards > doing such a thing anymore? >

Re: RFR: 8206106: [solaris sparc] jck tests api/javax_print/PrintService failing

Hi Phil, I've actually thought about the same trick yesterday in the evening and just wanted to try it out when I saw your mail. It indeed works quite nicely and I can confirm that it solves the problem on our side as well. I've also opened an issue in the CUPS bug tracker:

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

On Thu, Jun 28, 2018 at 8:02 PM, wrote: > 2018/6/27 23:21:34 -0700, volker.simo...@gmail.com: >> On Thu, Jun 28, 2018 at 12:08 AM, mark.reinh...@oracle.com wrote: >>> ... >>> >>> “OpenJDK” is a trademarked term, per the OpenJDK Trademark Notice [1]. >>> As such it should be used only as an

Re: RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH

Hi Martin, Erik, thanks for the reviews! Regards, Volker On Wed, Jun 27, 2018 at 5:53 PM, Erik Joelsson wrote: > Looks ok to me. > > /Erik > > > > On 2018-06-27 03:26, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the foll

Re: 11 RFR (XS) 8205956: Fix usage of “OpenJDK” in build and test instructions

On Thu, Jun 28, 2018 at 12:08 AM, wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8205956 > Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/ > > Quick links to handier HTML diffs: > > http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html >

RFR(XXS): 8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH

Hi, can I please have a review for the following tiny test fix (I'm actually not sure which would be the appropriate mailing list for this fix so please redirect if necessary): http://cr.openjdk.java.net/~simonis/webrevs/2018/8205916/ https://bugs.openjdk.java.net/browse/JDK-8205916 The test

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

On Tue, Jun 19, 2018 at 9:25 AM, David Holmes wrote: > Hi Volker, > > On 19/06/2018 4:50 PM, Volker Simonis wrote: >> >> On Tue, Jun 19, 2018 at 6:54 AM, David Holmes >> wrote: >>> >>> Hi Volker, >>> >>> v3 looks much cleaner

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

Thanks, > David > > > On 19/06/2018 2:04 AM, Volker Simonis wrote: >> >> On Mon, Jun 18, 2018 at 8:17 AM, David Holmes >> wrote: >>> >>> Hi Volker, >>> >>> src/hotspot/share/runtime/globals.hpp >>> >>> This change s

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

ill something missing. Regards, Volker > ?? > > Thanks, > David > - > > > > > > On 15/06/2018 12:26 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following fix: >> >> http://cr.openjdk.java.net/~simonis/webre

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

Hi Mattias, the change looks good. Could you please also update the comment in the line above which still reads "STAT". Also, maybe "STATI" would be a better name choice (longer is better :) because the probability of a clash is lower (and it would nicely align with QUEUE in the comments :) But

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

need it because the excluded code references methods (e.g. 'StringTable::create_archived_string()') which are not compiled into libjvm.so if we disable CDS. > > Best Regards, Thomas > > On Thu, Jun 14, 2018 at 4:26 PM, Volker Simonis > wrote: >> Hi, >> >> can I

Re: RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

base, > char*) \ >nonstatic_field(FileMapInfo::FileMapHeader::space_info, _used, > size_t) \ > > \ > > Thanks, > Jiangli > > On Jun 14, 2018, at 7:26 AM, Volker Simonis > wrote: > > Hi, > &

RFR(M): 8204965: Fix '--disable-cds' and disable CDS on AIX by default

Hi, can I please have a review for the following fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8204965/ https://bugs.openjdk.java.net/browse/JDK-8204965 CDS does currently not work on AIX because of the way how we reserve/commit memory on AIX. The problem is that we're using a

Re: RFR(XS): 8204684: [AIX] Build of libjli_static broken after change 8204572 (SetupJdkLibrary)

Hi Erik, Thomas, thanks for the quick review! Regards, Volker On Mon, Jun 11, 2018 at 5:59 PM, Thomas Stüfe wrote: > This looks good and I can confirm fixes our AIX build, > > Thanks for fixing! > > > ..Thomas > > > On Mon, Jun 11, 2018 at 4:48 PM, Volker Simonis &

RFR(XS): 8204684: [AIX] Build of libjli_static broken after change 8204572 (SetupJdkLibrary)

Hi, can I please have a review for the following trivial build change which fixes a build problem on AIX when building libjli_static: http://cr.openjdk.java.net/~simonis/webrevs/2018/8204684/ https://bugs.openjdk.java.net/browse/JDK-8204684 The reason is that change 8204572 forgot to add

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

On Tue, Jun 5, 2018 at 6:47 PM, Erik Joelsson wrote: > Hello Volker, > > On 2018-06-05 09:35, Volker Simonis wrote: >> >> Hi Erik, >> >> you wrote: "Note that this applies to the build time C++ flags, not >> the compiler in the JVM itself." So wha

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

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

Re: License and Usage Terms of generated API documentation

On Thu, May 3, 2018 at 12:21 PM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > On 2018-05-02 17:03, Volker Simonis wrote: >> >> Hi, >> >> we currently build OpenJDK and make it available from various sources >> (e.g. GitHub, apt-get se

License and Usage Terms of generated API documentation

Hi, we currently build OpenJDK and make it available from various sources (e.g. GitHub, apt-get server, DockerHub). We also build the API documentation (i.e. JavaDoc) and would like to make it available from our project page as well. However the default API doc produced by the build looks as

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

Hi Matthias, after Bhaktavatsal Reddy's report about the problems with "-qvisibility" with xlC 13 and taking into account that we can't test this anyway because we don't currently have xlC 13 on our machines I think it would be best to completely remove this option for now on AIX. Once we get

Re: RFR(XS): 8201584: Fix configure on SLES 11 after 8201483

Looks good! Thanks for fixing, Volker On Mon, Apr 16, 2018 at 2:15 PM, Lindenmaier, Goetz wrote: > Hi Magnus, > > yes, that works too: > http://cr.openjdk.java.net/~goetz/wr18/8201584-fixSLES11configure/02/ > Can I push this right away if I get a second review? > >

Re: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

On Mon, Apr 16, 2018 at 11:30 AM, Severin Gehwolf wrote: > Hi Andrew, > > On Mon, 2018-04-16 at 09:47 +0100, Andrew Haley wrote: >> On 04/13/2018 02:40 PM, Severin Gehwolf wrote: >> > ++ /usr/bin/tee >> >

Re: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

already fine without this, > but a jdk-submit would be prudent .. > I did start Solaris and AIX builds before I left the office. I can certainly also submit a job to JDK-submit, but at least hs-submit wasn’t working at all (i.e. didn’t return any results). > -phil. > > On 04/13/2018 09:22 A

Re: RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

wrote: > Hello Volker, > > The change looks good, but now that we no longer link against > libawt_headless, we should also remove the make dependency a few lines down. > (Should have been done already for Solaris.) > > /Erik > > > > On 2018-04-13 06:28, Volker Simonis w

RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless

Hi, can I please have a review for this tiny AIX cleanup: http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ https://bugs.openjdk.java.net/browse/JDK-8201524 This is a follow up change of JDK-8196516 which discovered that on AIX libfontmanager is always linked against libawt_headless at

Re: RFR: JDK-8201483 Make it possible to disable JVM features

On Thu, Apr 12, 2018 at 11:30 PM, David Holmes wrote: > On 12/04/2018 11:33 PM, Magnus Ihse Bursie wrote: >> >> On 2018-04-12 14:15, David Holmes wrote: >>> >>> Hi Magnus, >>> >>> On 12/04/2018 9:39 PM, Magnus Ihse Bursie wrote: It is currently easy to add new

Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Hi Severin, I'm currently looking at the AIX-side of this bug. The problem I see with your solution is that it uses LDFLAGS (which is generic) to filter out Linux specific linker flags. If we would extend this to AIX, we would have to add yet another substitution for AIX which filters out

Re: Problem building openjdk using cygwin

rosoft Visual Studio > ``` > but it seems not working because I get the same error. Can you give some > tips please? Sorry if I'm newbie, I'm just interested in some JEPs and want > to test them in a project to see if I can deploy it later. > Many thanks. > > On Thu, Mar 29, 201

Re: Problem building openjdk using cygwin

Hi Alireza, it seems you don’t have short file names enabled for the “Program Files” directory. Notice that you have short file names enabled for “c:\” (i.e. you have “progra~2”). You have to first enable short file names for the “Program Files” directory (see for example

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

Hi Magnus, thanks for addressing this long standing issue! I haven't looked at the changes, but just want to share some general and historical notes: - Compiling with "-fvisibility=hidden" which hides all symbols expect the ones explicitly exported with "__attribute__((visibility("default")))"

Re: [XXS] 8199858 : solaris-x86_64 : unpack200 fails linking with SS12u4

Hi Matthias, the change looks good. Can you please also update the copyright year before pushing (no need for a new webrev). Thanks, Volker On Tue, Mar 20, 2018 at 2:12 PM, Baesken, Matthias wrote: > Hello , could you please review this small fix for Solaris x86_64 ?

Friendly request: Update "Supported Build Platforms" Wiki page

Hi, could somebody please be so kind and update the "Supported Build Platforms" Wiki page [1] for OpenJDK 10 and possibly 11? Thanks a lot, Volker [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

  1   2   3   4   5   >