Re: RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces

Daniil, I forgot to ask you an output log of new tests. Could you, please, inline it in your reply? Thanks, Serguei On 7/20/20 18:48, serguei.spit...@oracle.com wrote: Hi Daniil, The fix looks pret

Re: RFR (M) 8249768: Move static oops and NullPointerException oops from Universe into OopStorage

Hi Coleen, cc'ing serviceability due to SA changes. On 21/07/2020 6:53 am, coleen.phillim...@oracle.com wrote: Summary: Move static oops into OopStorage and make NPE oops an objArrayOop. I've broken up moving oops in Universe to OopStorage into several parts.  This change moves the global sta

Re: RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces

Hi Daniil, The fix looks pretty good to me. Just minor comments. http://cr.openjdk.java.net/~dtitov/8216324/webrev.01/src/hotspot/share/prims/jvmtiEnv.cpp.frames.html 2519 int skipped = 0; // skip default methods from superinterface (see J

Re: [15?] RFR (S): 8249192: MonitorInfo stores raw oops across safepoints

Hi Thomas, On 21/07/2020 12:49 am, Thomas Schatzl wrote: Forwarding to hotspot-dev where it belongs after wrongly sending to hotspot-gc-dev. This touches serviceability code as well so cc'ing for good measure. Thanks for taking this one on as it wasn't actually a GC issue! Forward

Re: RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces

Looks good to me :) Thanks for handling this. --alex On 07/20/2020 12:00, Daniil Titov wrote: Please review change [1] that fixes GetClassMethods behavior in cases if a default method is present in a super interface. Currently for such cases the information GetClassMethods returns for the sub

RFR: 8216324: GetClassMethods is confused by the presence of default methods in super interfaces

Please review change [1] that fixes GetClassMethods behavior in cases if a default method is present in a super interface. Currently for such cases the information GetClassMethods returns for the sub-interface or implementing class incorrectly includes inherited not default methods. The fix (

Re: RFR (M) 8249650: Optimize JNIHandle::make_local thread variable usage

On 7/20/20 1:53 AM, David Holmes wrote: Hi Kim, Thanks for looking at this. Updated webrev at: http://cr.openjdk.java.net/~dholmes/8249650/webrev.v2/ I like this cleanup very much! src/hotspot/share/classfile/javaClasses.cpp     No comments. src/hotspot/share/classfile/verifier.cpp     L2

Re: RFR 8247878: Move Management strong oops to OopStorage

David, thank you for the review and help. Coleen On 7/20/20 12:47 AM, David Holmes wrote: Hi Coleen, On 18/07/2020 7:29 am, coleen.phillim...@oracle.com wrote: I've corrected this change with Kim's and David's feedback, and retested with tier1-3.  This is much better. Yes this is better.

Re: RFR 8247878: Move Management strong oops to OopStorage

Kim, Thank you for your help. Coleen On 7/20/20 1:25 AM, Kim Barrett wrote: On Jul 20, 2020, at 12:47 AM, David Holmes wrote: Hi Coleen, On 18/07/2020 7:29 am, coleen.phillim...@oracle.com wrote: I've corrected this change with Kim's and David's feedback, and retested with tier1-3. This

RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()

Hi, please help review this fix for VM_GetOrSetLocal. It moves the unsafe stackwalk from the vm operation prologue before the safepoint into the doit() method executed at the safepoint. Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.0/index.html Bug:https://bugs.openjdk.ja

Re: RFR (M) 8249650: Optimize JNIHandle::make_local thread variable usage

Thanks Kim! David On 20/07/2020 4:15 pm, Kim Barrett wrote: On Jul 20, 2020, at 1:53 AM, David Holmes wrote: Hi Kim, Thanks for looking at this. Updated webrev at: http://cr.openjdk.java.net/~dholmes/8249650/webrev.v2/ Looks good. On 20/07/2020 3:22 pm, Kim Barrett wrote: On Jul 20,