Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

On 4/15/16 11:59, Dmitry Samersoff wrote: Severin, Looks good for me. But I'm a little afraid of the fact that now we are holding eventHandler_lock while doing invoke*. It seems, I have this concern too. Please, let me take a look closer at this part if it is done in a right way. So

Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

Severin, Looks good for me. But I'm a little afraid of the fact that now we are holding eventHandler_lock while doing invoke*. So please hold on with backports until the fix bakes in jdk9 for some time. -Dmitry On 2016-04-15 19:53, Severin Gehwolf wrote: > Hi, > > Here is a patch which is a

Re: RFR: 8149790: NegativeArraySizeException with hprof

Looks good, not a Reviewer. Do you really need curly braces in the switch clauses? Erik On 2016-04-15 16:40, Andreas Eriksson wrote: Hi, Please review this test fix for 8149790: NegativeArraySizeException with hprof https://bugs.openjdk.java.net/browse/JDK-8149790

Re: RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

Hi Severin, The fix looks good to me. I can sponsor the fix once it is reviewed. Not sure, if I need to run the previously failed tests in the big loops or rely on your testing. Included Dan who did a back out into the cc-list. Thanks a lot for taking care to redo the fix! Thanks, Serguei

Re: RFR: 8153749 - New capability can_generate_early_class_hook_events

On 4/15/16 04:00, Alan Bateman wrote: On 14/04/2016 21:30, serguei.spit...@oracle.com wrote: Alan, This is for sanity check: The updated hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs2/ Please, note that the

RFR(s) 8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

Hi, Here is a patch which is a redo of the fix for JDK-4858370 which got backed out due to it causing test regressions. Specifically problems were reported for com/sun/jdi/InvokeTest.java and com/sun/jdi/InterfaceMethodsTest.java with the fix for JDK-4858370 applied. Those test regressions were

RFR: 8149790: NegativeArraySizeException with hprof

Hi, Please review this test fix for 8149790: NegativeArraySizeException with hprof https://bugs.openjdk.java.net/browse/JDK-8149790 http://cr.openjdk.java.net/~aeriksso/8149790/webrev.00/ Changes are to the hprof verifier, which now will pass heap dump content around as JavaThing arrays

Re: PerfData counter: sun.gc.policy.generations in JDK 8

Hi Ramki and Jon, What's the status of this review thread? The bug is still open and targeted for JDK 9. Thanks, StefanK On 2015-06-03 08:15, Srinivas Ramakrishna wrote: Thanks Jon for the review and the pointer to the test. I'll get back to you later this week with a suitable test. --

Re: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump

Thanks Staffan! - Andreas On 2016-04-15 13:00, Staffan Larsen wrote: Looks good! Thanks, /Staffan On 12 apr. 2016, at 18:05, Andreas Eriksson > wrote: Hi, Please review this fix for 8153641: assert(thread_state ==

Re: RFR: 8153749 - New capability can_generate_early_class_hook_events

On 14/04/2016 21:30, serguei.spit...@oracle.com wrote: Alan, This is for sanity check: The updated hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs2/ Please, note that the *src/share/vm/prims/jvmtiEnvBase.hpp* was corrected too. In

Re: [8u] RFR: 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native while heap dump

Looks good! Thanks, /Staffan > On 12 apr. 2016, at 18:05, Andreas Eriksson > wrote: > > Hi, > > Please review this fix for 8153641: assert(thread_state == _thread_in_native) > failed: Assumed thread_in_native while heap dump > > Bug: