Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v2]

2023-05-04 Thread Justin King
, Jan 10, 2023 at 9:09 AM Ioi Lam wrote: > On Mon, 9 Jan 2023 15:48:48 GMT, Justin King wrote: > > >> I like this, but would compilers not complain about unused statements? > > > > I don't believe so, at least not based on current options. Other > projects use similar

Re: RFR: JDK-8305090: Some NMT tests broken when running under ASan

2023-04-05 Thread Justin King
On Tue, 28 Mar 2023 15:05:41 GMT, Justin King wrote: > This change fixes or skips some NMT tests when running under ASan, as well as > fixing a leak. > > - `allocator_may_return_null=1` is added as the default is `0`, meaning ASan > will never return `nullptr` and will ins

RFR: JDK-8305090: Some NMT tests broken when running under ASan

2023-03-28 Thread Justin King
This change fixes or skips some NMT tests when running under ASan, as well as fixing a leak. - `allocator_may_return_null=1` is added as the default is `0`, meaning ASan will never return `nullptr` and will instead crash. NMT tests check that large allocations return `nullptr` so those do not

Re: RFR: 8303485: Replacing os.name for operating system customization [v2]

2023-03-13 Thread Justin King
On Fri, 10 Mar 2023 21:21:56 GMT, Roger Riggs wrote: >> Improvements to support OS specific customization for JDK internal use: >> - To select values and code; allowing elimination of unused code and values >> - Optionally evaluated by build processes, compilation, or archiving (i.e. >> CDS)

Re: RFR: JDK-8301998: Update HarfBuzz to 7.0.1 [v2]

2023-03-10 Thread Justin King
On Thu, 9 Mar 2023 06:12:26 GMT, Harshitha Onkar wrote: >> HarfBuzz library updated from v4.4.1 to v7.0.1 >> >> - harfbuzz.md file updated >> - Added -DHB_NO_VISIBILITY to HARFBUZZ_CFLAGS in Awt2DLibraries.gmk to avoid >> build issues on linux and macos targets. >> - GPOS.hh moved to Layout to

Re: RFR: 8303485: Replacing os.name for operating system customization

2023-03-10 Thread Justin King
On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > Improvements to support OS specific customization for JDK internal use: > - To select values and code; allowing elimination of unused code and values > - Optionally evaluated by build processes, compilation, or archiving (i.e. > CDS) > -

Re: RFR: 8303485: Replacing os.name for operating system customization

2023-03-09 Thread Justin King
On Thu, 9 Mar 2023 16:11:19 GMT, Roger Riggs wrote: > > Has this totally killed of BSD support on the JDK side? I thought building > > non-macOS BSD was still viable, but perhaps not - certainly not after this > > change. > > I haven't found any use of BSD and I don't think the build supports

Re: RFR: 8303485: Replacing os.name for operating system customization

2023-03-08 Thread Justin King
Let's please not kill generic BSD support if at all possible. There is NetBSD, OpenBSD, FreeBSD, and DragonflyBSD. I know FreeBSD and NetBSD have OpenJDK 19 and 17 respectively. On Wed, Mar 8, 2023, 6:54 PM David Holmes wrote: > On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote: > > >

Re: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC [v3]

2023-02-26 Thread Justin King
On Sun, 26 Feb 2023 06:10:14 GMT, David Holmes wrote: > The workaround should have been done under JDK-8302817. This issue should > have simply disabled RTTI in the build system. I'll split the RTTI disable to a separate PR Monday, leave this one as the workaround, and rename to the other

Re: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC [v3]

2023-02-24 Thread Justin King
rely on RTTI for Windows-specific > code while also decreasing the resulting binary size. > > Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI > was causing a subset of serviceability agent tests to fail. Justin King has updated the pull request with a new ta

Re: RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC [v2]

2023-02-24 Thread Justin King
rely on RTTI for Windows-specific > code while also decreasing the resulting binary size. > > Cheers to @alexmenkov for finding the tricky root cause of why disabling RTTI > was causing a subset of serviceability agent tests to fail. Justin King has updated the pull request incrementally wit

RFR: JDK-8303166: Disable RTTI for Hotspot when building with MSVC

