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 > >
