On Tue, 8 Jul 2025 01:49:14 GMT, David Holmes wrote:
>> Sorry for waiting so long. It's become clear that I won't be able to get awt
>> and accessibility up to speed for a long time, so I will go ahead with this
>> one first
>
> @TheShermanTanker the commented out code really should have been d
On Tue, 8 Jul 2025 04:20:32 GMT, Jaikiran Pai wrote:
> > Since your change was applied there have been 3762 commits pushed to the
> > master branch
>
> It's usually risky to be integrating a PR which is so far behind the master
> branch, without first merging the latest changes and running the
On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Thu, 29 May 2025 18:52:51 GMT, Mohamed Issa wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp line 49:
>>
>>> 47:
>>> /**/
>>> 48:
>>> 49: ATTRIBUTE_ALIGNED(4) static const juint _SIG_MASK[] =
>>
>> ATTRI
On Wed, 28 May 2025 18:39:13 GMT, Mohamed Issa wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are
>> included to check the performance of specific input value ranges to help
>> prevent regression
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote:
> kludge_c++11.h was introduced to work around older C++ versions not having
> access to C++ utilities like std::unique_ptr. Since we are already on C++14
> (And hopefully will get C++17 soon) this workaround can be rem
On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote:
> kludge_c++11.h was introduced to work around older C++ versions not having
> access to C++ utilities like std::unique_ptr. Since we are already on C++14
> (And hopefully will get C++17 soon) this workaround can be rem
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 5 May 2025 22:23:04 GMT, Alexander Matveev wrote:
>> kludge_c++11.h was introduced to work around older C++ versions not having
>> access to C++ utilities like std::unique_ptr. Since we are already on C++14
>> (And hopefully will get C++17 soon) this workaround can be removed from
>> j
On Fri, 25 Apr 2025 06:14:36 GMT, Julian Waters wrote:
> kludge_c++11.h was introduced to work around older C++ versions not having
> access to C++ utilities like std::unique_ptr. Since we are already on C++14
> (And hopefully will get C++17 soon) this workaround can be rem
kludge_c++11.h was introduced to work around older C++ versions not having
access to C++ utilities like std::unique_ptr. Since we are already on C++14
(And hopefully will get C++17 soon) this workaround can be removed from
jpackage code.
-
Commit messages:
- Include memory header
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 10 Apr 2025 08:03:58 GMT, Matthias Baesken wrote:
> JLI_ReportErrorMessageSys is not used any more on Windows, so we can remove
> it and make it UNIX-only (there a still a few remaining usages).
I was hoping to get around to using it on Windows, but oh well. I think the
remaining usage
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Wed, 2 Apr 2025 02:00:39 GMT, David Holmes wrote:
> > there was already a pragma but due to incorrect restrictions it did not
> > apply to clang.
>
> How does the `__GNUC__` check affect clang?? Isn't that just for gcc?
clang has a tendency to like to pretend to be other compilers, it defin
On Tue, 1 Apr 2025 12:07:09 GMT, SendaoYan wrote:
>> Hi all,
>> File src/java.base/share/native/libjli/java.c compile error: control reaches
>> end of non-void function [-Werror=return-type] with gcc options
>> -fsanitize=address -O0. The function int JavaMain(void* _args) in this file
>> will
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Tue, 11 Feb 2025 06:32:56 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection
t; practically unusable when `-XX:+EnableX86ECoreOpts` are set (65k+ lines of
>> warnings)
>
> Volodymyr Paprotski has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update src/hotspot/cpu/x86/macroAssembler_x86.cpp
>
&g
On Tue, 11 Feb 2025 21:47:31 GMT, Volodymyr Paprotski
wrote:
>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>>
>> This PR fixes two issues:
>> - the original issue is a crash caused by `__ warn` corrupting the stack on
>> Windows only
>> - This issue also uncovered that -Xcheck:
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Sat, 11 Jan 2025 07:10:53 GMT, He-Pin(kerr) wrote:
> Motivation:
> When a user passes a wrong parameter, the current implementation throws an
> IllegalArgumentException with an error message `null`, which is not helpful.
>
> Modification:
> Add detail error messages.
>
> Result:
> Helpful m
On Wed, 22 Jan 2025 21:59:40 GMT, Magnus Ihse Bursie wrote:
> GatherProcessInfoTimeoutHandler calls System.loadLibrary, which will trigger
> a `restricted` warning when building with JDK 24 or newer, and failing the
> build.
>
> This should be fixed by adding a @SuppressWarnings("restricted").
On Wed, 15 Jan 2025 16:13:04 GMT, Magnus Ihse Bursie wrote:
>> The idea.sh script which creates a configuration for IDEA does at some point
>> call a makefile, to extract information from the build system. However, this
>> is done in an ad-hoc manner that does not fit properly in the build syst
On Wed, 15 Jan 2025 16:26:26 GMT, Maurizio Cimadamore
wrote:
> We should probably also ask somebody with Windows
Hey, don't forget about me! How do I test this, just set up an IDEA Workspace
as instructed in the docs?
-
PR Comment: https://git.openjdk.org/jdk/pull/23140#issuecomm
On Tue, 14 Jan 2025 06:39:22 GMT, Alan Bateman wrote:
> > There's a contributor PR from the java bugs submitter at #23050, I wonder
> > what we should do in this case.
>
> The PR has the "oca" label so we can't look or comment on it.
:O People from Oracle aren't allowed to look at work from un
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 23 Dec 2024 08:18:40 GMT, Thomas Stuefe wrote:
>> src/java.desktop/share/native/common/awt/debug/debug_trace.h line 66:
>>
>>> 64: /* each file includes this flag indicating module trace status */
>>> 65: #ifdef __cplusplus
>>> 66: [[maybe_unused]]
>>
>> I don't really know what to do a
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Thu, 19 Dec 2024 16:27:30 GMT, Magnus Ihse Bursie wrote:
> We need to raise the abstraction of the SetupBuildLauncher API, to prepare
> for static launchers. We should specify the desired outcome, not what flags
> we should add. This can be seen as the last part of
> [JDK-8141444](https://b
On Wed, 18 Dec 2024 04:39:49 GMT, David Holmes wrote:
>> A simple fix for removing an unused variable in fallbacklinker.cpp. This is
>> needed for building zero jvm variant on macosx-x64.
>>
>> Testing:
>>
>> - [x] tier1
>> - [x] zero jvm variant build on macosx-x64
>
> src/java.base/share/nat
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 11 Dec 2024 20:55:41 GMT, Magnus Ihse Bursie wrote:
>> @magicus Sorry for the ping, but I'm a bit confused. Do you know what bug
>> report site Phil is referring to when he says to submit a bug to AWT
>> instead? Is it just the JBS? (There's a little bit of a problem if it is, it
>> is
On Fri, 25 Oct 2024 10:11:57 GMT, Magnus Ihse Bursie wrote:
>> It's a checkout error from the original gigantic Pull Request, sorry. I
>> don't plan to raise the JDK to C++17 in this one. But I'm not sure what to
>> do with this now, since maybe_unused is C++17. I don't think anyone is going
>
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
On Fri, 8 Nov 2024 13:10:48 GMT, Alexey Semenyuk wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove global memHandle, would've liked to keep it as a comment :(
>
> src/jdk.
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last r
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote:
> Can someone confirm that use of `__stdcall` has no affect on name
> decorations, as there is no mention here about anything being ignored:
>
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>
> I would h
On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev wrote:
>> src/hotspot/os/windows/os_windows.cpp line 510:
>>
>>> 508: // Thread start routine for all newly created threads.
>>> 509: // Called with the associated Thread* as the argument.
>>> 510: static unsigned thread_native_entry(void* t) {
>
On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote:
> I think you may be throwing the baby out with the bath water when it comes to
> `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> anything that states `__stdcall` is ONLY for 32-bit!
To my knowledge the only thing __
On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 30 Oct 2024 06:27:22 GMT, Chris Plummer wrote:
>> Julian Waters 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 conta
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Sat, 26 Oct 2024 04:35:09 GMT, Julian Waters wrote:
> I do wonder if mutex support can be implemented for Windows with
> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
> would be nice to have. Shame threads.h is not available with some Visual
> S
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last r
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the las
On Wed, 30 Oct 2024 11:19:03 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/share/adlc/main.cpp line 494:
>>
>>> 492: }
>>> 493:
>>> 494: #if !defined(_WIN32) || defined(_WIN64)
>>
>> Removing the conditionalization is fine for this change. But see also
>> https://bugs.openjdk.org/browse/JDK-
On Wed, 30 Oct 2024 05:51:30 GMT, David Holmes wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> un
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 23 Oct 2024 04:40:50 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 29 Oct 2024 14:37:43 GMT, Aleksey Shipilev wrote:
>> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if
>> support is really as simple as a single pause instruction. Should I help
>> implement this separately (After this PR is integrated, to avoid conflicts)?
>
On Tue, 29 Oct 2024 14:44:03 GMT, Magnus Ihse Bursie wrote:
>> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a
>> bug, this file, which is meant for Windows/x64, is used by Windows/ARM64
>> instead. The consequences of this are unknown
>
> What bug are you referring
On Mon, 28 Oct 2024 19:25:09 GMT, Aleksey Shipilev wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> T
On Tue, 29 Oct 2024 06:59:22 GMT, Julian Waters wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build suppor
On Tue, 29 Oct 2024 09:32:21 GMT, David Holmes wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> This
On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 25 Oct 2024 10:11:57 GMT, Magnus Ihse Bursie wrote:
>> It's a checkout error from the original gigantic Pull Request, sorry. I
>> don't plan to raise the JDK to C++17 in this one. But I'm not sure what to
>> do with this now, since maybe_unused is C++17. I don't think anyone is going
>
On Thu, 24 Oct 2024 07:11:16 GMT, David Holmes wrote:
> > the way I did it I'd have to force push
>
> That should not be the case. You can just anti-delta changes.
I did it in a really inefficient way, by checking out all files except for the
files that I wanted to stay. I could not figure out
On Thu, 24 Oct 2024 22:07:52 GMT, Magnus Ihse Bursie wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has refreshed the contents of this pull request, and previous
commits have been remov
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Wed, 23 Oct 2024 16:51:23 GMT, Chris Plummer wrote:
>> I wasn't sure whether the global memHandle not being used was a bug, so I
>> commented out the local one. I missed the line 88 one because it wasn't
>> flagged. If it really isn't needed I'll remove that one instead
>
> I'm not sure what
On Tue, 22 Oct 2024 18:03:12 GMT, Chris Plummer wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Tue, 22 Oct 2024 09:40:35 GMT, David Holmes wrote:
> > Aren't the dt_shmem and jdwp changes related to HotSpot?
>
> Nope. That's core-svc - the non-hotspot side of serviceability. :)
Oh, well I guess you learn something new everyday :)
-
PR Comment: https://git.openjdk.org/jdk/
On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes wrote:
> > and whatever team is responsible for HotSpot debugging.
>
> I don't see anything hotspot related here.
>
> I think you would be better off splitting this up into distinct issues and
> PRs for different areas. I expect the client team in
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote:
>> There is some old awt/2d coding where warnings occur when running with ubsan
>> enabled binaries.
>> However at most of these locations the coding should work (at least on our
>> supported platform set) so the warnings can be disabled
On Wed, 9 Oct 2024 06:25:07 GMT, Matthias Baesken wrote:
>> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:
>>
>>> 391:
>>> 392: hcreate_r(htab_sz, symtab->hash_table);
>>> 393: // guarantee(rslt, "unexpected failure: hcreate_r");
>>
>> The commented out guarantee l
On Fri, 27 Sep 2024 06:46:24 GMT, Matthias Baesken wrote:
> And it was reviewed by erikj and ihse, I think those are members of the
> OpenJDK build group
Erik and Magnus are indeed part of the build team. Erik is the Skara tool lead
but does build work as well, while Magnus is pretty much the
On Thu, 26 Sep 2024 11:51:19 GMT, Matthias Baesken wrote:
> > jni_md.h seems like a pretty big sledgehammer for something that seems to
> > only be in one file, for just java.desktop. Is this macro planned to be
> > used outside of java.desktop?
>
> Yes I have a couple (currently 2) more I wou
On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken wrote:
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be disabled at
On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken wrote:
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be disabled at
On Thu, 26 Sep 2024 05:03:01 GMT, Joe Darcy wrote:
>> Add citation of the second edition of "Hacker's Delight".
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
Interesting Pull Request for sure :)
1 - 100 of 424 matches
Mail list logo
