Re: RFR (XS): 8196450: Deprecate JDWP/JDI canUnrestrictedlyRedefineClasses to match JVM TI capabilities

Thank you for review, Chris! Serguei On 6/5/20 16:11, Chris Plummer wrote: Hi Serguei, Looks good. thanks, Chris On 6/5/20 6:05 AM, David Holmes wrote: Sorry Serguei I got distracted and forgot about the RFR part of this. Reviewed :) Thanks, David On 5/06/2020 3:19 pm, serguei.spit...

Re: RFR (XS): 8196450: Deprecate JDWP/JDI canUnrestrictedlyRedefineClasses to match JVM TI capabilities

Hi Serguei, Looks good. thanks, Chris On 6/5/20 6:05 AM, David Holmes wrote: Sorry Serguei I got distracted and forgot about the RFR part of this. Reviewed :) Thanks, David On 5/06/2020 3:19 pm, serguei.spit...@oracle.com wrote: Hi David, You have already approved the CSR below. May I co

Re: RFR (XS): 8196450: Deprecate JDWP/JDI canUnrestrictedlyRedefineClasses to match JVM TI capabilities

Thank you, David! Sorry for late reply. I did not see you message until restarted my Zunderbird email client. Thanks, Serguei On 6/5/20 06:05, David Holmes wrote: Sorry Serguei I got distracted and forgot about the RFR part of this. Reviewed :) Thanks, David On 5/06/2020 3:19 pm, serguei.

Re: RFR(S) : 8246494 : introduce vm.flagless at-requires property

Hi Per, you are reading this correctly, make TEST=test/hotspot/jtreg/gc/z/TestSmallHeap.java JTREG="VM_OPTIONS=-XX:+UseZGC" won't execute gc/z/TestSmallHeap.java; and I don't see it to be incorrect. Let me try to explain why using gc/z/TestSmallHeap.java as a running example. A hotspot test i

RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Ralf, Thanks for the quick reply and all the fixes. The changes to the workgroup are ok. Reviewed. (An incremental webrev would have helped 😊) What kind of tests did you run? > Yes, the buffer is now smaller (1M) versus the original (8M). You need > to be able to at least allocate one buffe

Re: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Goetz, thanks for the detailed review. I've incorporated your suggestions into a new webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.4/ In addition this new version adds a feature to the WorkGang, to execute the task in the foreground thread too (the thread which calls

Re: RFR (XS): 8196450: Deprecate JDWP/JDI canUnrestrictedlyRedefineClasses to match JVM TI capabilities

Sorry Serguei I got distracted and forgot about the RFR part of this. Reviewed :) Thanks, David On 5/06/2020 3:19 pm, serguei.spit...@oracle.com wrote: Hi David, You have already approved the CSR below. May I count it as a review as there is no difference between CSR and webrev - both have t

JVMTI callback SampledObjectAlloc always fires for first allocation in a new thread

Hi, JVMTI callback SampledObjectAlloc is currently always called for the first allocation of a thread. This generates a lot of bias in an application that regularly starts new threads. I tested this with latest Java 11 and Java 15. E.g. here is a sample that creates 100 threads and allocates one

Re: RFR(S) : 8246494 : introduce vm.flagless at-requires property

Hi Igor, When looking at the follow-up sub-tasks for this, I see for example this: http://cr.openjdk.java.net/~iignatyev/8246499/webrev.00/test/hotspot/jtreg/gc/z/TestSmallHeap.java.udiff.html Maybe I'm misunderstanding how this is supposed to work, but it looks like this test would now _not_

RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

I see. Thanks for the explanation :) Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Freitag, 5. Juni 2020 09:31 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; hotspot-gc-..

Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Hi Richard, On 6/5/20 00:18, Reingruber, Richard wrote: Hi, The mach5 test run is good. Thanks Serguei and thanks to everybody providing feedback! I just pushed the change. Great, thanks! Just curious: is mach5 an alias for tier5? The mach5 is a build and test system which also provid

RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Hi, > The mach5 test run is good. Thanks Serguei and thanks to everybody providing feedback! I just pushed the change. Just curious: is mach5 an alias for tier5? And is this mach5 the same as in "Job: mach5-one-rrich-JDK-8238585-2-20200604-1334-11519059" which is the (successful) submit repo