Integrated: 8273152: Refactor CDS FileMapHeader loading code

On Thu, 30 Sep 2021 05:43:40 GMT, Yumin Qi wrote: > Please review, > Refactor fundamental CDS FileMapHeader code for reliable reading of basic > info from shared archive. > With the change, it makes it possible to read an archive generated by > different version of hots

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8]

On Thu, 7 Oct 2021 06:06:02 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add offset check for _generic_header in populate_header > > LGTM @iklam @calvinccheung Thanks

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8]

On Thu, 7 Oct 2021 20:30:00 GMT, Calvin Cheung wrote: > I just have one minor comment. It's up to you if you want to change it. Thanks for review --- I will leave as it is now. - PR: https://git.openjdk.java.net/jdk/pull/5768

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v8]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Add offset check

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5]

On Wed, 6 Oct 2021 17:01:58 GMT, Ioi Lam wrote: >> see above reply. We need read the full _header_size for _header. Also note >> that helper class will delete gen_header when out of scope. > > I see. I think your current code is fine. > > Note that the current code writes the header as a FileMa

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v7]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Change FileHe

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5]

On Wed, 6 Oct 2021 04:09:32 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added a helper class to facilitate checking archive > > src/hotspot/share/cds/filemap.cpp line 1

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v6]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed comment

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5]

On Wed, 6 Oct 2021 04:15:06 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added a helper class to facilitate checking archive > > src/hotspot/share/cds/filemap.cpp line

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5]

On Wed, 6 Oct 2021 04:17:16 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added a helper class to facilitate checking archive > > src/jdk.hotspot.agent/share/native/libsa

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v5]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Added a help

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v4]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed comment

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v3]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed output accordi

Re: RFR: 8273152: Refactor CDS FileMapHeader loading code [v2]

gt; CDS archive If the archive supplied is not readable or fails to pass the > check. > > Tests: tier1-4 >jtreg on sa. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed miss return after f

RFR: 8273152: Refactor CDS FileMapHeader loading code

Please review, Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive. With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive su

Re: RFR: 8259070: Add jcmd option to dump CDS [v12]

On Sat, 27 Feb 2021 18:20:52 GMT, Ioi Lam wrote: >> Hi Yumin, >> >> This is a very useful addition. >> >> My biggest concern with this patch though is the use of >> `os::fork_and_exec()` in regular, non-fatal situations. I had a look at that >> function and I think that is very unsafe. >> >>

Integrated: 8259070: Add jcmd option to dump CDS

On Fri, 26 Feb 2021 00:03:40 GMT, Yumin Qi wrote: > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. > Before this change, user has to dump shared archive in two steps: first run > application with > `java -XX:DumpLoadedClassLi

Re: RFR: 8259070: Add jcmd option to dump CDS [v12]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v11]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v10]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v9]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v8]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

On Fri, 19 Mar 2021 05:39:25 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains five additional

Re: RFR: 8259070: Add jcmd option to dump CDS [v7]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v6]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v5]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

On Fri, 26 Feb 2021 22:46:07 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains five additional

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

On Fri, 26 Feb 2021 22:01:50 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains five

Re: RFR: 8259070: Add jcmd option to dump CDS [v3]

On Wed, 10 Mar 2021 04:28:04 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix white space in CDS.java > > src/java.base/share/classes/jdk/internal/misc/CDS.jav

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

On Sat, 27 Feb 2021 18:11:38 GMT, Ioi Lam wrote: >> How would it overflow? But I agree, I would not add jsa extension if the >> user did not specify one. I dislike when programs do that. > > `file_name` is user input that comes from the jcmd, so it can be arbitrarily > long and exceed JVM_MAXPA

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

On Sat, 27 Feb 2021 05:12:25 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspaceShared.cpp line 783: >> >>> 781: char* start = buffer + strlen(buffer); >>> 782: snprintf(start, buff_len, "%s ", arg); >>> 783: } >> >> Maybe move the above function to the StringUtils class under s

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

On Fri, 26 Feb 2021 21:39:48 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains five additional

Re: RFR: 8259070: Add jcmd option to dump CDS [v3]

On Wed, 10 Mar 2021 04:18:29 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix white space in CDS.java > > src/hotspot/share/services/diagnosticCommand.cpp line 1124: >

Re: RFR: 8259070: Add jcmd option to dump CDS [v4]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v3]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS [v2]

dump, user can dump multiple > times against same process. >The file name is optional, if the file name is not supplied, the file name > will take format of `java_pid_static.jsa` or > `java_pid_dynamic.jsa` for static and dynamic respectively. The > `` is the application

Re: RFR: 8259070: Add jcmd option to dump CDS

On Fri, 26 Feb 2021 22:05:06 GMT, Calvin Cheung wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. >> Before this change, user has to dump shared archive in two steps: first run >> application with >> `java -XX:DumpLoadedClassList=