2023-02-24 Thread Justin King
Disable RTTI `-GR-` for Hotspot when building with MSVC. This drops the size of `jvm.dll` by roughly 1 MB. Hotspot does not rely on RTTI and it is disabled for both GCC/Clang and Open XL C/C++ already. This change disables it for MSVC, ensuring we do not accidently rely on RTTI for

Re: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan

2023-02-21 Thread Justin King
On Wed, 22 Feb 2023 00:29:27 GMT, David Holmes wrote: > If ASAN support needs `-debug` wouldn't it make sense to restrict its use to > debug builds? MSVC named it poorly, IMO. It just means generate PDB basically. It doesn't *need* it, just complains that stack traces are better with it.

Integrated: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan

2023-02-21 Thread Justin King
On Tue, 21 Feb 2023 16:40:07 GMT, Justin King wrote: > Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots > of warnings. This pull request has now been integrated. Changeset: ce6de371 Author:Justin King URL: https://git.openjdk.org/jdk/

Re: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan

2023-02-21 Thread Justin King
On Tue, 21 Feb 2023 16:40:07 GMT, Justin King wrote: > Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots > of warnings. Linux GHA tests look unrelated. This is MSVC-only change. - PR: https://git.openjdk.org/jdk/pull/12693

Re: RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan

2023-02-21 Thread Justin King
On Tue, 21 Feb 2023 16:40:07 GMT, Justin King wrote: > Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots > of warnings. @magicus Trivial change for ASan under MSVC. Was giving it a run through tier1 today and noticed MSVC complaining heavily in build logs

RFR: JDK-8303010: Add /DEBUG to LDFLAGS for MSVC with ASan

2023-02-21 Thread Justin King
Add `/DEBUG` to `LDFLAGS` for MSVC with ASan. Without it MSVC produces lots of warnings. - Commit messages: - Add -debug to LDFLAGS under MSVC with ASan Changes: https://git.openjdk.org/jdk/pull/12693/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12693=00 Issue:

Integrated: JDK-8302599: Extend ASan support to Microsoft Visual C++

2023-02-20 Thread Justin King
On Wed, 15 Feb 2023 17:53:49 GMT, Justin King wrote: > Update build-related infrastructure to support building with ASan under > Microsoft Visual C++. This pull request has now been integrated. Changeset: 0bf3a53e Author:Justin King URL: https://git.openjdk.org/jdk/

Re: RFR: JDK-8300531: Update MSVC optimization flags to match GCC/Clang [v10]

2023-02-19 Thread Justin King
I'll work on some benchmark comparisons. On Sat, Feb 18, 2023, 1:38 PM Magnus Ihse Bursie wrote: > On Sat, 18 Feb 2023 18:21:44 GMT, Justin King wrote: > > >> Update MSVC CFlags to be more consistent with other compilers. Also > disables RTTI in a simliar manner to GCC

Re: RFR: JDK-8300531: Update MSVC optimization flags to match GCC/Clang [v10]

2023-02-18 Thread Justin King
On Sat, 18 Feb 2023 18:21:44 GMT, Justin King wrote: >> Update MSVC CFlags to be more consistent with other compilers. Also disables >> RTTI in a simliar manner to GCC/Clang for the JVM. > > Justin King has updated the pull request incrementally with one additional >

Re: RFR: JDK-8300531: Update MSVC optimization flags to match GCC/Clang [v10]

2023-02-18 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add comments clarifying -Oy- Sign

Re: RFR: JDK-8300531: Update MSVC optimization flags to match GCC/Clang [v9]

2023-02-18 Thread Justin King
On Wed, 15 Feb 2023 21:21:47 GMT, Justin King wrote: >> Update MSVC CFlags to be more consistent with other compilers. Also disables >> RTTI in a simliar manner to GCC/Clang for the JVM. > > Justin King has updated the pull request incrementally with one additional >

Re: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++ [v2]

2023-02-18 Thread Justin King
On Thu, 16 Feb 2023 16:27:16 GMT, Magnus Ihse Bursie wrote: >> Justin King has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update based on review >> >> Signed-off-by: Justin King >

Re: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++ [v2]

2023-02-18 Thread Justin King
> Update build-related infrastructure to support building with ASan under > Microsoft Visual C++. Justin King has updated the pull request incrementally with one additional commit since the last revision: Update based on review Signed-off-by: Justin King - C

