Re: RFR(8u) JDK-8153252: SA: Hotspot build on Windows fails if make/closed folder does not exist

Hello, As per Erik's suggestion not to remove the existing check for HS_ALT_MAKE, here is the updated webrev: http://cr.openjdk.java.net/~poonam/8153252/webrev.01/ Thanks, Poonam On 4/11/2016 12:15 PM, Poonam Bajaj Parhar wrote: Hello, Please review this simple fix. Bug JDK-8153252

Re: RFR 8150607 - Clean up CompactHashtable

Hi Ioi, Just a few minor comments. No need to see another webrev. compactHashtable.cpp: 71 _num_entries ++; extra space before ++ similarly in lines 80, 112, 123, 125 118 Entry tent = bucket->at(i); It is clearer if 'tent' is just 'ent' since the code in this block is not dealing w

Re: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly

On 4/13/16 09:48, Coleen Phillimore wrote: Dan, Thank you for reviewing this. On 4/13/16 12:07 PM, Daniel D. Daugherty wrote: On 4/11/16 2:06 PM, Coleen Phillimore wrote: Summary: Constant pool merging is not thread safe for source_file_name. This change includes the change for the following

Re: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly

Dan, Thank you for reviewing this. On 4/13/16 12:07 PM, Daniel D. Daugherty wrote: On 4/11/16 2:06 PM, Coleen Phillimore wrote: Summary: Constant pool merging is not thread safe for source_file_name. This change includes the change for the following bug because they are tested together. 81

RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS

Everybody. Please review a small fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/ I don't have a reproducer, so the fix is based on coredump analyzes. Tested with rbt -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to chang

Re: RFR 8151546: nsk/jvmti/RedefineClasses/StressRedefine fails in hs nightly

On 4/11/16 2:06 PM, Coleen Phillimore wrote: Summary: Constant pool merging is not thread safe for source_file_name. This change includes the change for the following bug because they are tested together. 8148772: VM crash in nsk/jvmti/RedefineClasses/StressRedefine: assert failed: Corrupted

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi Dmitry, Thank you for your comment. I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.02/ Thanks, Yasumasa On 2016/04/13 21:41, Dmitry Samersoff wrote: Yasumasa, Yes. It's better. Please place all _saved_* declarations together an

Re: PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Yasumasa, Yes. It's better. Please place all _saved_* declarations together and add a comment explaining what is the purpose of this variables. -Dmitry On 2016-04-13 15:20, Yasumasa Suenaga wrote: > Hi all, > > Could you review and sponsor it? > >>http://cr.openjdk.java.net/~ysuenaga/JDK

PING: RFR: JDK-8151815: Could not parse core image with JSnap.

Hi all, Could you review and sponsor it? http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.01/ If it is not accepted, I think that we can add new field to PerfMemory for using in JSnap: --- diff -r 4823056a5bbd src/share/vm/runtime/perfMemory.cpp --- a/src/share/

Re: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1

> On 13 apr. 2016, at 11:06, Dmitry Samersoff > wrote: > > Staffan, > >> Do you know if the change in jps output was intentional or caused by >> something else? > > Sorry, I don't know what change jps output. The problem is that the sun.java.command property has changed format with jigsaw.

Re: RFR(XS): JDK-8153856 com/sun/jdi/WatchFramePop.sh fails with exit code 1

Staffan, > Do you know if the change in jps output was intentional or caused by > something else? Sorry, I don't know what change jps output. -Dmitry On 2016-04-12 22:06, Staffan Larsen wrote: > Thanks for the explanation. The change looks good. > > Do you know if the change in jps output was

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

Thanks Serguei! - Andreas On 2016-04-12 20:57, serguei.spit...@oracle.com wrote: Hi Andreas, The fix looks good. Thanks, Serguei On 4/12/16 09:05, Andreas Eriksson wrote: Hi, Please review this fix for 8153641: assert(thread_state == _thread_in_native) failed: Assumed thread_in_native wh