On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman wrote:
> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change
> GetVersion to return this version.
>
> test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that
> JNI_VERSION_19 is returned. The native library
On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev wrote:
> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
> fields are used, and therefore this is a serious bug. These ops seem to be
> used only from a few corner cases, which is probably why this was never
>
On Mon, 13 Jun 2022 07:45:41 GMT, Robbin Ehn wrote:
>> Johan Sjölén has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move assert up and remove other assert, remove unused var
>
> The only way to become an active handshaker is to
On Tue, 7 Jun 2022 12:42:05 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and
On Fri, 3 Jun 2022 09:45:31 GMT, Johan Sjölén wrote:
>> Please review this PR for fixing JDK-8287281.
>>
>> If a thread is handshake safe we immediately execute the closure, instead of
>> going through the regular Handshake process.
>>
>> Finally: Should `VirtualThreadGetThreadClosure` and
On Mon, 6 Jun 2022 07:19:06 GMT, David Holmes wrote:
>> Johan Sjölén has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - do_thread(target) not self
>> - Remove checks for is_handshake_for, instead call H
On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman wrote:
>> This patch adds an alternative virtual thread implementation where each
>> virtual thread is backed by an OS thread. It doesn't scale but it can be
>> used by ports that don't have continuations support in the VM. Aside from
>>
On Thu, 26 May 2022 17:26:25 GMT, Ichiroh Takiguchi
wrote:
> On AIX platform,
> `test/hotspot/jtreg/serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java`
> testcase failed by single testcase execution.
>
> Failure message is:
>
> Error occurred during initialization of VM
> agent
On Mon, 23 May 2022 07:28:41 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 Fri, 27 May 2022 02:12:32 GMT, Yi Yang wrote:
>> Yes counting it twice is wrong but this is the wrong fix. The pools are not
>> defined correctly.
>
>> Sorry for chiming in in a not very helpful way, but I am not sure what even
>> the point is of this API.
>>
>> I'm seriously interested in
On Thu, 26 May 2022 13:47:55 GMT, Thomas Stuefe 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
>>
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
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Thu, 26 May 2022 05:59:30 GMT, Yi Yang wrote:
>> src/hotspot/share/services/management.cpp line 753:
>>
>>> 751: for (int i = 0; i < MemoryService::num_memory_pools(); i++) {
>>> 752: MemoryPool* pool = MemoryService::get_memory_pool(i);
>>> 753: if (pool->is_codeheap() ||
On Wed, 25 May 2022 16:11:52 GMT, Chris Plummer wrote:
>> If virtual threads become permanent then the usage message would minimally
>> be updated to drop the sentence that virtual threads are a preview feature.
>> At that point the debugger APIs may have been built out further and it might
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
cc'ing hotspot-jfr-dev
On 26/05/2022 9:45 am, Mat Carter wrote:
The Microsoft Java Engineering Group (JEG) have been looking at how Java
developers can best understand the impact of their decisions on start-up time.
Specifically, how developers can identify and mitigate the dominant
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov 8 14:45:04 2021 +
On Mon, 23 May 2022 07:28:41 GMT, Yi Yang wrote:
> It seems that calculation of
> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>
> Currently, NonHeapUsage = CodeCache + Metaspace + CompressedClassSpace
>
> ==> CodeHeap 'non-nmethods' 1532544 (Used)
> ==> CodeHeap 'profiled
On Thu, 19 May 2022 15:29:14 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 880:
>>
>>> 878: "onuncaught=y|n debug on any uncaught?
>>> n\n"
>>> 879: "timeout= for listen/attach in milliseconds
>>> n\n"
>>> 880:
On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson wrote:
> When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU,
> the upper bits of the saved link register contain a "pointer authentication
> code" which must be checked and removed by a special instruction before a
>
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 15:48:47 GMT, Jaroslav Bachorik
wrote:
>> I thought that "this approach" referred to the approach of this PR (possibly
>> renaming the flag), as CrashProtection is orthogonal to the issue that this
>> PR solves.
>
>> thought that "this approach" referred to the approach of
On Tue, 17 May 2022 09:07:26 GMT, Thomas Stuefe wrote:
>> Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler.
>>
>> I have no strong opinion about whether we should keep it or not - it makes
>> the code in `forte.cpp` slightly more resilient in case of further
>>
On Mon, 16 May 2022 15:14:25 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 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
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
On Fri, 6 May 2022 20:17:53 GMT, Dean Long wrote:
>> Jaroslav Bachorik has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>> contains one new
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
On Thu, 5 May 2022 13:42:12 GMT, Jaroslav Bachorik
wrote:
>> An option would be to place it after
>> https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901
>> but it would make the code less coherent.
>
> Ok, moved it a bit
On Thu, 5 May 2022 12:40:02 GMT, Jaroslav Bachorik
wrote:
>> src/hotspot/share/runtime/thread.hpp line 649:
>>
>>> 647: // support AGCT
>>> 648: private:
>>> 649: bool _in_agct;
>>
>> This should actually be in JavaThread as AGCT only operates on JavaThreads.
>
> I will have to do
On Thu, 5 May 2022 12:08:54 GMT, Johannes Bechberger
wrote:
>> I would like to disagree: The abbreviation "ASGCT" is used in multiple
>> places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found).
>
> I found "AGCT" only in a method named
>
On Thu, 5 May 2022 12:13:18 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 Thu, 5 May 2022 11:51:47 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, 3 May 2022 23:20:28 GMT, Alex Menkov wrote:
>> The test counts all "system" threads before the execution and expects that
>> this number remains the same during test execution.
>> This makes the test fragile - JVM may start internal threads, some threads
>> may end.
>>
>> The fix
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
On Tue, 3 May 2022 08:02:57 GMT, Johannes Bechberger
wrote:
>> Calling JavaThread::thread_from_jni_environment for a terminated thread in
>> AsyncGetCallTrace might cause the acquisition of a lock, making
>> AsyncGetCallTrace non-signal-safe.
>>
>> AsyncGetCallTrace can only be called for
On Sat, 30 Apr 2022 10:54:07 GMT, David Holmes wrote:
>> this method does not exist
>
> Sorry I meant: `JavaThread::cast(rawThread)`
You missed changing the cast here. You could also save the result for use below.
-
PR: https://git.openjdk.java.net/jdk/pull/8446
On Fri, 29 Apr 2022 10:38:42 GMT, Johannes Bechberger
wrote:
>> src/hotspot/share/prims/forte.cpp line 571:
>>
>>> 569: Thread* raw_thread = Thread::current_or_null_safe();
>>> 570:
>>> 571: if (trace->env_id == NULL || raw_thread == NULL ||
>>> !raw_thread->is_Java_thread() ||
On Thu, 28 Apr 2022 11:38:32 GMT, Johannes Bechberger
wrote:
>> Calling JavaThread::thread_from_jni_environment for a terminated thread in
>> AsyncGetCallTrace might cause the acquisition of a lock, making
>> AsyncGetCallTrace non-signal-safe.
>>
>> AsyncGetCallTrace can only be called for
On Thu, 28 Apr 2022 11:15:34 GMT, David Holmes wrote:
>> Calling JavaThread::thread_from_jni_environment for a terminated thread in
>> AsyncGetCallTrace might cause the acquisition of a lock, making
>> AsyncGetCallTrace non-signal-safe.
>>
>> AsyncG
On Thu, 28 Apr 2022 09:38:30 GMT, Johannes Bechberger
wrote:
> Calling JavaThread::thread_from_jni_environment for a terminated thread in
> AsyncGetCallTrace might cause the acquisition of a lock, making
> AsyncGetCallTrace non-signal-safe.
>
> AsyncGetCallTrace can only be called for the
On Thu, 28 Apr 2022 07:16:05 GMT, Alan Bateman wrote:
>> Yes, that seems to be the case, and you are right that it is not something
>> that is safe to assume.
>
> Lookup.defineHiddenClass allows class options to be specified, one of which
> is "STRONG" to mean that the hidden class can't
On Thu, 21 Apr 2022 18:08:05 GMT, Kevin Walls wrote:
>> But on the other hand we have `javax.script.Invocable`. :-)
>>
>> Codespell suggested this change, and I based my decision to keep it based on
>> [Merriam-Webster](https://www.merriam-webster.com/dictionary/invocable) not
>> even
On Thu, 14 Apr 2022 15:19:17 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
>>
On Tue, 19 Apr 2022 19:08:26 GMT, Magnus Ihse Bursie wrote:
>> I ran `codespell` on hotspot, and accepted those changes where it indeed
>> discovered real typos.
>>
>> You'd be surprised over the many implementions of instrinsics and other
>> intructions accross all archtectures I've
On Thu, 14 Apr 2022 15:19:17 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
>>
On Tue, 19 Apr 2022 04:01:16 GMT, Chris Plummer wrote:
>> During the SA attach process on macOS, SA installs an exception handler and
>> expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On
>> aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found
On Thu, 14 Apr 2022 22:16:36 GMT, Chris Plummer wrote:
> During the SA attach process on macOS, SA installs an exception handler and
> expects to get an EXC_SOFTWARE exception for the expected SIGSTOP signal. On
> aarch64, sometimes it instead gets an EXC_BAD_INSTRUCTION exception. I found
>
On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on hotspot, and accepted those changes where it indeed
> discovered real typos.
>
> You'd be surprised over the many implementions of instrinsics and other
> intructions accross all archtectures I've encounted,
On Tue, 12 Apr 2022 00:12:42 GMT, Chris Plummer wrote:
>> Let's take advantage of Java 7 language feature - "Catching Multiple
>> Exception Types".
>> It simplifies code. Reduces duplication.
>> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try'
>> statement
>
>
On Fri, 8 Apr 2022 12:19:03 GMT, Andrey Turbanov wrote:
> Let's take advantage of Java 7 language feature - "Catching Multiple
> Exception Types".
> It simplifies code. Reduces duplication.
> Found by IntelliJ IDEA inspection Identical 'catch' branches in 'try'
> statement
Nice cleanup! Great
On Mon, 11 Apr 2022 11:55:33 GMT, Roman Kennke wrote:
>> JVMTI heap walking marks objects in order to track which have been visited
>> already. In order to do that, it uses bits in the object header. Those are
>> the same bits that are also used by some GCs to mark objects (the lowest two
>>
On Mon, 11 Apr 2022 13:50:49 GMT, Leo Korinth wrote:
>> Leo Korinth has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review updates
>
> I would like to have this change approved, or the approval of removing
> tracking the allocation
On Mon, 11 Apr 2022 06:41:54 GMT, Alan Bateman wrote:
>> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
>> with CNFE like "java.lang.NoClassDefFoundError:
>> jdk/test/lib/compiler/InMemoryJavaCompiler"
>>
>> It is not a loom specific bug, it might happen in jdk/jdk
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
On Tue, 5 Apr 2022 10:37:26 GMT, Kevin Walls wrote:
> A sanity check using "jcmd VM.info" to catch the signal handler modification
> warning: it should never trigger during this test.
Seems quite reasonable.
-
Marked as reviewed by dholmes (Reviewer).
PR:
On Wed, 30 Mar 2022 11:02:18 GMT, xpbob wrote:
>> ```
>>long hostTicks = getHostTotalCpuTicks0();
>> int totalCPUs = getHostOnlineCpuCount0();
>> int containerCPUs = getAvailableProcessors();
>> // scale the total host load
On Wed, 30 Mar 2022 02:08:16 GMT, xpbob wrote:
>> ```
>>long hostTicks = getHostTotalCpuTicks0();
>> int totalCPUs = getHostOnlineCpuCount0();
>> int containerCPUs = getAvailableProcessors();
>> // scale the total host load
On Wed, 30 Mar 2022 02:08:16 GMT, xpbob wrote:
>> ```
>>long hostTicks = getHostTotalCpuTicks0();
>> int totalCPUs = getHostOnlineCpuCount0();
>> int containerCPUs = getAvailableProcessors();
>> // scale the total host load
On Tue, 29 Mar 2022 05:24:59 GMT, Ioi Lam wrote:
>> src/hotspot/share/runtime/arguments.hpp line 113:
>>
>>> 111: bool writeable() const { return _writeable; }
>>> 112:
>>> 113: bool readable() const {
>>
>> Might be better/simpler to keep is_readable and change to
On Tue, 29 Mar 2022 04:24:15 GMT, Ioi Lam wrote:
>> `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in
>> arguments.cpp, which aborts the VM when it fails to allocate a string copy
>> of the property value.
>>
>>
>> bool PathString::set_value(const char *value) {
>>
On Tue, 29 Mar 2022 04:24:15 GMT, Ioi Lam wrote:
>> `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in
>> arguments.cpp, which aborts the VM when it fails to allocate a string copy
>> of the property value.
>>
>>
>> bool PathString::set_value(const char *value) {
>>
On Mon, 28 Mar 2022 18:34:31 GMT, Ioi Lam wrote:
>> `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in
>> arguments.cpp, which aborts the VM when it fails to allocate a string copy
>> of the property value.
>>
>>
>> bool PathString::set_value(const char *value) {
>>
On Sun, 27 Mar 2022 08:59:40 GMT, Christoph Langer wrote:
> Fix risv64 -> riscv64
Good catch!
-
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7977
On Tue, 22 Mar 2022 12:08:01 GMT, Fei Yang wrote:
>> make/autoconf/libraries.m4 line 152:
>>
>>> 150: fi
>>> 151:
>>> 152: # Programs which use C11 or C++11 atomics, like #include ,
>>
>> Use of C++ atomics is not allowed in hotspot code base. See the style guide:
>>
On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched
On Tue, 22 Mar 2022 03:31:16 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched
On Mon, 21 Mar 2022 12:44:58 GMT, Thomas Stuefe wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove two unnecessary lines
>
> I'm currently implementing Andrews proposal for a static safefetch
>
On 18/03/2022 5:21 pm, Johannes Bechberger wrote:
On Fri, 11 Mar 2022 07:52:16 GMT, Johannes Bechberger
wrote:
The WXMode for the current thread (on MacOS aarch64) is currently stored in the
thread class which is unnecessary as the WXMode is bound to the current OS
thread, not the current
Hi Johannes,
On 18/03/2022 7:43 pm, Bechberger, Johannes wrote:
Hi,
I would like propose to
1. Replace duplicated stack walking code with unified API
2. Create a new version of AsyncGetCallTrace, tentatively called
"AsyncGetCallTrace2", with more information on more frames using the unified
On 12/03/2022 2:37 am, Anton Kozlov wrote:
On Thu, 10 Mar 2022 18:04:50 GMT, Thomas Stuefe wrote:
blocking SIGSEGV and SIGBUS - or other synchronous error signals like SIGFPE -
and then triggering said signal is UB. What happens is OS-dependent. I saw
processes vanishing, or hang, or core.
On Wed, 16 Mar 2022 07:48:42 GMT, Yi Yang wrote:
>> Yi Yang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new commit since
On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger
wrote:
>> The WXMode for the current thread (on MacOS aarch64) is currently stored in
>> the thread class which is unnecessary as the WXMode is bound to the current
>> OS thread, not the current instance of the thread class.
>> This pull
On Thu, 10 Mar 2022 12:31:06 GMT, Anton Kozlov wrote:
> The signal mask is per-thread, and a native thread may block the JVM signal.
@AntonKozlov the signal from safefetch (if it is not safe) is a SIGSEGV or
SIGBUS. If these signals happen to be blocked and we raise the signal
synchronously
On Thu, 10 Mar 2022 07:31:47 GMT, Anton Kozlov wrote:
> How in general safe to call SafeFetch on a native thread that has no Thread
> object? The JVM has not initialized the thread, so there could be no JVM
> signal handler installed.
@AntonKozlov Signal handlers are per-process not
On Thu, 10 Mar 2022 03:55:01 GMT, Chris Plummer wrote:
>> A trivial fix to solve a memory leak/memory pinning for long runs of
>> suspendthrd003.
>>
>> See the bug report for the gory analysis details.
>>
>> This fix was included in my jdk-19+12 stress runs so the updated test was
>>
On Wed, 9 Mar 2022 20:41:37 GMT, Daniel D. Daugherty wrote:
> A trivial fix to solve a memory leak/memory pinning for long runs of
> suspendthrd003.
>
> See the bug report for the gory analysis details.
>
> This fix was included in my jdk-19+12 stress runs so the updated test was
> executed
On Wed, 9 Mar 2022 08:35:41 GMT, Johannes Bechberger
wrote:
>> The WXMode for the current thread (on MacOS aarch64) is currently stored in
>> the thread class which is unnecessary as the WXMode is bound to the current
>> OS thread, not the current instance of the thread class.
>> This pull
On Wed, 9 Mar 2022 10:11:06 GMT, Thomas Stuefe wrote:
>> @parttimenerd please never force-push in an active review as it completely
>> destroys the review history and comment context!
>
> Hi @dholmes-ora , @parttimenerd
>
> I'd like to argue again for my proposal from before.
>
> All this
On Wed, 9 Mar 2022 07:01:06 GMT, Johannes Bechberger
wrote:
>> but current_thread_wx would be too? Maybe I could change both to namespaces?
>
> But the style guide has no opinions on them...
If/when the styleguide has an opinion on namespaces I would expect the same
naming style to apply as
On Tue, 8 Mar 2022 12:07:08 GMT, Johannes Bechberger
wrote:
>> Johannes Bechberger has refreshed the contents of this pull request, and
>> previous commits have been removed. Incremental views are not available.
>
> I don't know why the Linux x86 build fails.
>
> I tested the current version
On Tue, 8 Mar 2022 10:32:46 GMT, Johannes Bechberger
wrote:
>> The WXMode for the current thread (on MacOS aarch64) is currently stored in
>> the thread class which is unnecessary as the WXMode is bound to the current
>> OS thread, not the current instance of the thread class.
>> This pull
On Tue, 8 Mar 2022 08:36:41 GMT, Johannes Bechberger
wrote:
>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.hpp line 57:
>>
>>> 55: static void current_thread_init_wx();
>>> 56:
>>> 57: static void current_thread_assert_wx_state(WXMode expected);
>>
>> Can we move all these into the
On Tue, 8 Mar 2022 00:25:51 GMT, Johannes Bechberger
wrote:
>> The WXMode for the current thread (on MacOS aarch64) is currently stored in
>> the thread class which is unnecessary as the WXMode is bound to the current
>> OS thread, not the current instance of the thread class.
>> This pull
On Mon, 7 Mar 2022 14:24:01 GMT, Thomas Stuefe wrote:
> We need to change the wx state of the current pthread in order to be able to
> execute stub routines. Otherwise, we would crash right away when trying to
> execute the SafeFetch stub.
Oh I see - that is unfortunate. I don't like messing
On Mon, 7 Mar 2022 11:29:08 GMT, Johannes Bechberger
wrote:
> The WXMode for the current thread (on MacOS aarch64) is currently stored in
> the thread class which is unnecessary as the WXMode is bound to the current
> OS thread, not the current instance of the thread class.
> This pull
On Fri, 4 Mar 2022 09:05:36 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstrap
>> java.lang.invoke.LambdaForm$MH/0x000800c0b400
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
I eyeballed the diff file and all seems okay.
Thanks,
David
-
Marked as reviewed by dholmes (Reviewer).
PR:
On Fri, 4 Mar 2022 03:53:52 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstrap
>> java.lang.invoke.LambdaForm$MH/0x000800c0b400
On Fri, 4 Mar 2022 03:03:10 GMT, Yi Yang wrote:
>> src/hotspot/share/services/diagnosticCommand.cpp line 964:
>>
>>> 962:"Dump the detail content of Java class. "
>>> 963:"Some classes are annotated with flags: "
>>> 964:"F = has finializer method, "
>>
>>
On Fri, 4 Mar 2022 03:07:26 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstrap
>> java.lang.invoke.LambdaForm$MH/0x000800c0b400
On Wed, 23 Feb 2022 21:59:35 GMT, Johannes Bechberger
wrote:
>> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using
>> the newly introduced method `JavaThread::thread_from_jni_environment`.
>
> Johannes Bechberger has updated the pull request incrementally with one
>
this pull request, and
> previous commits have been removed. The incremental views will show
> differences compared to the previous content of the PR. The pull request
> contains one new commit since the last revision:
>
> Add changes by David Holmes
Hi Johannes,
Your original cha
On Wed, 23 Feb 2022 05:56:18 GMT, Chris Plummer wrote:
>> This test has 4 test cases/modes: two core files test cases and two process.
>> Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to
>> run when `-XX:+DeoptimizeALot` is used, because the test does some checks
>>
On Wed, 16 Feb 2022 00:16:48 GMT, Zhengyu Gu wrote:
>> There are scenarios that JDWP agent can deadlock on `classTrackLock`
>> monitor. Following is the scenario in bug report.
>>
>> **Java Thread**
>> - loads a class and post `JVMTI_EVENT_CLASS_PREPARE` event
>> - JDWP event callback
On Sat, 19 Feb 2022 04:00:30 GMT, Chris Plummer wrote:
> This test has 4 test cases/modes: two core files test cases and two process.
> Each runs with and w/o `-Xcomp`. The `-Xcomp` test cases are not suppose to
> run when `-XX:+DeoptimizeALot` is used, because the test does some checks
>
On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger
wrote:
> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the
> newly introduced method `JavaThread::thread_from_jni_environment`.
Please do update. Thanks.
-
PR:
On Mon, 21 Feb 2022 14:43:27 GMT, Johannes Bechberger
wrote:
> Fixes the mentioned bug by replacing the check in AsyncGetCallTrace using the
> newly introduced method `JavaThread::thread_from_jni_environment`.
I don't like unnecessary special-cases. I added the `ShouldNotReachHere()` due
to
1 - 100 of 2969 matches
Mail list logo