Re: RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++

2023-02-16 Thread Justin King
/asan_flags.cpp. GCC uses the same runtime library as does MSVC. On Thu, Feb 16, 2023 at 5:38 AM Thomas Stüfe wrote: > I’m curious, why does the options function have to be exported? Who is > consuming it? > > On Wed 15. Feb 2023 at 19:01, Justin King wrote: > >> Update build-r

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]

2023-02-15 Thread Justin King
On Wed, 15 Feb 2023 21:21:47 GMT, Justin King wrote: >> Update MSVC CFlags to be more consistent with other compilers. Also disables >> RTTI in a simliar manner to GCC/Clang for the JVM. > > Justin King has updated the pull request incrementally with one additional >

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]

2023-02-15 Thread Justin King
On Thu, 16 Feb 2023 02:03:35 GMT, David Holmes wrote: > > Looks like serviceability might rely on RTTI on Windows. > > Can you point to the code please? We should not be using RTTI. Removing /GR- makes the tests pass. I think somewhere we are indirectly relying on RTTI for Windows. Maybe

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]

2023-02-15 Thread Justin King
On Tue, 14 Feb 2023 18:42:07 GMT, Justin King wrote: >> Update MSVC CFlags to be more consistent with other compilers. Also disables >> RTTI in a simliar manner to GCC/Clang for the JVM. > > Justin King has updated the pull request incrementally with one additional >

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v9]

2023-02-15 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Revert usage of /GR- Signed-off-by: Justi

RFR: JDK-8302599: Extend ASan support to Microsoft Visual C++

2023-02-15 Thread Justin King
Update build-related infrastructure to support building with ASan under Microsoft Visual C++. - Commit messages: - Move comment to appropriate location - Use elif instead of separate if - Only pass -fsanitize=address to linker for Clang/GCC - Update asan_default_options.c with

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]

2023-02-14 Thread Justin King
On Tue, 14 Feb 2023 18:42:07 GMT, Justin King wrote: >> Update MSVC CFlags to be more consistent with other compilers. Also disables >> RTTI in a simliar manner to GCC/Clang for the JVM. > > Justin King has updated the pull request incrementally with one additional >

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v8]

2023-02-14 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Reposition -Oy- Signed-off-by: Justi

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v7]

2023-02-14 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Reposition -Oy- Signed-off-by: Justi

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v6]

2023-02-14 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Add -Oy- Signed-off-by: Justi

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v4]

2023-02-14 Thread Justin King
On Tue, 14 Feb 2023 17:21:51 GMT, Justin King wrote: >> Update MSVC CFlags to be more consistent with other compilers. Also disables >> RTTI in a simliar manner to GCC/Clang for the JVM. > > Justin King has updated the pull request with a new target base due to a > merge

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v5]

2023-02-14 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove -Ob3 Signed-off-by: Justi

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v4]

2023-02-14 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Update MSVC

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]

2023-02-08 Thread Justin King
On Wed, 8 Feb 2023 06:58:52 GMT, Thomas Stuefe wrote: > I read through your explanation, and through the [design > docs](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument), > but my question remains unanswered. See below. > > > > Metaspace objects hold

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]

2023-02-08 Thread Justin King
On Wed, 8 Feb 2023 06:45:28 GMT, Thomas Stuefe wrote: > The informal rule is that ongoing discussions should be closed and that > nobody strongly objects to a change. Two reviewers are easy to come by. The > point of this rule is that you have a reasonable chance to block changes you >

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]

2023-02-07 Thread Justin King
On Wed, 8 Feb 2023 02:53:51 GMT, David Holmes wrote: > The bot can only check the required number of Reviewers (strictly 1 per > OpenJDK rules but changeable as here via `/reviewers` command) but it doesn't > know about the informal rules such as having reviewers from each affected > area

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]

2023-02-07 Thread Justin King
On Tue, 7 Feb 2023 15:40:34 GMT, Justin King wrote: >> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been >> used to identify multiple leaks so far. It can run most of the test suite >> except those that also fail with ASan, which is being lo

Integrated: JDK-8298445: Add LeakSanitizer support in HotSpot

