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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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
> 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 th
On Sat, 9 Nov 2024 04:26:55 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 that trigger the
>> un
> 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 th
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:39:08 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 that trigger the
>> un
On Fri, 8 Nov 2024 13:39:08 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 that trigger the
>> un
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.jpackage/windows/native/libjpackage/V
> 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 th
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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.
A `CriticalSection` is a mutex. A RWLock is not a "mutex".
-
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecommen
On Thu, 31 Oct 2024 07:13:56 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
> > Studio versi
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 locals that trigger the
>> u
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 contains two additional
>> commit
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 locals that trigger the
>> u
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
> Studio versions we s
> 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 th
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 locals that trigger the
>> u
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 locals that trigger the
>> u
> 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 th
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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 locals that trigger the
>> u
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
> 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 th
On Thu, 24 Oct 2024 03:33:51 GMT, Julian Waters wrote:
> the way I did it I'd have to force push
That should not be the case. You can just anti-delta changes.
-
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2434475849
On Thu, 24 Oct 2024 03:31:31 GMT, Julian Waters wrote:
>> I'm not sure what you mean by "that one". It's the static one that should be
>> removed. The local variables always hide the static, and there seems to be
>> no reason for the value of memHandle to survive outside of the local scope
>>
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 that trigger the
> unuse
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 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 that trigger the
> unuse
On Wed, 23 Oct 2024 05:22:45 GMT, Julian Waters wrote:
>> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:
>>
>>> 45: {
>>> 46: void *mappedMemory;
>>> 47: // HANDLE memHandle;
>>
>> Why comment out this one but not the one at line 88? It seems they are both
>> equally problemat
On Wed, 23 Oct 2024 05:23:39 GMT, Julian Waters wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:
>>
>>> 51: #ifndef _WIN32
>>> 52: static MUTEX_T my_mutex = MUTEX_INIT;
>>> 53: #endif
>>
>> The reason for no reference on windows is because of the following on
>> window
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 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 that trigger the
> unuse
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:43:50 GMT, Julian Waters wrote:
> Aren't the dt_shmem and jdwp changes related to HotSpot?
Nope. That's core-svc - the non-hotspot side of serviceability. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428793636
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters 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 particular
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
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 that trigger the
> unuse
53 matches
Mail list logo
