Re: RFR: 8275405: Linking error for classes with lambda template parameters and virtual functions [v2]
On Wed, 20 Oct 2021 12:23:28 GMT, Stefan Karlsson wrote:
>> We encountered the following linking error when trying to build Generational
>> ZGC on Windows:
>>
>> jvm.exp : error LNK2001: unresolved external symbol "const
>> ZBasicOopIterateClosure
>> >::`vftable'"
>> (??_7?$ZBasicOopIterateClosure@V6B@)
>>
>>
>> I narrowed this down to a simple reproducer, which doesn't link when built
>> through the HotSpot build system:
>>
>> #include
>> std::function = [](){};
>>
>>
>> I found that we have a line in our make files that filters out symbols that
>> contain the string vftable (though it checks the mangled name, so a bit hard
>> to find):
>>
>> else ifeq ($(call isTargetOs, windows), true)
>> DUMP_SYMBOLS_CMD := $(DUMPBIN) -symbols *.obj
>> FILTER_SYMBOLS_AWK_SCRIPT := \
>> '{ \
>> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/) print $$7; \
>> }'
>>
>>
>> The following line prints the vftable symbol if it doesn't contain the
>> string 'type_info':
>> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/) print $$7;
>>
>> The printed values are added to a list of symbols that get filtered out of
>> the mapfile, which is then passed to the linker.
>>
>> I can get the code to link if I add a second exception for vftable symbols
>> containing the string 'lambda':
>> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/ && $$7 !~ /lambda/) print $$7;
>>
>> I did an additional experiment where I completely removed this filtering of
>> vftable symbols. When I did that the linker complained that we used more
>> than 64K symbols.
>
> Stefan Karlsson has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix typo
Thanks for reviewing!
-
PR: https://git.openjdk.java.net/jdk/pull/6030
Integrated: 8275405: Linking error for classes with lambda template parameters and virtual functions
On Wed, 20 Oct 2021 08:11:34 GMT, Stefan Karlsson wrote:
> We encountered the following linking error when trying to build Generational
> ZGC on Windows:
>
> jvm.exp : error LNK2001: unresolved external symbol "const
> ZBasicOopIterateClosure
> >::`vftable'"
> (??_7?$ZBasicOopIterateClosure@V6B@)
>
>
> I narrowed this down to a simple reproducer, which doesn't link when built
> through the HotSpot build system:
>
> #include
> std::function = [](){};
>
>
> I found that we have a line in our make files that filters out symbols that
> contain the string vftable (though it checks the mangled name, so a bit hard
> to find):
>
> else ifeq ($(call isTargetOs, windows), true)
> DUMP_SYMBOLS_CMD := $(DUMPBIN) -symbols *.obj
> FILTER_SYMBOLS_AWK_SCRIPT := \
> '{ \
> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/) print $$7; \
> }'
>
>
> The following line prints the vftable symbol if it doesn't contain the string
> 'type_info':
> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/) print $$7;
>
> The printed values are added to a list of symbols that get filtered out of
> the mapfile, which is then passed to the linker.
>
> I can get the code to link if I add a second exception for vftable symbols
> containing the string 'lambda':
> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/ && $$7 !~ /lambda/) print $$7;
>
> I did an additional experiment where I completely removed this filtering of
> vftable symbols. When I did that the linker complained that we used more than
> 64K symbols.
This pull request has now been integrated.
Changeset: 09f5235c
Author:Stefan Karlsson
URL:
https://git.openjdk.java.net/jdk/commit/09f5235c65de546640d5f923fa9369e28643c6ed
Stats: 18 lines in 1 file changed: 17 ins; 0 del; 1 mod
8275405: Linking error for classes with lambda template parameters and virtual
functions
Reviewed-by: ihse, pliden
-
PR: https://git.openjdk.java.net/jdk/pull/6030
Re: RFR: 8275569: Add linux-aarch64 to test-make profiles
On Wed, 20 Oct 2021 18:46:14 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change that adds "linux-aarch64" to test make > profile. Marked as reviewed by ihse (Reviewer). I assume the tests are passing on aarch64. - PR: https://git.openjdk.java.net/jdk/pull/6051
Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v9]
> This PR contains the API and implementation changes for JEP-419 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision: - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm) - Merge branch 'master' into JEP-419 - Fix copyright header in TestArrayCopy - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!) - * use `invokeWithArguments` to simplify new test - Add test for liveness check with high-aririty downcalls (make sure that if an exception occurs in a downcall because of liveness, ref count of other resources are left intact). - * Fix javadoc issue in VaList * Fix bug in concurrent logic for shared scope acquire - Address review comments - Apply suggestions from code review Co-authored-by: Paul Sandoz - Fix TestLinkToNativeRBP test - ... and 5 more: https://git.openjdk.java.net/jdk/compare/aeabb3df...5c69eabf - Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/414952ad..5c69eabf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=07-08 Stats: 25202 lines in 587 files changed: 18962 ins; 4240 del; 2000 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907
Re: RFR: 8275569: Add linux-aarch64 to test-make profiles
On Wed, 20 Oct 2021 18:46:14 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change that adds "linux-aarch64" to test make > profile. Magnus, thank you for review. The test make build passes on linux-aarch64. - PR: https://git.openjdk.java.net/jdk/pull/6051
Integrated: 8275569: Add linux-aarch64 to test-make profiles
On Wed, 20 Oct 2021 18:46:14 GMT, Mikhailo Seledtsov wrote: > Please review this trivial change that adds "linux-aarch64" to test make > profile. This pull request has now been integrated. Changeset: af146501 Author:Mikhailo Seledtsov URL: https://git.openjdk.java.net/jdk/commit/af14650127de47058b958be411503584c0ba6323 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8275569: Add linux-aarch64 to test-make profiles Reviewed-by: ihse - PR: https://git.openjdk.java.net/jdk/pull/6051
Re: Unable to build Client/Server variant for OpenJDK-11 on ARMv7-A
Thank you again, that solved that problem, and now another has arose. It can run and compile on our embedded system, but sound no longer functions and I'm now at the point where I need to ask for help again. Running the same code on Java 8 sound works with no errors, running it on the newly built 11 crashes every time. It doesn't seem to be able to recognize the mixer properly in 11 and I have not been able to figure out why and whether it's a problem with my build, or a bug, or some other configuration I've still been missing. I've tried using client, server, and zero variants, with and without fastdebug enabled, I've also tried using two different toolchains, and even got a build on the older mercurial tree working and tried that as well. I've also tried multiple different sound files, and they all have the same error. I've also tried setting the sound.properties to: javax.sound.sampled.Clip=com.sun.media.sound.DirectAudioDeviceProvider javax.sound.sampled.Port=com.sun.media.sound.PortMixerProvider javax.sound.sampled.SourceDataLine=com.sun.media.sound.DirectAudioDeviceProvider javax.sound.sampled.TargetDataLine=com.sun.media.sound.DirectAudioDeviceProvider The only major difference I've noticed between my build of 11, and the working build of 8, is 8 also has a libjsoundalsa.so, and my 11 build does not. Here's the output of java8 version and java11 version too: # java8 -version java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) Client VM (build 25.144-b01, mixed mode) [java -version openjdk version "11.0.14-internal" 2022-01-18 OpenJDK Runtime Environment (build 11.0.14-internal+0-adhoc.johnc.jdk11u-dev) OpenJDK Client VM (build 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed mode) The app I've been collecting information with just gets the mixers, and any data lines and prints their values, and then plays a .wav file using SourceDataLine, and again with Clip. I use -Daudio.mixer="M1 PCM [default]" because in the Java 11 build, setting it to null for the default just returns null, and it doesn't even return the "Found Audio Mixer" line. If it helps, here is the java itself: https://pastebin.com/CCfUWTTf The output is as follows: Java 8 output # java8 -Daudio.mixer="M1 PCM [default]" AudioFormats SuccessBuzzer.wav Found audio mixer: M1 PCM [default] Supported Lines of default mixer (M1 PCM [default]): Mixer ClassName: com.sun.media.sound.DirectAudioDeviceProvider$DirectAudioDeviceInfo Mixer Desc: Direct Audio Device: sun7i PCM, M1 PCM, sun7i PCM Vendor: ALSA (http://www.alsa-project.org) M1 PCM [default]--- interface SourceDataLine supporting 8 audio formats, and buffers of at least 32 bytes - com.sun.media.sound.DirectAudioDevice$DirectSDL@873330 M1 PCM [default]--- interface Clip supporting 8 audio formats, and buffers of at least 32 bytes - com.sun.media.sound.DirectAudioDevice$DirectClip@19d7047 com.sun.media.sound.DirectAudioDevice@16ec8df --- interface TargetDataLine supporting 8 audio formats, and buffers of at least 32 bytes - com.sun.media.sound.DirectAudioDevice$DirectTDL@ec Mixer Num Source Info Lines: 2 Mixer Num Target Info Lines: 1 interface SourceDataLine supporting 8 audio formats, and buffers of at least 32 bytes max buffer size: -1 min buffer size: 32 Supported Audio formats: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian encoding: PCM_SIGNED channels: 1 frame size [bytes]: 2 sample size [bit]: 16 big endian: false line supported: true PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian encoding: PCM_SIGNED channels: 1 frame size [bytes]: 2 sample size [bit]: 16 big endian: true line supported: true PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian encoding: PCM_SIGNED channels: 2 frame size [bytes]: 4 sample size [bit]: 16 big endian: false line supported: true PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian encoding: PCM_SIGNED channels: 2 frame size [bytes]: 4 sample size [bit]: 16 big endian: true line supported: true PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame, encoding: PCM_SIGNED channels: 1 frame size [bytes]: 1 sample size [bit]: 8 big endian: false line supported: true PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame, encoding: PCM_UNSIGNED channels: 1 frame size [bytes]: 1 sample size [bit]: 8 big endian: false line supported: true PCM_SIGNED un
Re: RFR: 8275745: Reproducible copyright headers
On Sat, 28 Nov 2020 23:14:35 GMT, Emmanuel Bourg wrote: > The copyright headers are generated at build time, and the year inserted in > the template depends on the current date. This means the headers are not > reproducible if the project is built a year later. The year in the headers > could be derived from the SOURCE_DATE_EPOCH environment variable to make the > build reproducible (this variable is already used in other parts of the > build). Dummy comment to keep this issue alive (auto closing after 8 weeks of inactivity is a bad idea) . . Unfortunately I don't have a JBS account, so I'm stuck here bumping this PR every 4 weeks until someone notices it. . Yes, 5 months later I now understand that the GitHub issue tracker isn't the right entry point to contribute to OpenJDK, sadly. . - PR: https://git.openjdk.java.net/jdk/pull/1498
RFR: 8275745: Reproducible copyright headers
The copyright headers are generated at build time, and the year inserted in the template depends on the current date. This means the headers are not reproducible if the project is built a year later. The year in the headers could be derived from the SOURCE_DATE_EPOCH environment variable to make the build reproducible (this variable is already used in other parts of the build). - Commit messages: - Make the copyright headers reproducible when the SOURCE_DATE_EPOCH environment variable is defined Changes: https://git.openjdk.java.net/jdk/pull/1498/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1498&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275745 Stats: 24 lines in 2 files changed: 18 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1498.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1498/head:pull/1498 PR: https://git.openjdk.java.net/jdk/pull/1498
Re: RFR: 8275745: Reproducible copyright headers
On Sat, 28 Nov 2020 23:14:35 GMT, Emmanuel Bourg wrote: > The copyright headers are generated at build time, and the year inserted in > the template depends on the current date. This means the headers are not > reproducible if the project is built a year later. The year in the headers > could be derived from the SOURCE_DATE_EPOCH environment variable to make the > build reproducible (this variable is already used in other parts of the > build). You should link an issue to this patch so that a Request-For-Review email will be sent to the corresponding mailing list. Or they may not notice your patch. Hi Emmanuel Bourg, I'm not quite sure whether this PR is useful since I'm not familiar with the make system. I think you can just send an email to build-dev@openjdk.java.net(You may need to subscribe [it](https://mail.openjdk.java.net/mailman/listinfo/build-dev) before), the related folks/experts would review your change or give some meaningful feedbacks if they think it's worth doing it. Good Luck! Thanks, Yang - PR: https://git.openjdk.java.net/jdk/pull/1498
Re: RFR: 8275745: Reproducible copyright headers
On Sat, 28 Nov 2020 23:14:35 GMT, Emmanuel Bourg wrote: > The copyright headers are generated at build time, and the year inserted in > the template depends on the current date. This means the headers are not > reproducible if the project is built a year later. The year in the headers > could be derived from the SOURCE_DATE_EPOCH environment variable to make the > build reproducible (this variable is already used in other parts of the > build). I'm impressed you noticed this! Do you test reproducibility by changing the date drastically? I agree that the gensrc files should be fixed. However, we already have a configure option `--with-copyright-year` and I think the correct solution is to propagate that value into the Java tools that creates the source code. I can't set the issue for you, but if you prepend "8275745: " to the PR title, things will work out. - PR: https://git.openjdk.java.net/jdk/pull/1498
Re: RFR: 8275745: Reproducible copyright headers
On Thu, 21 Oct 2021 23:33:35 GMT, Magnus Ihse Bursie wrote: >> The copyright headers are generated at build time, and the year inserted in >> the template depends on the current date. This means the headers are not >> reproducible if the project is built a year later. The year in the headers >> could be derived from the SOURCE_DATE_EPOCH environment variable to make the >> build reproducible (this variable is already used in other parts of the >> build). > > I can't set the issue for you, but if you prepend "8275745: " to the PR > title, things will work out. @magicus Thank you for filing the issue! > Do you test reproducibility by changing the date drastically? Yes, Debian has a test framework dedicated to finding reproducibility issue such as this one. > we already have a configure option --with-copyright-year and I think the > correct solution is to propagate that value into the Java tools that creates > the source code. Why not, but ideally if `--with-copyright-year` isn't specified at build time it should defaults to the year specified by the `SOURCE_DATE_EPOCH` environment variable (if specified). The idea is to have a single parameter, universal across projects, that automatically makes any build reproducible without further configuration. - PR: https://git.openjdk.java.net/jdk/pull/1498