2023-02-07 Thread Justin King
On Thu, 26 Jan 2023 17:33:28 GMT, Justin King wrote: > Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been > used to identify multiple leaks so far. It can run most of the test suite > except those that also fail with ASan, which is being looked at s

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v4]

2023-02-07 Thread Justin King
On Tue, 7 Feb 2023 15:32:11 GMT, Justin King wrote: >> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been >> used to identify multiple leaks so far. It can run most of the test suite >> except those that also fail with ASan, which is being lo

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v6]

2023-02-07 Thread Justin King
; > **Caveats:** > - By default ASan enables LSan, however we explicitly disable it unless > `--enable-lsan` is given. It is useful to be able to use ASan without LSan. > Using LSan by itself is less likely to be useful and will probably not work, > but its still possible curren

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v5]

2023-02-07 Thread Justin King
; > **Caveats:** > - By default ASan enables LSan, however we explicitly disable it unless > `--enable-lsan` is given. It is useful to be able to use ASan without LSan. > Using LSan by itself is less likely to be useful and will probably not work, > but its still possible curren

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]

2023-02-07 Thread Justin King
On Tue, 7 Feb 2023 13:49:55 GMT, Magnus Ihse Bursie wrote: >> Justin King has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Fix grammatical error >> >>Signed-off-by: Justin King >

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v4]

2023-02-07 Thread Justin King
; > **Caveats:** > - By default ASan enables LSan, however we explicitly disable it unless > `--enable-lsan` is given. It is useful to be able to use ASan without LSan. > Using LSan by itself is less likely to be useful and will probably not work, > but its still possible cur

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]

2023-02-03 Thread Justin King
On Fri, 3 Feb 2023 06:16:06 GMT, Thomas Stuefe wrote: > Thanks for the explanation. Do I understand correctly: You register address > ranges with LSAN, and at certain points (program exit?) the memory is > examined for pointers that point still to unreleased memory? Does LSAN > instrument

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]

2023-02-02 Thread Justin King
On Thu, 2 Feb 2023 06:34:56 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Support CDS >> >> Signed-off-by: Justin King > > Think

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]

2023-02-02 Thread Justin King
On Thu, 2 Feb 2023 06:06:04 GMT, David Holmes wrote: >> src/hotspot/share/runtime/arguments.cpp line 3979: >> >>> 3977: // LSAN relies on pointers to be natively aligned. Using compressed >>> class pointers breaks this >>> 3978: // expectation and results in nondeterministic leak reports.

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]

2023-02-02 Thread Justin King
On Thu, 2 Feb 2023 05:34:57 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Support CDS >> >> Signed-off-by: Justin King > > make/data/lsa

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v3]

2023-02-02 Thread Justin King
l possible currently. > - There are a series of tests that are upset due to the above flags being > forced false, as they rely on the arguments being supported. In the future > ideally these tests would be skipped nicely when LSan is enabled. Justin King has updated the pull request increm

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot

2023-02-01 Thread Justin King
On Thu, 26 Jan 2023 17:33:28 GMT, Justin King wrote: > Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been > used to identify multiple leaks so far. It can run most of the test suite > except those that rely on testing compressed oops or compressed class &

Re: RFR: JDK-8298445: Add LeakSanitizer support in HotSpot [v2]

2023-02-01 Thread Justin King
l possible currently. > - There are a series of tests that are upset due to the above flags being > forced false, as they rely on the arguments being supported. In the future > ideally these tests would be skipped nicely when LSan is enabled. Justin King has updated the pull request

RFR: JDK-8298445: Add LeakSanitizer support in HotSpot

2023-01-31 Thread Justin King
Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been used to identify multiple leaks so far. It can run most of the test suite except those that rely on testing compressed oops, compressed class pointers, or CDS. It is especially useful when combined with ASan, as LSan can

Integrated: JDK-8301097: Update GHA XCode to 12.5.1

2023-01-27 Thread Justin King
On Wed, 25 Jan 2023 16:20:28 GMT, Justin King wrote: > We are using 11.7 for x86 and 12.4 for aarch64. We should probably be using > the same version for both. I assume aarch64 is using a more recent one for > better aarch64 support in XCode. 12.4 is not the last release in the 12.x

