Re: RFR: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes

Hi Yasumasa, Thanks for the answer and sorry for the latency. It is not easy to double check everything related to the JvmtiThreadState_lock use. You are right, it is not safe to remove the MutexLockers around the direct handshakes (unfortunately, I'm still

Re: RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions

Hi Christoph, I think this test should be moved to test/hotspot/jtreg/resourcehogs/serviceability/jvmti even if @requires os.maxMemory fixes the issue. It's could actually already be causing sporadic undiagnosed intermittent failures with other tests being run concurrently. It's best to just

Re: RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions

Hi The exhausting of RAM could lead to unexpected failures of other tests executed concurrently on this host and/or other environment related issues. I think you might want to add *@requires* tag to skip test on the hosts with small amount of RAM. Like '@requires os.maxMemory > 6G'. See for

Re: RFD: 8252768: Fast, asynchronous heap dumps

On 9/3/20 12:36 PM, Thomas Stüfe wrote: On Thu, Sep 3, 2020, 21:27 Laurence Cable > wrote: On 9/3/20 12:25 PM, Thomas Stüfe wrote: On Thu, Sep 3, 2020, 21:07 Laurence Cable mailto:larry.ca...@oracle.com>> wrote: On 9/3/20 9:03 AM, Volk

Re: RFD: 8252768: Fast, asynchronous heap dumps

On Thu, Sep 3, 2020, 21:27 Laurence Cable wrote: > > > On 9/3/20 12:25 PM, Thomas Stüfe wrote: > > > > On Thu, Sep 3, 2020, 21:07 Laurence Cable wrote: > >> >> >> On 9/3/20 9:03 AM, Volker Simonis wrote: >> > Hi, >> > >> > I'd like to get your opinion on a POC I've done in order to speed up >> >

Re: RFD: 8252768: Fast, asynchronous heap dumps

On 9/3/20 12:25 PM, Thomas Stüfe wrote: On Thu, Sep 3, 2020, 21:07 Laurence Cable > wrote: On 9/3/20 9:03 AM, Volker Simonis wrote: > Hi, > > I'd like to get your opinion on a POC I've done in order to speed up > heap dumps on Linux:

Re: RFD: 8252768: Fast, asynchronous heap dumps

On Thu, Sep 3, 2020, 21:07 Laurence Cable wrote: > > > On 9/3/20 9:03 AM, Volker Simonis wrote: > > Hi, > > > > I'd like to get your opinion on a POC I've done in order to speed up > > heap dumps on Linux: > > > > https://bugs.openjdk.java.net/browse/JDK-8252768 > > http://cr.openjdk.java.net/~si

Re: RFD: 8252768: Fast, asynchronous heap dumps

On 9/3/20 9:03 AM, Volker Simonis wrote: Hi, I'd like to get your opinion on a POC I've done in order to speed up heap dumps on Linux: https://bugs.openjdk.java.net/browse/JDK-8252768 http://cr.openjdk.java.net/~simonis/webrevs/2020/8252768/ Currently, heap dumps can be taken by the SA tool

Re: RFD: 8252768: Fast, asynchronous heap dumps

Hi Volker, On Thu, Sep 3, 2020 at 7:41 PM Volker Simonis wrote: > Hi Thomas, > > Thanks for sharing your concerns. Please find my anserwers inline: > > On Thu, Sep 3, 2020 at 6:58 PM Thomas Stüfe > wrote: > > > > Hi Volker, > > > > hah, that is a cool idea :) > > > > Lets see what could go wron

RE: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Thanks for the re-review and approval, Volker. Now we just have to wait for the CSR to be approved. I'm going to leave INT_MAX because that's the argument the original patch passes to jmm_DumpThreads via the dumpThreads0 native method in ThreadImpl.java. Serguei, do you want to re-review? On

Re: RFD: 8252768: Fast, asynchronous heap dumps

Hi Thomas, Thanks for sharing your concerns. Please find my anserwers inline: On Thu, Sep 3, 2020 at 6:58 PM Thomas Stüfe wrote: > > Hi Volker, > > hah, that is a cool idea :) > > Lets see what could go wrong: > > So, child process is forked, but in the child only the forking thread > survives,

Re: RFD: 8252768: Fast, asynchronous heap dumps

Hi Volker, hah, that is a cool idea :) Lets see what could go wrong: So, child process is forked, but in the child only the forking thread survives, right? The forking thread then proceeds to dump. What happens when, during dumping, it needs a lock owned by one of the non-running threads? Could

Re: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

On Tue, Sep 1, 2020 at 9:44 PM Hohensee, Paul wrote: > > Hi, > > I've re-finalized the CSR after Volker's re-review. See > https://bugs.openjdk.java.net/browse/JDK-8251498. It now says we won't update > JMM_VERSION. I've also updated the webrevs to reflect the CSR changes and to > target 8u282.

RFD: 8252768: Fast, asynchronous heap dumps

Hi, I'd like to get your opinion on a POC I've done in order to speed up heap dumps on Linux: https://bugs.openjdk.java.net/browse/JDK-8252768 http://cr.openjdk.java.net/~simonis/webrevs/2020/8252768/ Currently, heap dumps can be taken by the SA tools from a frozen process or core file or direct

RE: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

Hi David, > > > > Furthermore I have corrected the type of the parameter waitCycles of > > Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it > > matches the declaration in GetLocalWithoutSuspendTest.java. > Hmmm ... could this mean that the attempt to read a 64-bit value

RFR(XS): 8252773: [TESTBUG] serviceability/jvmti/GetObjectSizeOverflow fails due to OOM conditions

Hi, please review the following patch for the GetObjectSizeOverflow test. Bug: https://bugs.openjdk.java.net/browse/JDK-8252773 Webrev: https://cr.openjdk.java.net/~cgo/8252773/webrev.00 The test case already handles out of memory conditions, but not if the whole JVM crashes because of it. T

RE: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

Hi Serguei, > This looks reasonable to me. Thanks! > The only question is about the quality of this testing. > How are we sure these errors are caused by races but not bugs in the > GetLocalObject implementation? I'm not sure. Unfortunately I cannot reproduce it even though I tried. I had 40 i

Re: RFR: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes

Hi Serguei, Your suggestion would not grab lock if it performs in direct handshake, then other threads can enter these functions. Is it safe? Thanks, Yasumasa On 2020/09/03 16:34, serguei.spit...@oracle.com wrote: Hi Yasumasa, Wood it be MT-safe to do this to avoid locks at handshake time

Re: RFR: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes

Hi Yasumasa, Wood it be MT-safe to do this to avoid locks at handshake time? :  JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop fpop) { -  MutexLocker mu(SafepointSynchronize::is_at_safepoint() ? NULL : JvmtiThreadState_lock); +  MutexLocker mu(Thread::current == e