Re: RFR (M) 8212160: JVMTI agent crashes with "assert(_value != 0LL) failed: resolving NULL _value"

Hi Coleen, This looks great. Thanks for sorting this out! /Erik On 12/2/19 3:43 PM, coleen.phillim...@oracle.com wrote: On 11/26/19 7:03 PM, David Holmes wrote: (adding runtime as well) Hi Coleen, On 27/11/2019 12:22 am, coleen.phillim...@oracle.com wrote: Summary: Add local deferred even

Re: RFR (S) 8173361: various crashes in JvmtiExport::post_compiled_method_load

Hi Coleen, Thanks for removing the nmethodLocker. I'm on a mission to remove all nmethod lockers, and this one is really nasty. Looks good. Thanks, /Erik On 11/21/19 3:12 PM, coleen.phillim...@oracle.com wrote: Please review a new version of this change that keeps the nmethod from being un

Re: RFR: 8231943: ZGC: Enable serviceability/dcmd/gc/RunGCTest

+1 /Erik > On 10 Oct 2019, at 14:28, Per Liden wrote: > > (CC:ing serviceability-dev) > >> On 10/7/19 2:38 PM, Per Liden wrote: >> This test is currently disabled for ZGC, but it can easily be enabled by >> adjusting the expected log string. ZGC doesn't print "Pause Full", but it >> still p

Re: RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata

Hi Coleen, Could you please make the counter uint64_t instead? We usually use 64 bit unsigned counters when we don't want to think about overflow. Otherwise I like the approach. Don't need another webrev... This looks good. Thanks, /Erik On 9/26/19 3:29 AM, coleen.phillim...@oracle.com wrote

Re: RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime

Hi Martin, Looks good for me. Thanks for cleaning up this code! /Erik > On 23 Jul 2019, at 19:50, Doerr, Martin wrote: > > Hi Erik, > > adding Andrew and Aleksey. > >> The new webrev looks good. > Thanks. > >> Note though the following though... it looks like the AArch64 code >> doesn't do

Re: RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime

, which parts did you review (x86, SPARC, shared code)? >> Thanks and best regards, >> Martin >>> -Original Message- >>> From: Doerr, Martin >>> Sent: Freitag, 19. Juli 2019 13:11 >>> To: David Holmes ; hotspot-runtime- >>> d...@openjdk.jav

Re: RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime

n my initial proposal. > > Best regards, > Martin > > >> -Original Message- >> From: Erik Osterlund >> Sent: Donnerstag, 18. Juli 2019 08:43 >> To: Doerr, Martin >> Cc: hotspot-runtime-...@openjdk.java.net; serviceability- >> d...@open

Re: RFR(M): 8227680: FastJNIAccessors: Check for JVMTI field access event requests at runtime

Hi Martin, Since the JNI calls go through function pointers in the JNI env that go either to the fast or slow version, could one option be to go through the JNI envs and change the function pointers to the slow one when this JVMTI feature is enabled? Advantages: 1) No need to change the platfor

Re: RFR(XXS): 8227338: templateInterpreter.cpp: copy_table() needs to be safer

Yeah that switch statement code and yet another plain non-volatile load/store loop looks like complete nonsense unfortunately. It should at least use Atomic::load/store. Fortunately, on x86_64, I believe it will in practice yield word atomic copying anyway by chance. But it should be fixed anyw

Re: RFR(XXS): 8227117: normal interpreter table is not restored after single stepping with TLH

Thanks Dan! /Erik On 5 Jul 2019, at 21:53, Daniel D. Daugherty wrote: >> I'll file a follow up bug after the dust settles for 8227117. > > I filed the following: > > JDK-8227338 templateInterpreter.cpp: copy_table() needs to be safer > https://bugs.openjdk.java.net/browse/JDK-822733