Integrated: 8262157: LingeredApp.startAppExactJvmOpts does not print app output when launching fails

On Mon, 22 Feb 2021 22:26:50 GMT, Yumin Qi wrote: > Hi, Please review > > When debugging for other test case which uses jcmd to attach LingeredApp > process, found there is no error information logged when the app started with > function 'startAppExactJvmOpts' exits

Re: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app output when launching fails [v3]

hich uses the function startAppExactJvmOpts to create LingeredApp, also the > test case in debugging, which indeed captured the error message upon start > error. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app output when launching fails [v2]

hich uses the function startAppExactJvmOpts to create LingeredApp, also the > test case in debugging, which indeed captured the error message upon start > error. > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last

Re: RFR: 8262157: LingeredApp.startAppExactJvmOpts does not print app output when launching fails

On Tue, 23 Feb 2021 03:43:41 GMT, Chris Plummer wrote: >> It seems error prone to have to call finishApp() manually in order to see >> the error log. Since LingeredApp.startApp calls finishApp() on exceptions, >> shouldn't startAppExactJvmOpts do the same thing? > > Although you have a point, y

Re: CSR: 8259798: Add jcmd option to dump CDS

, will send codereview after the problems fixed. Thanks Yumin On 1/14/21 12:03 PM, Yumin Qi wrote: Hi, All   I have created bug and CSR for this issue and wish have your comments on it:   BUG: https://bugs.openjdk.java.net/browse/JDK-8259070   CSR: https://bugs.openjdk.java.net/browse/JDK

Fwd: CSR: 8259798: Add jcmd option to dump CDS

Oops, push send too soon. Thanks Yumin Forwarded Message Subject:CSR: 8259798: Add jcmd option to dump CDS Date: Thu, 14 Jan 2021 12:03:38 -0800 From: Yumin Qi To: hotspot-runtime-...@openjdk.java.net Hi, All   I have created bug and CSR for this issue

Re: RFR: 8257726: Make -XX:+StressLdcRewrite option a diagnostic option

On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote: > See bug for details. Tested: > > $ java -XX:+StressLdcRewrite -version > Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via > -XX:+UnlockDiagnosticVMOptions. > Error: The unlock option must precede 'StressLdcRe

Re: RFR(T) 8203005: The top-of-stack type specified for nofast_* bytecodes are wrong

Thanks Dan for the review! On 6/25/20 12:17 PM, Daniel D. Daugherty wrote: On 6/25/20 1:33 PM, Yumin Qi wrote: Hi, please review the tiny changes for bug: https://bugs.openjdk.java.net/browse/JDK-8203005 webrev:http://cr.openjdk.java.net/~minqi/2020/8203005/webrev-00/ src/hotspot/share

Re: RFR(T) 8203005: The top-of-stack type specified for nofast_* bytecodes are wrong

://bugs.openjdk.java.net/browse/JDK-8174995 has this same bug. What do you think? thanks, Chris On 6/25/20 10:33 AM, Yumin Qi wrote: Hi, please review the tiny changes for bug: https://bugs.openjdk.java.net/browse/JDK-8203005 webrev:http://cr.openjdk.java.net/~minqi/2020/8203005/webrev-00/ Summary

RFR(T) 8203005: The top-of-stack type specified for nofast_* bytecodes are wrong

Hi, please review the tiny changes for bug: https://bugs.openjdk.java.net/browse/JDK-8203005 webrev:http://cr.openjdk.java.net/~minqi/2020/8203005/webrev-00/ Summary: The change was left by 8074345(https://bugs.openjdk.java.net/browse/JDK-8074345), the types were wrongly put as T_ILLEGAL for

Re: RFR(S) 8246019 PerfClassTraceTime slows down VM start-up

  product(bool, UsePerfData, true,  \   "Flag to disable jvmstat instrumentation for performance testing "\   "and problem isolation purposes") \ The flag default value set to true --- should we change tha

Re: RFR(T): 8247495: ProblemList vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java

Hi, Dan   Looks good to me and it is trivial. Thanks Yumin On 6/12/20 11:40 AM, Daniel D. Daugherty wrote: Tap, tap, tap... is this thing working? Anyone out there? This is a trivial 1-liner review... Dan On 6/12/20 12:46 PM, Daniel D. Daugherty wrote: Greetings, It's time to reduce th

Re: (S) 8237750: Load libzip.so only if necessary

eclaration. It probably doesn't matter, but we usually add 'inline' to the declaration of functions that appear in xxx_inline.hpp files. Thanks - Ioi On 5/5/20 1:32 PM, Yumin Qi wrote: Hi, Ioi and Calvin   There is an file classLoader.inline.hpp which also in

Re: (S) 8237750: Load libzip.so only if necessary

he hpp to this (to reduce unnecessary header file dependencies)   inline static void load_zip_library_if_needed(); and then move the implementation to the classLoader.cpp file. You also need to add include "runtime/atomic.hpp" to classLoader.cpp. Thanks - Ioi On 5/4/20 4:40 PM,

Re: (S) 8237750: Load libzip.so only if necessary

reshing.com/20130922/acquire-and-release-fences/ Thanks - Ioi On 5/1/20 8:00 PM, Yumin Qi wrote: Dean,   I have updated to use MutexLocker instead at same link: http://cr.openjdk.java.net/~minqi/8237750/webrev-01/   Tested locally, passed jtreg/runtime. Thanks Yumin On 5/1/20 4:24 PM

Re: (S) 8237750: Load libzip.so only if necessary

42 PM, Yumin Qi wrote: Hi, Dean   Thanks for the review. I will try MutextLocker, for AOT, I think currently the tests are not using CDS then it will load classes from stream, that will use libzip's Crc32.   I will check for AOT to see if it really loads libzip with the patch. For test co

Re: (S) 8237750: Load libzip.so only if necessary

th CDS. Thanks Yumin On 5/1/20 2:11 PM, Dean Long wrote: It looks like Zip_lock could be a MutexLocker instead of a MonitorLocker. dl On 5/1/20 10:24 AM, Yumin Qi wrote: Hi, please review: bug 8237750: https://bugs.openjdk.java.net/browse/JDK-8237750 webrev: http://cr.openjdk.java.net/~minqi/82

(S) 8237750: Load libzip.so only if necessary

Hi, please review: bug 8237750: https://bugs.openjdk.java.net/browse/JDK-8237750 webrev: http://cr.openjdk.java.net/~minqi/8237750/webrev-01/ Summary:   zip library is loaded unconditionally at start up but it is only needed when   1) bootclasspath contains zip or   2) UseAOT enabled or   3) Ver

Re: RFR (XS) 8215495: Always set isCopy

Looks good to me. Thanks Yumin On Wed, Dec 19, 2018 at 7:42 AM JC Beyler wrote: > Hi all, > > Could I get a second review for this please? :) > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8215495/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215495 > > Thanks! > Jc > > On Mon,

Re: RFR: JDK-8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC

Jini, Looks good. One minor comment: + public void printG1HeapSummary(G1CollectedHeap heap) {+ G1CollectedHeap g1h = (G1CollectedHeap) heap; 'heap' has been cast to 'G1CollectedHeap' at call site, so seems no need to convert here again. Thanks Yumin On Mon, Mar 12, 2018 at 8:52 AM, Jini

Re: RFR: 8130115: REDO - Reduce Symbol::_identity_hash to 2 bytes

d 64-bit, and all OSes). Thanks - Ioi On 7/15/15 10:37 AM, Yumin Qi wrote: Hi, This is redo for bug 8087143, in that push, it caused failure on Serviceability Agent failed to get type for "_identity_hash": mistakenly used JShortField for it, but in fact it still is CIntegerFiel

RFR: 8130115: REDO - Reduce Symbol::_identity_hash to 2 bytes

Hi, This is redo for bug 8087143, in that push, it caused failure on Serviceability Agent failed to get type for "_identity_hash": mistakenly used JShortField for it, but in fact it still is CIntegerField. In this change, besides of the original change in hotspot/src, I add code to calculat

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Jiangli, Two minor suggestions (did not pay attention in first round, anyway, no harm): 1) CompactHashtable.java: 58 private static long uintxSize; I did not find the usage of this var, please remove it. 2) + anyway. Searches the regular symbol table and the shared symbol +

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