RFR: JDK-8301097: Update GHA XCode to 12.5.1

2023-01-25 Thread Justin King
We are using 11.7 for x86 and 12.4 for aarch64. We should probably be using the same version for both. I assume aarch64 is using a more recent one for better aarch64 support in XCode. 12.4 is not the last release in the 12.x series, that would be 12.5.1, so we should update both to use that.

Integrated: JDK-8300592: ASan build does not correctly propagate options to some test launchers

2023-01-25 Thread Justin King
On Wed, 18 Jan 2023 20:40:40 GMT, Justin King wrote: > Update some custom launchers to set the default ASan options, without it the > tests fail due to incompatibility with LSan. Additionally adds `-fno-common` > for ASan build, as suggested by the docs. This pull request has

Re: RFR: JDK-8300592: ASan build does not correctly propagate options to some test launchers [v2]

2023-01-25 Thread Justin King
On Wed, 25 Jan 2023 15:28:14 GMT, Magnus Ihse Bursie wrote: >> Justin King has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Remove extra whitespace >> >>Signed-off-by: Justin King >>

Re: RFR: JDK-8300592: ASan build does not correctly propagate options to some test launchers [v3]

2023-01-25 Thread Justin King
> Update some custom launchers to set the default ASan options, without it the > tests fail due to incompatibility with LSan. Additionally adds `-fno-common` > for ASan build, as suggested by the docs. Justin King has updated the pull request incrementally with one additional com

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v3]

2023-01-25 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes b

Re: RFR: JDK-8300592: ASan build does not correctly propagate options to some test launchers [v2]

2023-01-23 Thread Justin King
> Update some custom launchers to set the default ASan options, without it the > tests fail due to incompatibility with LSan. Additionally adds `-fno-common` > for ASan build, as suggested by the docs. Justin King has updated the pull request incrementally with two additional comm

Re: RFR: JDK-8300592: ASan build does not correctly propagate options to some test launchers

2023-01-23 Thread Justin King
On Wed, 18 Jan 2023 20:40:40 GMT, Justin King wrote: > Update some custom launchers to set the default ASan options, without it the > tests fail due to incompatibility with LSan. Additionally adds `-fno-common` > for ASan build, as suggested by the docs. > I think this sho

Re: RFR: JDK-8300592: ASan build does not correctly propagate options to some test launchers

2023-01-19 Thread Justin King
On Wed, 18 Jan 2023 20:40:40 GMT, Justin King wrote: > Update some custom launchers to set the default ASan options, without it the > tests fail due to incompatibility with LSan. Additionally adds `-fno-common` > for ASan build, as suggested by the docs. @magicus Yet more build fixes

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v2]

2023-01-19 Thread Justin King
On Thu, 19 Jan 2023 19:23:30 GMT, Erik Joelsson wrote: > Changing the global optimization flags is a pretty big and potentially > intrusive change. It's quite possible that the current flags need a > re-evaluation, since they were chosen a long time ago, for a much older > version of Visual

Re: RFR: JDK-8300531: MSVC CFlags look suspicious [v2]

2023-01-19 Thread Justin King
> Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Justin King has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes b

RFR: JDK-8300592: ASan build does not correctly propagate options to some test launchers

2023-01-18 Thread Justin King
Update some custom launchers to set the default ASan options, without it the tests fail due to incompatibility with LSan. Additionally adds `-fno-common` for ASan build, as suggested by the docs. - Commit messages: - Fix ASan build for custom test launchers Changes:

Re: RFR: JDK-8300531: MSVC CFlags look suspicious

2023-01-18 Thread Justin King
On Wed, 18 Jan 2023 14:32:20 GMT, Justin King wrote: > Update MSVC CFlags to be more consistent with other compilers. Also disables > RTTI in a simliar manner to GCC/Clang for the JVM. Not sure why `-Oy-` was used. GCC/Clang omit frame pointers by default these days, IIRC. So forcin

RFR: JDK-8300531: MSVC CFlags look suspicious

2023-01-18 Thread Justin King
Update MSVC CFlags to be more consistent with other compilers. Also disables RTTI in a simliar manner to GCC/Clang for the JVM. - Commit messages: - Update MSVC CFlags Changes: https://git.openjdk.org/jdk/pull/12073/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12073=00

