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, 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 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
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' ; '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: 8236714: enable link-time section-gc for linux to remove unused code
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
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). > >>