Looks good to me. Not a 'R'eviwer. Thanks Yumin On 1/29/2015 5:46 PM, Jiangli Zhou wrote: Hi Serguei, Thanks for noticing that. It’s actually a duplicated bug ID for the same issue. I just fixed the web rev: http://cr.openjdk.java.net/~jiangli/8071962/webrev.00/. Thanks, Jiangli On Jan 29,

Re: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error

I'm not a "R"eviewer, so you still need one. (Forgot to mention in my reply email). Thanks Yumin On 1/14/2015 8:33 AM, Jiangli Zhou wrote: Hi Yumin, Thanks for the review! Will fix the copyright. Thanks, Jiangli On 01/13/2015 07:56 PM, Yumin Qi wrote: Looks good to me. C

Re: RFR 8067982: some jcmd /gc/heap_dump tests failed: hprof output contains warning or error

Looks good to me. Could you update the copyright year? Thanks Yumin On 1/13/2015 4:50 PM, Jiangli Zhou wrote: Hi, Please review the fix for JDK-8067982 (Some jcmd /gc/heap_dump tests failed: hprof output contains warning or error). The jcmd

Re: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError

s the exception. Though I'm unclear how it still reports "main" as the name when it has now become "DestroyJavaVM" David On 18/10/2014 3:08 PM, Yumin Qi wrote: David, (cc Karen) I think I got why it throws CircularityError in 'main' thread. The CircularityEr

Re: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError

at java.lang.Shutdown.(Shutdown.java:61) Presumably this static initialization is what triggers the involvement of the agent to do the transform, and hence encounters the exception. Though I'm unclear how it still reports "main" as the name when it has now become "Destroy

Re: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError

nstrument.InstrumentationImpl.transform(InstrumentationImpl.java:428) at java.lang.Shutdown.(Shutdown.java:61) This output in On 10/15/2014 9:58 AM, Yumin Qi wrote: David, I will take another detail trace to see where the exception begins in main thread, it should not thrown in m

Re: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError

failed not cause exception output, not caught), the main thread got the exception. That is not right. Thanks Yumin On 10/14/2014 5:28 PM, David Holmes wrote: Hi Yumin, On 15/10/2014 4:40 AM, Yumin Qi wrote: David, Thanks for the comment. See embedded. On 10/13/2014 7:30 PM, David Holmes

Re: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError

I have to make a correction: DestroyJavaVM thread will not load TestClass2 so no CircularityError happened with it. When it is created and run, the loading of TestClass2 already finished. On 10/14/2014 11:40 AM, Yumin Qi wrote: David, Thanks for the comment. See embedded. On 10/13/2014 7:30

Re: RFR: 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError

David, Thanks for the comment. See embedded. On 10/13/2014 7:30 PM, David Holmes wrote: Hi Yumin, jdk9-dev is not the best place for code review requests. serviceability-dev would be better for this test. On 14/10/2014 8:58 AM, Yumin Qi wrote: bug: https://bugs.openjdk.java.net/browse

Re: JDK-7090324: gclog rotation via external tool

M, Yasumasa Suenaga wrote: Hi Yumin, Thank you for comments. I've updated webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.06/ Could you review this? Thanks, Yasumasa On 03/04/2014 03:29 PM, Yumin Qi wrote: Yasumasa, Seems no comments for this email so far. I have so

Re: JDK-7090324: gclog rotation via external tool

Yasumasa, Seems no comments for this email so far. I have some comments of the changes: 1) arguments.cpp: a) line 1896 & 1897, please merge these two lines into one, the length will not exceeds longest lines in this file. b) line 1898 - 1990, move line back 4 spaces, in hotspot we

Re: JDK-7090324: gclog rotation via external tool

Yasumasa, I can sponsor this for you --- will start from next week. Thanks Yumin On 1/24/2014 5:50 AM, Yasumasa Suenaga wrote: Hi all, I've created webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-7090324/webrev.00/ This patch works fine on current jdk9/hs-rt . Could you review this? I am

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: cdf20166ec45 Author:minqi Date: 2013-11-13 16:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cdf20166ec45 8025632: Remove all references to MagicLambdaImpl from Hotspot Summary: MagicLambdaImpl was removed from jdk side, this should be done in vm sid