Integrated: JDK-8300254: ASan build does not correctly propagate ASAN_OPTIONS

2023-01-17 Thread Justin King
On Tue, 17 Jan 2023 13:50:48 GMT, Justin King wrote: > Update ASan build to use the same approach as UBSan for setting default > options. The main difference is that we only want to change the default ASan > options for processes which launch the JVM. We do this by only

Integrated: JDK-8300069: Left shift of negative value in share/adlc/dict2.cpp

2023-01-17 Thread Justin King
On Thu, 12 Jan 2023 18:48:46 GMT, Justin King wrote: > Refactor `hashstr` to use unsigned integrals to avoid undefined behavior. This pull request has now been integrated. Changeset: e139ec3d Author: Justin King Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/com

Re: RFR: JDK-8300254: ASan build does not correctly propagate ASAN_OPTIONS

2023-01-17 Thread Justin King
On Tue, 17 Jan 2023 13:50:48 GMT, Justin King wrote: > Update ASan build to use the same approach as UBSan for setting default > options. The main difference is that we only want to change the default ASan > options for processes which launch the JVM. We do this by only

RFR: JDK-8300254: ASan build does not correctly propagate ASAN_OPTIONS

2023-01-17 Thread Justin King
Update ASan build to use the same approach as UBSan for setting default options. The main difference is that we only want to change the default ASan options for processes which launch the JVM. We do this by only compiling the default options in the common launcher build file. -

Integrated: JDK-8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC

2023-01-12 Thread Justin King
On Thu, 12 Jan 2023 18:30:12 GMT, Justin King wrote: > Fix misconfigured UBSan build by funneling `UBSAN_CFLAGS` and `UBSAN_LDFLAGS` > to ADLC. This pull request has now been integrated. Changeset: 19628e3e Author:Justin King Committer: Magnus Ihse Bursie URL:

Re: RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant

2023-01-12 Thread Justin King
On Thu, 12 Jan 2023 20:28:50 GMT, Justin King wrote: > The implementation of `offset_of` for GCC/Clang only deals with types are > aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the > behavior is undefined. UBSan also suggests that `offset_of` is n

RFR: JDK-8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant

2023-01-12 Thread Justin King
The implementation of `offset_of` for GCC/Clang only deals with types are aligned to 16 bytes or less, if they are more, such as `zCollectedHeap` the behavior is undefined. UBSan also suggests that `offset_of` is not always a compile time constant, as the stack trace came from the dynamic

Re: RFR: JDK-8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC

2023-01-12 Thread Justin King
On Thu, 12 Jan 2023 18:56:38 GMT, Magnus Ihse Bursie wrote: >> Fix misconfigured UBSan build by funneling `UBSAN_CFLAGS` and >> `UBSAN_LDFLAGS` to ADLC. > > make/autoconf/jdk-options.m4 line 480: > >> 478: LDFLAGS_JDKEXE="$LDFLAGS_JDKEXE $UBSAN_LDFLAGS" >> 479: ]) >> 480: if

Re: RFR: JDK-8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC

2023-01-12 Thread Justin King
On Thu, 12 Jan 2023 18:30:12 GMT, Justin King wrote: > Fix misconfigured UBSan build by funneling `UBSAN_CFLAGS` and `UBSAN_LDFLAGS` > to ADLC. @magicus After adding the strict build configuration preprocessor check to the UBSan default options source file, I apparently never attempt to

RFR: JDK-8300068: UBSan CFLAGS/LDFLAGS not passed when building ADLC

2023-01-12 Thread Justin King
Fix misconfigured UBSan build by funneling `UBSAN_CFLAGS` and `UBSAN_LDFLAGS` to ADLC. - Commit messages: - UBSan CFLAGS/LDFLAGS not passed when building ADLC Changes: https://git.openjdk.org/jdk/pull/11975/files Webrev: https://webrevs.openjdk.org/?repo=jdk=11975=00 Issue:

Integrated: JDK-8298448: UndefinedBehaviorSanitizer

