On Mon, 25 Mar 2024 20:10:45 GMT, Bernd wrote:
>> To match the license claim in the code we are using:
>> https://github.com/openjdk/jdk/blob/fb8f2a0a929ebe7f65c69741712b89bbb403ade9/src/hotspot/share/classfile/altHashing.cpp#L32-L43
>
> The header file contains more claims
>
On Sun, 24 Mar 2024 17:24:49 GMT, Bernd wrote:
>> Updated and moved the license file.
>
> src/hotspot/share/legal/siphash.md line 9:
>
>> 7:Copyright (c) 2012-2021 Jean-Philippe Aumasson
>> 8:
>> 9:Copyright (c) 2012-2014 Daniel J. Bernstein
>
> Why would you remove a author or
On Wed, 28 Feb 2024 01:18:50 GMT, Kim Barrett wrote:
> Please review this change that renames some test .h files to .hpp. These
> files contain C++ code and should be named accordingly. Some of them contain
> uses of NULL, which we change to nullptr.
>
> The renamed files
On Thu, 29 Feb 2024 00:16:28 GMT, Kim Barrett wrote:
>> Please review this change that renames some test .h files to .hpp. These
>> files contain C++ code and should be named accordingly. Some of them contain
>> uses of NULL, which we change to nullptr.
>&g
On Wed, 28 Feb 2024 14:15:25 GMT, Coleen Phillimore wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp
>> line 26:
>>
>>> 24: #include
>>> 25: #include
>>> 26: #include
>>
>> Should this be in quotes rather than <> ?
>
> Suggestion:
>
>
On Wed, 28 Feb 2024 14:18:58 GMT, Coleen Phillimore wrote:
>> Kim Barrett has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - add Oracle copyright
>> - fix busted copyright text
>
> test/hotspot/jtreg
On Wed, 28 Feb 2024 04:06:08 GMT, Guoxiong Li wrote:
>> Kim Barrett has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - add Oracle copyright
>> - fix busted copyright text
>
> test/hotspot/jtreg/servi
On Wed, 28 Feb 2024 14:11:49 GMT, Coleen Phillimore wrote:
>> test/hotspot/jtreg/serviceability/jvmti/events/SingleStep/singlestep01/libsinglestep01.cpp
>> line 28:
>>
>>> 26: #include
>>> 27: #include
>>> 28: #include "jvmti_common.hpp"
>>
>> The copyright of this file is wrong.
>>
>>> *
ly,
> likely as part of JDK-8324681.
>
> Thus, the only "interesting" changes are to the renamed files.
>
> Testing: mach5 tier1
Kim Barrett has updated the pull request incrementally with two additional
commits since the last revision:
- add Oracle copyright
- fix busted
On Wed, 28 Feb 2024 06:12:17 GMT, Guoxiong Li wrote:
> So large patch. In order to easy to review, it is good to separate such large
> patch into several patches in the future.
I was doing that in prior related changes (see the subtasks of JDK-8324799).
But reviewers requested I batch up
the
Please review this change that renames some test .h files to .hpp. These
files contain C++ code and should be named accordingly. Some of them contain
uses of NULL, which we change to nullptr.
The renamed files are:
test/hotspot/jtreg/vmTestbase/nsk/share/aod/aod.h
On Mon, 5 Feb 2024 21:39:06 GMT, Magnus Ihse Bursie wrote:
> Here is the full list:
> https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic
I know about that list, and that's not what I was asking for. I want to
understand the impact on *our* code. What warnings are arising from
On Mon, 5 Feb 2024 16:19:59 GMT, Magnus Ihse Bursie wrote:
> Is there anything in this proposed PR that you gentlemen disagree with or
> object to? Or is this fine to push as a step in our ongoing pursuit of
> increasing the code quality, that can (and will) be followed by many more?
Yes. As
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote:
>>> I consider the "format '%p' expects argument of type 'void*" warnings to be
>>> not at all helpful. Fortunately we don't use '%p' in HotSpot,
>>
>> We do use it in hotspot. Not a huge amount as
On Mon, 5 Feb 2024 06:15:08 GMT, David Holmes wrote:
> > I consider the "format '%p' expects argument of type 'void*" warnings to be
> > not at all helpful. Fortunately we don't use '%p' in HotSpot,
>
> We do use it in hotspot. Not a huge amount as we have the legacy format
> specifiers for
> On Feb 5, 2024, at 4:31 AM, Magnus Ihse Bursie wrote:
>
> On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote:
>
>>> Inspired by (the later backed-out)
>>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>>> enable `-Wpedantic`
On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like m
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> #define DEBUG_ONLY(code) code;
>
> DEBUG_ONLY(foo());
> ```
>
> will result in a `; ;`. This breaks the C standard, but is benign, and we use
> it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but
> this is
On Sat, 27 Jan 2024 18:24:45 GMT, Coleen Phillimore wrote:
>> This mechanically replaces NULL with nullptr in hpp/cpp native files in test
>> native code. This didn't attempt to change NULL in comments to say null
>> because nullptr is generally the right thing for the comment to say. It
>>
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch introduces `JitCompiler::isConstantExpression` which can be used
>> to statically determine whether an expression has been constant-folded by
>> the Jit compiler, leading to more constant-folding opportunities. For
On Wed, 10 Jan 2024 22:12:40 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li wrote:
>> Hi all,
>>
>> This patch fixes the building failure introduced by
>> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC
>> version (linux & GCC 7.5.0 locally).
>>
>> Thanks for the review.
>>
>> Best Regards,
>> --
On Tue, 19 Dec 2023 19:08:08 GMT, Kim Barrett wrote:
>>> Have you tested with gcc 9? Or is this just supposition based on gcc9
>>> having removed the experimental
>> status for C++17?
>>
>> I have not tested GCC 8 and 9. @sviswa7 seems to test them.
>>
On Tue, 19 Dec 2023 02:22:05 GMT, Guoxiong Li wrote:
>> Guoxiong Li 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 additional
>> commits
On Sun, 17 Dec 2023 13:25:00 GMT, Guoxiong Li wrote:
>> Hi all,
>>
>> This patch fixes the building failure introduced by
>> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC
>> version (linux & GCC 7.5.0 locally).
>>
>> Thanks for the review.
>>
>> Best Regards,
>> --
On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li wrote:
> Hi all,
>
> This patch fixes the building failure introduced by
> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version
> (linux & GCC 7.5.0 locally).
>
> Thanks for the review.
>
> Best Regards,
> -- Guoxiong
On Mon, 11 Dec 2023 02:36:30 GMT, Guoxiong Li wrote:
> Hi all,
>
> This patch fixes the building failure introduced by
> [JDK-8319577](https://bugs.openjdk.org/browse/JDK-8319577) in old GCC version
> (linux & GCC 7.5.0 locally).
>
> Thanks for the review.
>
> Best Regards,
> -- Guoxiong
On Sat, 27 May 2023 15:33:37 GMT, Kim Barrett wrote:
>> I am basically worried that undefining malloc, even if it seems harmless
>> now, exposes us to difficult-to-investigate problems down the road, since it
>> depends on how the libc devs will reform those macros in t
On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov wrote:
> When using the clang compiler to build OpenJDk on Linux, we encounter various
> "warnings as errors".
> They can be fixed with small changes.
All of the -Wformat-nonliteral changes make me wonder why we're seeing these
with clang but not
On Fri, 26 May 2023 07:48:06 GMT, Daniel Jeliński wrote:
> According to our docs, [clang is a supported compiler for
> Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).
I think that's aspirational rather than actual. Clang has been
On Sat, 27 May 2023 11:50:11 GMT, Thomas Stuefe wrote:
>>> This one is not just to get rid of a warning. We get real test errors
>>> because malloc gets replaced by vec_malloc in log tags.
>>
>> That does not invalidate my argument, nor does it answer my question. Those
>> test errors could
On Thu, 25 May 2023 09:14:14 GMT, JoKern65 wrote:
> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
> on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small
> adjustments.
> A lot of those changes
On Tue, 11 Apr 2023 23:55:50 GMT, Brent Christian wrote:
> With the removal of the AltFinalizer mechanism from `FileInputStream` and
> `FileOutputStream` in
> [JDK-8192939](https://bugs.openjdk.org/browse/JDK-8192939), this portion of
> the Implementation Requirement in the class JavaDoc is
On Sat, 8 Apr 2023 13:24:37 GMT, Julian Waters wrote:
>> C11 has been stable for a long time on all platforms, so native code can use
>> the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the
On Sat, 8 Apr 2023 13:24:37 GMT, Julian Waters wrote:
>> C11 has been stable for a long time on all platforms, so native code can use
>> the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the
> On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov wrote:
>
> On 06/03/2023 13:51, Albert Yang wrote:
>> Upon a cursory inspection of ForceGC.java, it seems that the fundamental
>> logic involves waiting for a certain duration and relying on chance.
>> However, I am of the opinion that utilizing
On Fri, 16 Dec 2022 21:02:21 GMT, Daniel D. Daugherty
wrote:
> A batch a trivial fixes to ProblemList tests:
> [JDK-8298976](https://bugs.openjdk.org/browse/JDK-8298976) ProblemList
> java/util/concurrent/ExecutorService/CloseTest.java on macosx-aarch64
>
On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett wrote:
>> It's to avoid redefining the linkage as static in os_windows.cpp (where it's
>> implemented) after an extern declaration (inside the class), which is
>> forbidden by C++11:
>>
>>> The linkages i
On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters wrote:
>> Sorry my eyes must be playing tricks on me. ??
>>
>> Why did you need to add this here?
>
> It's to avoid redefining the linkage as static in os_windows.cpp (where it's
> implemented) after an extern declaration (inside the class),
On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters wrote:
> Out of curiosity, is there a way to get the discussion on approving the use
> of alignas back up? [...]
A PR to address JDK-8252584 would be welcomed by me. Just do the process for
Style Guide changes (see the Style Guide or previous PRs
On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes wrote:
>> Yep, it was renamed since the file is also named VISCPP, and I felt that
>> matching the names was a good style change
>
> I think it is the file that has the "bad" name in this case. :( But okay.
I also think the macro name should be
On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters wrote:
>> make/hotspot/lib/CompileJvm.gmk line 67:
>>
>>> 65: # Hotspot cannot handle an empty build number
>>> 66: VERSION_BUILD := 0
>>> 67: endif
>>
>> I think the proposed "solution" is *much* worse than this.
>
> Reverted to use the
On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features
On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters wrote:
>> make/autoconf/flags-cflags.m4 line 632:
>>
>>> 630: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" =
>>> xclang; then
>>> 631: STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections
>>> -fdata-sections \
>>>
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features
On Mon, 10 Oct 2022 11:59:55 GMT, Julian Waters wrote:
>> The C99 snprintf is available with Visual Studio 2015 and above, alongside
>> Windows 10 and the UCRT, and is no longer identical to the outdated Windows
>> _snprintf. Since support for the Visual C++ 2017 compiler was removed a
>>
On Sun, 9 Oct 2022 08:17:15 GMT, Julian Waters wrote:
>> The C99 snprintf is available with Visual Studio 2015 and above, alongside
>> Windows 10 and the UCRT, and is no longer identical to the outdated Windows
>> _snprintf. Since support for the Visual C++ 2017 compiler was removed a
>>
On Tue, 5 Jul 2022 18:43:26 GMT, Ryan Ernst wrote:
>> This is a followup to simplify Shutdown.exit after the removal of
>> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement
>> on the approach has been reached in this PR, a CSR will be filed to
>> propose the spec change to
On Thu, 7 Jul 2022 08:03:52 GMT, David Holmes wrote:
> > I think that isn't true. If a hook doesn't terminate then VM.shutdown
> > doesn't get called, so the window never gets cracked opened to call halt
> > directly.
>
> @kimbarrett Any thread can call halt() directly while the attempted
On Mon, 4 Jul 2022 12:09:46 GMT, David Holmes wrote:
>>> Is "deadlock" accurate?
>>
>> Yes.
>>
>> In the context of the specification, "shutdown hook" means _application_
>> shutdown hook - as far as the specification is concerned, application
>> shutdown hooks are the only kind of hooks.
On Mon, 4 Jul 2022 12:19:27 GMT, David Holmes wrote:
> > Let's say we've run shutdown so run all the hooks but not halted. Then
> > someone calls exit(0). That seems to suggest the call will block
> > indefinitely, which is neither desirable nor what was actually implemented.
>
> If the hook
On Sat, 2 Jul 2022 21:21:37 GMT, Ryan Ernst wrote:
>> This is a followup to simplify Shutdown.exit after the removal of
>> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement
>> on the approach has been reached in this PR, a CSR will be filed to
>> propose the spec change to
On Sun, 3 Jul 2022 22:19:50 GMT, David Holmes wrote:
>> Ryan Ernst has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> better clarify multiple threads behavior
>
> src/java.base/share/classes/java/lang/Runtime.java line 89:
>
>> 87: *
54 matches
Mail list logo
