On Tue, 23 Aug 2022 21:31:24 GMT, Tyler Steele wrote:
> Adds Classpath exception to assemblyprefix.h. Affects copyright header only.
LGTM
-
Marked as reviewed by stuefe (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9990
On Tue, 23 Aug 2022 16:57:20 GMT, Ioi Lam wrote:
> > Stupid question, does that not mean that the CDS dump generated at build
> > time is not usable with the VM at runtime if that is started with default
> > options?
>
> The CDS archive is still useable.
>
> * If G1 is used at runtime, the sh
On Tue, 23 Aug 2022 15:56:35 GMT, Ioi Lam wrote:
> ZERO uses UseSerialGC by default. When we dump the default CDS archive during
> the build process, it fails to dump the shared heap (which requires G1GC).
>
> The fix is to force -XX:+UseG1GC when dumping the default CDS archive during
> the b
On Thu, 18 Aug 2022 15:46:04 GMT, Julian Waters wrote:
> Initially I did intend to do that, but a raw GetLastError wouldn't exactly be
> very helpful when a failure does occur
I disagree. Error codes are well documented, unlike posix errno with defined
numerical values, and often more helpful
On Thu, 18 Aug 2022 15:11:22 GMT, Harold Seigel wrote:
>> Please review this small change to add a test that option -XX:+CheckJNICalls
>> shows changed signal handlers. This new test is a copy of the recently
>> deleted TestPosixSig.java with small changes. This version of the test only
>> c
On Thu, 18 Aug 2022 11:23:00 GMT, Julian Waters wrote:
> I don't quite get what you mean?
The only thing JLI_ReportErrorMessageSys has above JLI_ReportErrorMessage is
that it prints the error code for you, and that is a very slim win. It turns
into a loss quickly if it does that one thing wron
On Thu, 18 Aug 2022 12:48:30 GMT, Harold Seigel wrote:
> Please review this small change to add a test that option -XX:+CheckJNICalls
> shows changed signal handlers. This new test is a copy of the recently
> deleted TestPosixSig.java with small changes. This version of the test only
> check
On Thu, 18 Aug 2022 09:46:56 GMT, Julian Waters wrote:
>> Let's back up a bit.
>>
>> I looked again, and think @dholmes-ora was originally right when he wrote
>> that this coding does not get called on Windows. Not sure why I thought
>> differently, but I cannot find a single callsite on windo
On Thu, 18 Aug 2022 08:10:34 GMT, Julian Waters wrote:
>> src/java.base/windows/native/libjli/java_md.c line 621:
>>
>>> 619: char *errtext = NULL;
>>> 620:
>>> 621: char* const conflict = "Java detected conflicting Windows and C
>>> Runtime errors and is unable to provide an accurate
On Thu, 18 Aug 2022 08:23:22 GMT, Julian Waters wrote:
>> Second attempt at resolving
>> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
>> intrusive approach this time
>>
>> Side note: While it might be preferred to remove this entirely, other areas
>> of the JDK also
On Wed, 17 Aug 2022 11:05:50 GMT, Aleksey Shipilev wrote:
> > I'm confused. How does adding EnsureCapacity in newString646_US fix the
> > compiler warning mentioned in JBS?
>
> I think this is a bona-fide compiler static analyzer bug. GCC 12 compiles
> this code fine. So, we have two options:
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Tue, 16 Aug 2022 08:07:52 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, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev wrote:
> The affected file was added by
> [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that
> fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled
> for tests. Looks like we really need the
On Mon, 15 Aug 2022 18:38:51 GMT, Ioi Lam wrote:
> Do you know how much testing is done by the community with zero? We don't
> test it that much in our pipeline.
You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms
with broad platform support and use a lot of zero.
---
On Mon, 15 Aug 2022 14:26:38 GMT, Aleksey Shipilev wrote:
>>> Why? `arguments.hpp` transitively includes it.
>>
>> I thought the rule is not to rely on transitive includes. Unless it is an
>> explicit umbrella header. If you need it, include it - that way if someone
>> changes the include tree
On Mon, 15 Aug 2022 10:57:04 GMT, Aleksey Shipilev wrote:
> Why? `arguments.hpp` transitively includes it.
I thought the rule is not to rely on transitive includes. Unless it is an
explicit umbrella header. If you need it, include it - that way if someone
changes the include tree, we minimize
On Sun, 14 Aug 2022 05:52:01 GMT, Ioi Lam wrote:
>> Enable CDS for zero builds. `java --version` is about 2x faster now.
>>
>>
>> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version
>> 0.034645 +- 0.44 seconds time elapsed ( +- 0.13% )
>> $ perf stat -r 40 ./images/jdk/bin/java -
On Thu, 11 Aug 2022 12:38:50 GMT, David Holmes wrote:
>> Please review this fix for a problem discovered by @stuart-marks in the
>> course of examining the VM shutdown behaviour. The VM code assumed that only
>> unattached threads called JNI's DestroyJavaVM and so they were always
>> attached
On Thu, 11 Aug 2022 02:31:21 GMT, David Holmes wrote:
>> Please review this fix for a problem discovered by @stuart-marks in the
>> course of examining the VM shutdown behaviour. The VM code assumed that only
>> unattached threads called JNI's DestroyJavaVM and so they were always
>> attached
On Thu, 11 Aug 2022 08:26:53 GMT, David Holmes wrote:
>> I disagree. Splitting the test leads causes better runtime (on my 24 core
>> machine: 10.5 seconds vs 16 seconds). It also makes the jtr file easier to
>> read, since it only contains one test. It also is simpler to run a selected
>> tes
On Thu, 11 Aug 2022 02:13:00 GMT, David Holmes wrote:
>> test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java line 36:
>>
>>> 34: * @run main/native TestDaemonDestroy
>>> 35: * @run main/native TestDaemonDestroy daemon
>>> 36: */
>>
>> If you do two @test sections, you can giv
On Tue, 9 Aug 2022 06:10:40 GMT, David Holmes wrote:
> Please review this fix for a problem discovered by @stuart-marks in the
> course of examining the VM shutdown behaviour. The VM code assumed that only
> unattached threads called JNI's DestroyJavaVM and so they were always
> attached as no
On Mon, 8 Aug 2022 13:25:22 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters wrote:
> Nothing I could find in the tests that suggest they use this message as
> input, and none of them have failed with this patch, so I guess that's a good
> thing? :P
Oh, that is fine :) Thanks for looking. I just mentioned it since you are
On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters wrote:
> I don't quite get what you mean by that, should I revert the changes made to
> the freeit checks?
I looked over this function and found a number of issues with it. I created
https://bugs.openjdk.org/browse/JDK-8292016 to track those (if y
On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote:
> To improve modularity and build time, move the declaration of the following
> accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp:
>
> + java_lang_Thread_FieldHolder
> + java_lang_Thread_Constants
> + java_lang_ThreadGroup
>
On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote:
>> Please review a small patch for dumping the failure reason when the MSVCRT
>> libraries or the Java Virtual Machine fails to load on Windows, which can
>> provide invaluable insight when debugging related launcher issues. This also
>> fi
On Sat, 6 Aug 2022 11:14:55 GMT, Julian Waters wrote:
>> src/java.base/share/native/libjli/emessages.h line 111:
>>
>>> 109: #define DLL_ERROR2 "Error: failed %s, because %s"
>>> 110: #define DLL_ERROR3 "Error: could not find executable %s"
>>> 111: #define DLL_ERROR4 "Error: Fail
On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote:
>> Please review a small patch for dumping the failure reason when the MSVCRT
>> libraries or the Java Virtual Machine fails to load on Windows, which can
>> provide invaluable insight when debugging related launcher issues. This also
>> fi
On Wed, 27 Jul 2022 14:34:49 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Wed, 27 Jul 2022 14:34:49 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote:
> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved,
> I'd like to disable
>
> - java/foreign/TestUpcallAsync.java
> - java/foreign/enablenativeaccess/TestEnableNativeAccess.java
>
> on m
On Mon, 18 Jul 2022 22:21:44 GMT, Jorn Vernee wrote:
>> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved,
>> I'd like to disable
>>
>> - java/foreign/TestUpcallAsync.java
>> - java/foreign/enablenativeaccess/TestEnableNativeAccess.java
>>
>> on muslc to take load from
Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd
like to disable
- java/foreign/TestUpcallAsync.java
- java/foreign/enablenativeaccess/TestEnableNativeAccess.java
on muslc to take load from our CIs.
Tests: tested locally that the tests are excluded on Alpine, and
On Thu, 14 Jul 2022 00:42:55 GMT, Ichiroh Takiguchi
wrote:
>> AIX build was failed by following messages:
>>
>> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
>> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
>> ld: 0711-317 ERROR: Undefined symbol: .collector_fun
On Tue, 12 Jul 2022 18:38:33 GMT, Ioi Lam wrote:
>> src/hotspot/os/posix/perfMemory_posix.cpp line 807:
>>
>>> 805: // Hold the lock until here to prevent other JVMs from using this
>>> file
>>> 806: // while we are in the middle of deleting it.
>>> 807: ::close(fd);
>>
>> I don't
On Tue, 12 Jul 2022 19:12:01 GMT, Ioi Lam wrote:
>> Some Kubernetes setups share the /tmp directory across multiple containers.
>> On rare occasions, the JVM may crash when it tries to write to
>> `/tmp/hsperfdata_/` when a process in a separate container
>> decides to do the same thing (becau
On Sat, 9 Jul 2022 06:49:03 GMT, Ioi Lam wrote:
>> Some Kubernetes setups share the /tmp directory across multiple containers.
>> On rare occasions, the JVM may crash when it tries to write to
>> `/tmp/hsperfdata_/` when a process in a separate container
>> decides to do the same thing (becaus
On Thu, 7 Jul 2022 21:21:27 GMT, Ioi Lam wrote:
>> Some Kubernetes setups share the /tmp directory across multiple containers.
>> On rare occasions, the JVM may crash when it tries to write to
>> `/tmp/hsperfdata_/` when a process in a separate container
>> decides to do the same thing (becaus
On Thu, 7 Jul 2022 21:58:55 GMT, Ioi Lam wrote:
>> src/hotspot/os/posix/perfMemory_posix.cpp line 781:
>>
>>> 779: // signal the process, then the file is assumed to
>>> 780: // be stale and is removed because the files for such a
>>> 781: // process should be in a different user spe
On Thu, 7 Jul 2022 06:01:58 GMT, Ioi Lam wrote:
> Some Kubernetes setups share the /tmp directory across multiple containers.
> On rare occasions, the JVM may crash when it tries to write to
> `/tmp/hsperfdata_/` when a process in a separate container decides
> to do the same thing (because th
On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote:
> Currently the ProcessBuilder/Basic.java test fails on musl.
> We run into
>>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at java.ba
On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote:
> Currently the ProcessBuilder/Basic.java test fails on musl.
> We run into
>>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at java.ba
On Fri, 1 Jul 2022 09:10:07 GMT, Christoph Langer wrote:
> This pull request contains a backport of
> [JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit
> [7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e)
> from the [openjdk/jdk](https:/
On Mon, 27 Jun 2022 08:15:01 GMT, Yi Yang wrote:
>> It seems that calculation of
>> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>>
>> Currently,
>> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>>
>> ==> CodeHeap
On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls wrote:
>> Test has been problemlisted for a long time due to intermittent failures.
>>
>> This is a difficult test as it tries to monitor usage thresholds on Memory
>> Pools which are outside its control.
>> Not just Java heap pools, where the alloc
On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore wrote:
>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>>
>> I left the commits intact to see better the progression of changes, but most
>> files are include file changes. The only tricky parts are that some files
On Tue, 21 Jun 2022 11:30:49 GMT, Yi Yang wrote:
> > > > I would have thought that since we don't have the pool anymore, we can
> > > > just remove this test line. The lines above already
> > > > test against MaxMetaspaceSize.
> > >
> > >
> > > Okay.
> > > > I think you may be right, we need a
On Tue, 21 Jun 2022 02:41:35 GMT, Yi Yang wrote:
> > I would have thought that since we don't have the pool anymore, we can just
> > remove this test line. The lines above already
> > test against MaxMetaspaceSize.
>
> Okay.
>
> > I think you may be right, we need a replacement for the old mem
On Fri, 27 May 2022 07:22:11 GMT, Thomas Stuefe wrote:
>>> I think the right fix is to just convert the MetaspacePool into
>>> NonClassMetaspacePool and only report the non-class values.
>>
>> Yes, it's okay for me. But I have another concern.
>>
>
On Fri, 17 Jun 2022 08:22:42 GMT, Yi Yang wrote:
>> test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.sh line 74:
>>
>>> 72: # we would have committed the space right away and therefore the
>>> MemoryMXBean "committed" trigger
>>> 73: # would have fired. In the new Metaspace, we don't
On Fri, 17 Jun 2022 07:02:47 GMT, Yi Yang wrote:
>> It seems that calculation of
>> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>>
>> Currently,
>> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>>
>> ==> CodeHeap
On Tue, 31 May 2022 15:10:38 GMT, Adam Sotona wrote:
>> This is continuation of PR #4256
>>
>> The patch simply rounds up the specified stack size to multiple of the
>> system page size, on systems where necessary.
>> The patch is based on the original PR/branch, with reflected remaining
>> r
On Sat, 28 May 2022 03:31:30 GMT, Yasumasa Suenaga wrote:
> We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so
> we should use `NULL` where we want to handle it.
>
> https://github.com/openjdk/jdk/pull/8646#discussion_r882294076
>
> Also I found using `0` as NUL char i
On Fri, 27 May 2022 06:25:45 GMT, Yi Yang wrote:
>
> If we remove `CompressedClassSpace`, we can only
> `getMemoryPool("Metaspace")`. Although metaspace is not baked in the
> specification, IMHO it's easier for developers to understand what is
> `metaspace` compared to the concepts of `Non Cl
On Fri, 27 May 2022 06:22:36 GMT, Ioi Lam wrote:
> > The basic problem is that we have two non-heap pools:
> >
> > * `MetaspacePool`
> >
> > * consists of `ClassType` and `NonClassType` parts
> > * `CompressedKlassSpacePool`
> >
> > but the `CompressedKlassSpacePool` is actually the "Class
On Thu, 26 May 2022 11:32:46 GMT, Yi Yang wrote:
>> I think the problem is the definition of the pools. We seem to have nested
>> pools but it is far from clear that this API/mechanism was designed/intended
>> to support nested pools.
>
> In any case, it's unreasonable for getNonHeapMemoryUsage
On Thu, 26 May 2022 12:47:42 GMT, David Holmes wrote:
>> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of
>> memory repeatedly, right? In the extreme case, we might add all nested pools
>> of metaspace, and we will get Metaspace x2 + CodeCache when using
>> getNonHe
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 Wed, 18 May 2022 18:10:45 GMT, Severin Gehwolf wrote:
>> @iklam yes I meant `Find the longest common prefix`. Fixed the comment.
>
> I'm not convinced the extra function makes the code more readable, but here
> it is. I can revert back if this is too much.
@jerboaa Feel free to go back to yo
On Wed, 18 May 2022 18:10:45 GMT, Severin Gehwolf wrote:
>> @iklam yes I meant `Find the longest common prefix`. Fixed the comment.
>
> I'm not convinced the extra function makes the code more readable, but here
> it is. I can revert back if this is too much.
@jerboaa Feel free to go back to yo
On Wed, 18 May 2022 06:12:41 GMT, David Holmes wrote:
>> Yasumasa Suenaga 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 three additional
>> co
On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik
wrote:
>> A gist of the fix is to allow relaxed special handling of code blob lookup
>> when done for ASGCT.
>>
>> Currently, a guarantee will fail when we happen to hit a zombie method which
>> is still on stack. While this would indicate
On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik
wrote:
>> A gist of the fix is to allow relaxed special handling of code blob lookup
>> when done for ASGCT.
>>
>> Currently, a guarantee will fail when we happen to hit a zombie method which
>> is still on stack. While this would indicate
On Tue, 17 May 2022 14:54:23 GMT, Johannes Bechberger
wrote:
>> But you aren't keeping it on the stack versus TLS you are using a stack
>> object to set the TLS. All we have done in this final form is replace:
>>
>>
>> thread->set_in_asgct(true);
>>
>> thread->set_in_asgct(false);
>>
>> wit
On Tue, 17 May 2022 12:23:56 GMT, David Holmes wrote:
>> Hi David,
>>
>>> You can't call `JavaThread::current()` in any of this code as it is not
>>> safe from a signal handling context. (There is an existing use in ASGCT
>>> that is also unsafe.) I suggest not having the no-arg constructor an
On Tue, 17 May 2022 08:13:11 GMT, Jaroslav Bachorik
wrote:
>> src/hotspot/share/prims/forte.hpp line 53:
>>
>>> 51: ASGCTMark() : ASGCTMark(JavaThread::current()) {}
>>> 52: ~ASGCTMark() {
>>> 53: JavaThread::current()->set_in_asgct(false);
>>
>> You can't call `JavaThread::current()`
On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use stringStream to simplify controller path assembly
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
>
>>
On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use stringStream to simplify controller path assembly
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
>
>>
On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote:
>> Please review this change to the cgroup v1 subsystem which makes it more
>> resilient on some of the stranger systems. Unfortunately, I wasn't able to
>> re-create a similar system as the reporter. The idea of using the longest
>> sub
On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf wrote:
>> Please review this change to the cgroup v1 subsystem which makes it more
>> resilient on some of the stranger systems. Unfortunately, I wasn't able to
>> re-create a similar system as the reporter. The idea of using the longest
>> sub
On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote:
> Please review this change to the cgroup v1 subsystem which makes it more
> resilient on some of the stranger systems. Unfortunately, I wasn't able to
> re-create a similar system as the reporter. The idea of using the longest
> substri
On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote:
> Please review this change to the cgroup v1 subsystem which makes it more
> resilient on some of the stranger systems. Unfortunately, I wasn't able to
> re-create a similar system as the reporter. The idea of using the longest
> substri
On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik
wrote:
>> A gist of the fix is to allow relaxed special handling of code blob lookup
>> when done for ASGCT.
>>
>> Currently, a guarantee will fail when we happen to hit a zombie method which
>> is still on stack. While this would indicate a
On Fri, 6 May 2022 14:20:30 GMT, Jaroslav Bachorik
wrote:
>> Functionally this looks good now - thanks.
>>
>> The only concern is the overhead added to `find_blob` to account for this
>> very special case. Can you do some benchmarking of this?
>>
>> Thanks.
>
> Hi @dholmes-ora , thanks for ta
On Tue, 3 May 2022 07:47:28 GMT, Matthias Baesken wrote:
> The test serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java fails
> on Alpine Linux using musl.
> Reason is the difference how dlclose is done
> https://wiki.musl-libc.org/functional-differences-from-glibc.html
> "musl’s dyn
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 Fri, 15 Apr 2022 10:04:12 GMT, Johannes Bechberger
wrote:
> > Thanks for the JFR insight, Marcus. I can see the CrashProtection being a
> > stop-gap measure under time constraints. Maybe worth rethinking now. From
> > your description, the way it is used in JFR differ significantly from how
On Thu, 14 Apr 2022 09:32:46 GMT, Thomas Stuefe wrote:
> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not
> reap zombies in a timely fashion.
> [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes
> this problem in detail.
>
&g
On Thu, 14 Apr 2022 18:29:21 GMT, Thomas Stuefe wrote:
>> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not
>> reap zombies in a timely fashion.
>> [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes
>> this problem in
On Thu, 14 Apr 2022 17:08:32 GMT, Markus Grönlund wrote:
> For additional context, I should add that the CrashProtection mechanism was
> mainly put in place as a result of having to deliver JFR from JRockit into
> Hotspot under a deadline, upholding feature-parity. The stack walking code
> was
On Thu, 14 Apr 2022 14:56:31 GMT, Roger Riggs wrote:
> Please update the copyright date. Thanks for including the explanation in the
> test.
Thank you @RogerRiggs! Would I need a second Reviewer?
-
PR: https://git.openjdk.java.net/jdk/pull/8240
ee comments in JBS), let
> us have a clarifying comment in the test itself.
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
fix copyright
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8240
On Thu, 14 Apr 2022 14:33:35 GMT, Johannes Bechberger
wrote:
> I compared the code of ASGCT and JFR and found only one instance of a method
> that is used in ASGCT, but not in JFR and which does affect the VM state. It
> is the `JavaThread::block_if_vm_exited` method which is transitively call
On Thu, 14 Apr 2022 11:30:13 GMT, Johannes Bechberger
wrote:
> > We have only one other subsystem that does this kind of wholesale catching
> > of error signals and then unwinding the stack (JFR) and presumably they
> > fine-combed their coding and are sure exactly what they do under the sigjm
On Thu, 14 Apr 2022 10:16:28 GMT, Ludovic Henry wrote:
> At
>
> https://github.com/openjdk/jdk/blob/77a21cb5658961b20011b7125a1ed896622faa4d/src/hotspot/share/prims/forte.cpp#L461
>
> , you have a NoHandleMark which wouldn’t get cleaned up in case of crash.
> For other such cases, it could be w
ee comments in JBS), let
> us have a clarifying comment in the test itself.
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
modify comment
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8240
ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not
reap zombies in a timely fashion.
[JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes this
problem in detail.
Until we figure out a way to fix that (if at all - see comments in JBS), let us
have a
On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger
wrote:
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd2
On Wed, 13 Apr 2022 15:11:41 GMT, Jaroslav Bachorik
wrote:
>> Move the AsyncGetCallTrace method implementation into a separate method and
>> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
>> like it is done in
>> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9c
On Wed, 13 Apr 2022 14:53:54 GMT, Johannes Bechberger
wrote:
> Move the AsyncGetCallTrace method implementation into a separate method and
> wrap its call in non-assert compilation mode in `os::ThreadCrashProtection`
> like it is done in
> [JFR](https://github.com/openjdk/jdk/blob/965ea8d9cd2
On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel wrote:
> Please review this small fix for JDK-8284642. The fix was tested by running
> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux
> x64. Additionally, the modified test and the test in the bug report were run
>
On Wed, 13 Apr 2022 12:24:46 GMT, Harold Seigel wrote:
> Please review this small fix for JDK-8284642. The fix was tested by running
> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux
> x64. Additionally, the modified test and the test in the bug report were run
>
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
901 - 1000 of 1317 matches
Mail list logo
