> 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 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 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 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 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 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 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:
> 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
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 that trigger the
> unuse
18 matches
Mail list logo