2023-01-12 Thread Justin King
On Fri, 9 Dec 2022 06:53:31 GMT, Justin King wrote: > Allow building OpenJDK with UBSan. Currently the build fails when optimizing > the image due to lots of undefined behavior (it invokes the built JVM). > Follow up PRs will either replace the undefined behavior with well defined &

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v11]

2023-01-10 Thread Justin King
On Tue, 10 Jan 2023 21:55:51 GMT, Ioi Lam wrote: >> Justin King has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use macros from when available and update >> justification >> >> Signed-

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v12]

2023-01-10 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v2]

2023-01-10 Thread Justin King
On Tue, 10 Jan 2023 17:05:48 GMT, Ioi Lam wrote: >> I don't believe so, at least not based on current options. Other projects >> use similar tricks, like ABSL_DCHECK from Abseil which short circuits >> expressions when in non-debug builds causing the code to be unreachable and >> stripped. If

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v11]

2023-01-10 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v2]

2023-01-10 Thread Justin King
On Tue, 10 Jan 2023 06:57:01 GMT, David Holmes wrote: >> This doesn't look "too terrible", but I can't comment on the actual >> poisoning strategies. >> >> Cheers. > >> Forcing 2 reviewers to ensure @dholmes-ora can chime in before moving >> forward. > > Well I won't be able to Review as not

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v2]

2023-01-09 Thread Justin King
On Wed, 4 Jan 2023 06:22:11 GMT, David Holmes wrote: >> Justin King has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Exclude more zapping when ASan is in use >> >> Signed-off-by: Justin King

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v6]

2023-01-09 Thread Justin King
On Mon, 9 Jan 2023 08:08:28 GMT, Thomas Stuefe wrote: > Metaspace changes mostly good. Do the gtests pass? Especially the Metaspace > fence tests? You need to execute them via the jtreg wrapper > (test/hotspot/jtreg/gtest) - these wrappers execute the googletest suite with > a number of

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v10]

2023-01-09 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v9]

2023-01-09 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v6]

2023-01-09 Thread Justin King
On Mon, 9 Jan 2023 07:39:03 GMT, Thomas Stuefe wrote: >> Justin King has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use -fno-common as suggested by ASan docs >> >> Signed-off-by: Justin King &g

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v8]

2023-01-09 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v7]

2023-01-09 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v2]

2023-01-09 Thread Justin King
On Mon, 9 Jan 2023 08:05:47 GMT, Thomas Stuefe wrote: >> Ah I see. > > I like this, but would compilers not complain about unused statements? I don't believe so, at least not based on current options. Other projects use similar tricks, like ABSL_DCHECK from Abseil which short circuits

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v6]

2023-01-05 Thread Justin King
On Thu, 5 Jan 2023 16:29:13 GMT, Justin King wrote: >> This change instruments Metaspace for ASan. Metaspace allocates memory using >> `mmap`/`munmap` which ASan is not aware of. Fortunately ASan supports >> applications [manually poisoning/unpoisoning >> memory](h

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v6]

2023-01-05 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v10]

2023-01-05 Thread Justin King
On Sat, 17 Dec 2022 06:39:48 GMT, Justin King wrote: >> Allow building OpenJDK with UBSan. Currently the build fails when optimizing >> the image due to lots of undefined behavior (it invokes the built JVM). >> Follow up PRs will either replace the undefined behavior

Re: RFR: JDK-8298448: UndefinedBehaviorSanitizer [v10]

2023-01-04 Thread Justin King
On Sat, 17 Dec 2022 06:39:48 GMT, Justin King wrote: >> Allow building OpenJDK with UBSan. Currently the build fails when optimizing >> the image due to lots of undefined behavior (it invokes the built JVM). >> Follow up PRs will either replace the undefined behavior

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v3]

2023-01-04 Thread Justin King
On Wed, 4 Jan 2023 17:05:54 GMT, Thomas Stuefe wrote: >> Justin King 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 four addi

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v5]

2023-01-04 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

Re: RFR: JDK-8298908: Instrument Metaspace for ASan [v4]

2023-01-04 Thread Justin King
intenance. > > This also has the added benefit of making > [LSan](https://bugs.openjdk.org/browse/JDK-8298445) more accurate and > deterministic, as LSan will not look for pointers to malloc memory in > poisoned memory regions. > > IMO the benefit of doing this greatly o

  1   2   >