On Fri, 20 May 2022 14:54:39 GMT, Christian Hagedorn
wrote:
> Thanks Thomas for doing the testing!
Hi Christian,
I can see no problems on ppcle attributable to your test. However, I may
overlook something since tests are still failing all over the place because of
loom.
I see test errors in
On Sat, 2 Apr 2022 05:54:16 GMT, Thomas Stuefe wrote:
>> Christian Hagedorn has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 58 commits:
>>
>> - Apply remaining review comments from Thomas Stuefe
>>
On Thu, 28 Apr 2022 10:24:37 GMT, Matthias Baesken wrote:
> Currently , in target "product-bundles" , the Alpine Linux build fails when
> BusyBox tar is used.
> Error is :
Looks good.
I confirmed that the build works now in my Alpine container. Thanks for fixing!
-
Marked as revi
On Tue, 19 Apr 2022 08:47:18 GMT, Feilong Jiang wrote:
>> This patch adds Zero support for the 32-bit RISC-V architecture.
>>
>> Additional tests:
>>
>> - [x] Linux zero RISCV32 cross-compilation
>> - [x] Resulting binaries run on QEMU User mode without problems
>
> Feilong Jiang has updated th
On Mon, 11 Apr 2022 16:17:08 GMT, Andrew Leonard wrote:
>> Andrew Leonard has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8284661: Reproducible assembly builds without relative linking
>>
>> Signed-off-by: Andrew Leonard
>
> @magic
On Mon, 11 Apr 2022 14:50:37 GMT, Andrew Leonard wrote:
>> Non-determinism in .debuginfo straight away makes .so libraries
>> non-deterministic due to the embedded debuginfo CRC value.
>> @erikj79 i'll try removing .debuginfo from the exceptions and try it...
>
>> @andrew-m-leonard This change l
On Mon, 28 Feb 2022 16:22:25 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x000
On Mon, 28 Feb 2022 16:22:25 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x000
On Mon, 28 Mar 2022 22:25:01 GMT, David Holmes wrote:
>> src/hotspot/share/utilities/elfFile.cpp line 450:
>>
>>> 448: if (buf == nullptr) {
>>> 449: return false;
>>> 450: }
>>
>> I'd move this close to and local to where it is used.
>>
>> Also, you seem to repeat the same pattern a l
On Mon, 28 Mar 2022 12:20:44 GMT, Thomas Stuefe wrote:
>> Christian Hagedorn has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 54 commits:
>>
>> - Updating some comments
>> - Cleanup load
On Thu, 24 Feb 2022 08:14:34 GMT, Thomas Stuefe wrote:
>> Christian Hagedorn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make dwarf tag NOT_PRODUCT
>
> src/hotspot/share/utilities/decoder_elf.cp
On Mon, 28 Feb 2022 16:22:25 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x000
On Tue, 8 Feb 2022 08:17:17 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x
On Mon, 28 Mar 2022 06:46:30 GMT, Christian Hagedorn
wrote:
> Ping - may I get another review for this change?
I'll take a look later today or tomorrow. This is nice stuff, I'm looking
forward to having it upstream.
-
PR: https://git.openjdk.java.net/jdk/pull/7126
On Fri, 18 Mar 2022 08:03:11 GMT, Ichiroh Takiguchi
wrote:
>> This change is just for AIX platform with IBM XL C/C++ 16.1.
>> By this change, lib's entry points are reduced by compilation and linkage
>> option changes.
>>
>> Without changes:
>>
>> $ dump -X32_64 -Tv lib/libawt.so | grep EXP |
On Fri, 18 Mar 2022 08:07:53 GMT, Thomas Stuefe wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove unexpected comment
>
> So, does this mean we cannot build with ol
On Fri, 18 Mar 2022 08:03:11 GMT, Ichiroh Takiguchi
wrote:
>> This change is just for AIX platform with IBM XL C/C++ 16.1.
>> By this change, lib's entry points are reduced by compilation and linkage
>> option changes.
>>
>> Without changes:
>>
>> $ dump -X32_64 -Tv lib/libawt.so | grep EXP |
On Fri, 11 Mar 2022 08:28:32 GMT, Ioi Lam wrote:
>> Is reproducibility also a topic for users calling -Xdump with custom JNI
>> coding? Or maybe having the VM instrumented somehow? Since it seems such an
>> easy fix, I would prevent attaching too. At least the user would get a clear
>> error m
On Fri, 11 Mar 2022 07:03:00 GMT, David Holmes wrote:
> > Well, he does it for `DumpSharedSpaces` only. Are you really worried about
> > that one load+conditional jump?
>
> As I said (and I'm not the only one who says this :) ) "death by a thousand
> cuts".
Thank you, that is a good expressio
On Thu, 10 Mar 2022 19:34:29 GMT, Ioi Lam wrote:
>> src/hotspot/share/prims/jvm.cpp line 2887:
>>
>>> 2885: return;
>>> 2886: }
>>> 2887: #endif
>>
>> Should we do this for jni_AttachCurrentThread too?
>
> This hasn't been necessary for me because jni_AttachCurrentThread is not
> called
On Fri, 11 Mar 2022 06:50:00 GMT, David Holmes wrote:
> I can combine the tests for `MemTracker::tracking_level()` and
> `DumpSharedSpaces` into a single test and do more work only when the uncommon
> path is taken. This would require some refactoring of the
> MemTracker/MallocTracker code. I'
On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote:
> > Thanks for pointing this out. I ran more tests and found that on certain
> > platforms, there are other structures that have problems with uninitialized
> > gaps. I ended up changing `os::malloc()` to zero the buffer when running
> > wi
On Wed, 9 Mar 2022 07:58:51 GMT, Thomas Stuefe wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixed zero build
>
> Hi Ioi,
>
> some questions, comments inline.
>
> Like Da
On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote:
>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry h
On Wed, 2 Mar 2022 08:33:58 GMT, TheShermanTanker wrote:
> > > This also removes support for the legacy cross compilation flags as well.
> >
> >
> > Hi,
> > without reading through building.md and your patch, which legacy flags are
> > would be removed by this?
> > Thanks, Thomas
>
> Specific
On Wed, 2 Mar 2022 08:11:51 GMT, TheShermanTanker wrote:
>This also removes support for the legacy cross compilation flags as well.
Hi,
without reading through building.md and your patch, which legacy flags are
would be removed by this?
Thanks, Thomas
Oh, and please describe whatever you do
On Mon, 14 Feb 2022 23:44:40 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK π
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Mon, 14 Feb 2022 10:32:11 GMT, Magnus Ihse Bursie wrote:
>> Tyler Steele has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - Merge branch 'master' into JDK-8203290
>> - Adds Oracle & IBM copyrights as per gui
On Fri, 11 Feb 2022 23:56:19 GMT, Tyler Steele wrote:
> > Be warned: This may take time. You certainly want your change to get
> > integrated at some point of time.
>
> I think this has turned out to be sage advice from Martin, as I believe
> neither of us has received a reply from the Oracle
On Thu, 3 Feb 2022 11:22:02 GMT, Thomas Stuefe wrote:
>> Looks good to me, too. I think it is ready for integration assuming all
>> change requests were taken care of and tests have passed.
>
>> Looks good to me, too. I think it is ready for integration assuming all
&g
On Thu, 3 Feb 2022 11:14:19 GMT, Martin Doerr wrote:
> Looks good to me, too. I think it is ready for integration assuming all
> change requests were taken care of and tests have passed.
@TheRealMDoerr we should test the latest version of this patch in our
nightlies, just in case
On Tue, 1 Feb 2022 21:36:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK π
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Mon, 31 Jan 2022 22:12:30 GMT, David Holmes wrote:
> > That's a valid concern. I've also asked myself this question when I had
> > initially started using some assertions. We should not crash again during
> > error reporting. I've therefore tried to be as conservative as possible and
> > ad
On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett wrote:
> Please review this change to the HotSpot Style Guide change process.
>
> The current process involves gathering consensus among the HotSpot Group
> Members. That's fine for changes of substance. But it seems overly weighty
> for editorial
On Fri, 28 Jan 2022 15:07:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK π
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Fri, 28 Jan 2022 15:07:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK π
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Fri, 28 Jan 2022 09:19:04 GMT, Christian Hagedorn
wrote:
> > Two general remarks. One concern I have is that the new functionality
> > should be super stable, since nothing is more annoying than to crash during
> > stack dumping in hs-err file; I much rather have a call stack without bells
On Thu, 27 Jan 2022 19:28:01 GMT, Tyler Steele wrote:
>
> This is a good suggestion. I thought about doing it before, but I am used to
> tamping down my functional programming instincts when writing C.
You are right, it's generally good to do things the way they are done. When in
Rome. But in
On Thu, 27 Jan 2022 00:17:17 GMT, Tyler Steele wrote:
>> src/hotspot/os/aix/os_perf_aix.cpp line 33:
>>
>>> 31: #include "runtime/os_perf.hpp"
>>> 32: #include "runtime/vm_version.hpp"
>>> 33: #include "utilities/globalDefinitions.hpp"
>>
>> include debug.hpp too (you use assert)
>
> Thanks! I
On Tue, 25 Jan 2022 15:10:11 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x000
On Tue, 25 Jan 2022 10:57:14 GMT, Thomas Stuefe wrote:
> After discussing this on hotspot-runtime-dev [1], the general opinion seems
> to be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT
> unconditional. This affects minimal builds only. As pointed out in
On Wed, 26 Jan 2022 08:26:27 GMT, Aleksey Shipilev wrote:
>> Thomas Stuefe has updated the pull request incrementally with 15 additional
>> commits since the last revision:
>>
>> - 8280377: MethodHandleProxies does not correctly invoke default methods
>> with v
On Wed, 26 Jan 2022 08:42:46 GMT, Aleksey Shipilev wrote:
> This looks fine to me.
Thanks, Aleksey!
-
PR: https://git.openjdk.java.net/jdk/pull/7213
On Wed, 26 Jan 2022 08:26:27 GMT, Aleksey Shipilev wrote:
> There is some major weirdness in this PR: it includes a lot of unrelated
> changes. Consider rebasing to current master and force-pushing?
Done.
I wondered about that, I did merge master - normally, this shows up as a single
merge ch
t rid of one configuration
> to build and test.
>
> [1]
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
>
> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well
> as the associated build option.
Thomas Stuefe
t rid of one configuration
> to build and test.
>
> [1]
> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-January/053504.html
>
> Patch removes INCLUDE_NMT from hotspot, as well as dependent macros, as well
> as the associated build option.
Thomas St
After discussing this on hotspot-runtime-dev [1], the general opinion seems to
be that it would be worthwhile to get rid of INCLUDE_NMT and make NMT
unconditional. This affects minimal builds only. As pointed out in the mail
thread, the overhead is very small and it would get rid of one configur
On Tue, 25 Jan 2022 17:22:54 GMT, Yumin Qi wrote:
>> I'm curious, under what circumstances would, before
>> https://bugs.openjdk.java.net/browse/JDK-8237750, we ever hit the
>> LoadLibrary in imageDecompressor.cpp? Did this ever work? Was there ever a
>> scenario where the JVM was not involved
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing
> copy. The user case failed to load zip.dll, since zip.dll is not set in PATH.
> This failure is after we get NULL from GetModuleHandle("zip.dll"),
On Mon, 24 Jan 2022 22:23:33 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK π
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Wed, 12 Jan 2022 15:18:46 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK π
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Thu, 11 Nov 2021 14:32:18 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source code in src/utils. This scripts
> verifies that modifiers are in the "blessed" order, and fixes it otherwise. I
> have manually checked the changes made by the script to make sure they ar
On Tue, 9 Nov 2021 20:47:29 GMT, Anirvan Sarkar wrote:
> Use version `3.2.0` of `cygwin` instead of latest version `3.3.2` on GitHub
> Actions.
> `make` SEGVs on the latest version.
>
> Version number format obtained from
> https://cygwin.com/packages/summary/cygwin.html
> The patch looks oka
On Thu, 23 Sep 2021 09:19:42 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request increm
On Thu, 6 May 2021 16:38:52 GMT, Phil Race wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> switch off warning in build instead of fixing it
>
> The policy is to do what you end
On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote:
> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS
> issue.
>
> I fixed the issue in the harfbuzz sources, but I am not sure of the policy
> here. Do we modify the harfbuzz sources or leave them un
On Thu, 6 May 2021 07:53:52 GMT, Richard Reingruber wrote:
> Looks good to me, thanks!
> Personally I'm building with gcc 9. I've test your fix successfully with gcc
> 7.5.
>
> Cheers, Richard.
Thanks Richard! I tested the build on Debian with gcc 7 and gcc 9, it worked.
Since I now have enou
On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote:
> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS
> issue.
>
> I fixed the issue in the harfbuzz sources, but I am not sure of the policy
> here. Do we modify the harfbuzz sources or leave them un
On Thu, 6 May 2021 06:16:36 GMT, Aleksey Shipilev wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> switch off warning in build instead of fixing it
>
> FWIW, current jdk master builds
ixes linux x64 fastdebug and opt build for me.
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
switch off warning in build instead of fixing it
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/3
On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote:
> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS
> issue.
>
> I fixed the issue in the harfbuzz sources, but I am not sure of the policy
> here. Do we modify the harfbuzz sources or leave them un
On Wed, 5 May 2021 07:54:20 GMT, Thomas Stuefe wrote:
> Harfbuzz upgrade broke Linux x64 build on older gccs. For details see JBS
> issue.
>
> I fixed the issue in the harfbuzz sources, but I am not sure of the policy
> here. Do we modify the harfbuzz sources or leave them un
On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote:
> Upgrade to harfbuzz 2.8
https://github.com/openjdk/jdk/pull/3873
-
PR: https://git.openjdk.java.net/jdk/pull/3826
On Fri, 30 Apr 2021 20:07:53 GMT, Phil Race wrote:
> Upgrade to harfbuzz 2.8
Same here. In my case it breaks with gcc 7.5.0, which I believe is still
supported.
I opened https://bugs.openjdk.java.net/browse/JDK-8266545.
-
PR: https://git.openjdk.java.net/jdk/pull/3826
On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote:
> The number of CDS source files have grown significantly. To improve
> modularity, the following files should be moved a new directory,
> src/hotspot/share/cds.
>
> - src/hotspot/share/classfile/classListParser.cpp
> - src/hotspot/share/classfi
On Wed, 10 Mar 2021 18:44:18 GMT, Thomas Stuefe wrote:
>> Yumin Qi has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains seven commits:
>>
>> - Merge branch 'master' into jdk-8236847
>> - Me
On Wed, 10 Mar 2021 17:41:25 GMT, Yumin Qi wrote:
>> Hi, Please review
>> Usually most OSes are configured with page size of 4K, but some others are
>> configured with 64K. If jdk binary is built on 4K platform and run on
>> different configured platforms, CDS fails to be loaded due to region
On Mon, 8 Mar 2021 00:56:24 GMT, Yasumasa Suenaga wrote:
>> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
>>
>> AccessBridgeDebug.cpp
>> γ‘γ’: γ€γ³γ―γ«γΌγ γγ‘γ€γ«:
>> d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
>>
>> :
>>
>> c:\progra~
On Sun, 7 Mar 2021 22:00:41 GMT, Sergey Bylokhov wrote:
> > I wondered why C++ std headers are even used. The source code looks C-ish;
> > but "8196681: Java Access Bridge logging and debug flags dynamically
> > controlled" added some coding, adding a bunch of C++11x semantics and
> > included
On Sun, 7 Mar 2021 16:19:15 GMT, Phil Race wrote:
>> I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):
>>
>> AccessBridgeDebug.cpp
>> γ‘γ’: γ€γ³γ―γ«γΌγ γγ‘γ€γ«:
>> d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h
>>
>> :
>>
>> c:\progra~2\micro
On Fri, 22 Jan 2021 16:17:57 GMT, Harold Seigel wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the always true os::supports_monotonic_clock()
>
> Hi David,
> The changes look good. Just a couple of nits.
>
On Thu, 21 Jan 2021 15:26:43 GMT, Gerard Ziemski wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the always true os::supports_monotonic_clock()
>
> Marked as reviewed by gziemski (Committer).
Builds fine on
On Mon, 18 Jan 2021 11:25:32 GMT, Tobias Hartmann wrote:
> Otherwise, looks good to me.
Thanks Tobias. I added your suggestion.
Cheers, Thoams
-
PR: https://git.openjdk.java.net/jdk/pull/2063
gt;
> Note that (3) is not only simpler, but also more efficient: many of the
> PrintInliningBuffer objects are inserted into the middle of the
> _print_inlining_list; GrowableArray does shift all higher items up to provide
> space for the new item. If those items are simple po
On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe wrote:
> Hi,
>
> May I have reviews please for the following patch.
>
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler
> may be invoked instead of our error handler, and we just see a
>
On Tue, 15 Dec 2020 08:20:54 GMT, Magnus Ihse Bursie wrote:
> Build changes look good.
>
> I left a note on the hotspot code; feel free to ignore it if you want. :)
>
> I agree with your assessment that restoring gtest to the code base would make
> life simpler. I'm not sure what needs to be d
On Tue, 15 Dec 2020 08:16:51 GMT, Magnus Ihse Bursie wrote:
>> Hi,
>>
>> May I have reviews please for the following patch.
>>
>> At the moment, if a crash happens on Windows in gtests, the gtest SEH
>> handler may be invoked instead of our error handler, and we just see a
>> one-line-warning
On Mon, 14 Dec 2020 04:52:02 GMT, David Holmes wrote:
> Hi Thomas,
> Not an expert but this all seems quite reasonable to me.
> Thanks,
> David
Thanks David!
-
PR: https://git.openjdk.java.net/jdk/pull/1757
Hi,
May I have reviews please for the following patch.
At the moment, if a crash happens on Windows in gtests, the gtest SEH handler
may be invoked instead of our error handler, and we just see a one-line-warning
"SEH happened blabala". No hs-err file.
Even worse, if a crash happens inside the
On Sat, 5 Dec 2020 15:23:38 GMT, Thomas Stuefe wrote:
>> Thumbs up on the jsig.c change. No comment on the Lib.gmk change.
>
> Hi David,
>
> I am fine with this, but since this is possibly a breaking change would this
> not need a release note?
>
> ..Thomas
>
On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty wrote:
>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago
>> and supported three different Linux signal API's: sigset, signal and
>> sigaction:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal
Hi all,
may I please have opinions and reviews on this cleanup-fix-patch for the
hotspot signal handlers.
Its main intent is to simplify coding and to commonize some of it across all
Posix platforms where possible. Also to fix a number of smaller issues.
This will have a number of benefits, ma
82 matches
Mail list logo