Re: RR(S): JDK-8005810: SA: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data

I think in SA, the command 'vmstructsdump' will trigger your code? Thanks Yumin On 10/9/2013 1:59 PM, Dmitry Samersoff wrote: Staffan, I don't have specific test, but I rebuild vm testbase with -parameters and then run nsk.sajdi. -Dmitry On 2013-10-09 22:04, Staffan Larsen wrote: Dmitry,

Re: Fwd: RR:(M): JDK-8025250 Sync linux and bsd versions of ps_core file

Hi, Dmitry Changes looks good. A minor comment for comment: agent/src/os/bsd/ps_core.c:233 Please remove the trailing "For" agent/src/os/linux/ps_core.c:232 Please remove the trailing "For" Thanks Yumin On 9/25/2013 12:14 AM, Dmitry Samersoff wrote: Yumin, Could you take a loo

Re: RR(S): JDK-8022616 u4 should not be used as a type for thread_id

Looks good. On 9/24/2013 12:20 PM, Dmitry Samersoff wrote: Staffan and Yumin, Thank you for feedback. Fixed (in place, please press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8022616/webrev.02/ -Dmitry On 2013-09-24 11:57, Dmitry Samersoff wrote: Please review changes: http:

Re: RR(S): JDK-8022616 u4 should not be used as a type for thread_id

Dmitry, Looks good. Minor comments: os_bsd.cpp: + #elif __APPLE__ //XNU kernel + // despite the fact mach port is actually not a thread id use it + // instead of syscall(SYS_thread_selfid) as it certenly fit to u4 Is it a typo for 'certainly' here? certenly => certainly fit => fits Tha

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: 621eda7235d2 Author:minqi Date: 2013-09-16 15:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/621eda7235d2 7164841: Improvements to the GC log file rotation Summary: made changes to easily identify current log file in rotation. Parameterize the input

Re: RFR: 7164841: Improvements to the GC log file rotation

e rotation and continue with the current file if you can't open the next file, thank you. That turned rotation off --- if the current file can grow, it will grow, just like no rotation case; if it can not grow, VM may or may not continue which depends on what happens. Thanks Yumin Thank

Re: RFR: 7164841: Improvements to the GC log file rotation

:. Others are basically same. Please take a look and comment. http://cr.openjdk.java.net/~minqi/7164841/webrev02 <http://cr.openjdk.java.net/%7Eminqi/7164841/webrev02> Thanks Yumin On 8/27/2013 10:13 AM, Tao Mao wrote: On 8/27/13 1:01 AM, Bengt Rutisson wrote: Yumin, On 8/26/13 7:01 PM, Yu

Re: RFR: 7164841: Improvements to the GC log file rotation

Hi, Bernd On 8/27/2013 10:27 AM, Bernd Eckenfels wrote: Hello, no matter what you decide (for example configurable pattern like J9 is doing it) please add enough header informatiomn to the logfile that it answers common gc diagnostic questions (version, command line settings, ram/swap size)

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: 7e7dd25666da Author:ccheung Date: 2013-08-26 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7e7dd25666da 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error Summary: removed offending EXCEPTION_MARK calls and code cleanup R

Re: RFR: 7164841: Improvements to the GC log file rotation

wide audience, especially sustaining, they have more experience with customer request. Thanks Yumin On 8/26/2013 4:47 AM, Bengt Rutisson wrote: Hi Yumin and Tao, I have not reviewed the code change but I have a comment inlined below. On 8/24/13 1:05 AM, Yumin Qi wrote: Tao, Thanks for

Re: RFR (XS) 8023406 - [windows] build_vm_def.sh takes too long even when BUILD_WIN_SA != 1

Ioi, One question, SKIP_GENERATED, is this a environment variable or need to give on command? Others looks OK. Thanks Yumin On 8/20/2013 2:11 PM, Ioi Lam wrote: |Please review a very small fix:|| || ||http://cr.openjdk.java.net/~iklam/8023406/windows_build_vm_def_slow_001/|| || ||Bug: m

hg: hsx/hotspot-rt/hotspot: 8023188: Unsafe volatile double store on bsd is broken

Changeset: b1fd869e7df0 Author:minqi Date: 2013-08-19 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b1fd869e7df0 8023188: Unsafe volatile double store on bsd is broken Reviewed-by: dcubed, dholmes Contributed-by: yumin...@oracle.com ! src/os_cpu/bsd_x86/vm/

Re: RFR: 8020962: dump loaded java classes when vm crash

d to replay compilations. Also a customer may not want their classes disclosed in error reporting. They don't have to if they don't want to. -- Chris 3. This doesn't seem important enough to include as a new feature in jdk8 release, which is feature-complete. I don't see a

Re: RFR: 8020962: dump loaded java classes when vm crash

which is feature-complete. I don't see a customer request for it. Coleen On 08/12/2013 01:00 PM, Yumin Qi wrote: Chris, David Yes. This can be after crash with core file, but some time no core file generated (also if the error could not repeat, we will never got information again), s

Re: RFR: 8020962: dump loaded java classes when vm crash

Ioi, Thanks for the reminding, it is possible. I will use env instead. Yumin On 8/12/2013 11:00 AM, Ioi Lam wrote: On 08/12/2013 10:00 AM, Yumin Qi wrote: - What if it the SA also crashes, will it launch a third VM then a fourth etc? Definitely don't want to see this happened

Re: RFR: 8020962: dump loaded java classes when vm crash

mpiler-dev-boun...@openjdk.java.net [mailto:hotspot-compiler-dev-boun...@openjdk.java.net] On Behalf Of David Holmes Sent: Monday, August 12, 2013 1:56 AM To: Yumin Qi Cc: hotspot compiler; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR: 8020962: dump loaded java classes when vm crash Hi Yumin

Re: RFR: 8020962: dump loaded java classes when vm crash

Sorry forgot to include svc. Yumin On 8/11/2013 4:36 PM, Yumin Qi wrote: Hi, all I would like to have your review for http://cr.openjdk.java.net/~minqi/8020962/webrev0/ <http://cr.openjdk.java.net/%7Eminqi/8020962/webrev0/> Description: When JVM crashed, we also want to che

Re: RR(S): 8022655: ClassDump ignored jarStream setting

those tests now on Solaris, I found coreadm settings may mean they don't find the core: putting a coreadm command in the test means we should find JTwork/scratch/core Thanks Kevin On 08/08/2013 19:25, Yumin Qi wrote: Kevin, https://jbs.oracle.com/bugs/browse/JDK-8022655 I assigned t

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: 57ac7245594c Author:minqi Date: 2013-08-08 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/57ac7245594c 8019583: [TESTBUG] runtime/7107135 always passes Summary: If java test return none zero, the value will be override by 'if' statement, the exit

Re: About bug fix of 8010278

l test and let you know... Thanks! Kevin On 26/07/13 02:17, Yumin Qi wrote: Hi, Kevin http://cr.openjdk.java.net/~kevinw/8010278/webrev.03/ <http://cr.openjdk.java.net/%7Ekevinw/8010278/webrev.03/> I found this fix breaks C2 replay for dumping loaded java clas

hg: hsx/hotspot-rt/hotspot: 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases

Changeset: f9ee986a9fea Author:ccheung Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/f9ee986a9fea 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases Summary: Added checking for gcc and simplifi

Re: RFR(S): 8021444: SA: ClassDump.run() should not ignore existing ClassFilter.

as it calls sun.jvm.hotspot.CLHSDB, and gives the javascript exceptions characteristic of 8011888. Rebuilding with the suggested new sa.js I see in that bug, I'll test and let you know... Thanks! Kevin On 26/07/13 02:17, Yumin Qi wrote: Hi, Kevin http://cr.openjdk.java.net/~kevinw/8010

About bug fix of 8010278

Hi, Kevin http://cr.openjdk.java.net/~kevinw/8010278/webrev.03/ I found this fix breaks C2 replay for dumping loaded java classes: at sun.jvm.hotspot.tools.jcore.PackageNameFilter.canInclude(PackageNameFilter.java:55)

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: 1b6395189726 Author:minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need expli

hg: hsx/hotspot-rt/hotspot: 3 new changesets

Changeset: 72727c4b6dec Author:ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh scr

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: 4614a598dae1 Author:minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volati

hg: hsx/hotspot-rt/hotspot: 2 new changesets

Changeset: 02d7aa1456c9 Author:ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCa

  1   2   >