Re: RFR 8230303 : JDB hangs when running monitor command

Thank you Serguei for review! On 9/9/19 9:14 PM, serguei.spit...@oracle.com wrote: Hi Ivan, Thank you for filing the shadow bug and fixing this issue! I've targeted the bug to 14 (please, fix me if it is wrong). Yes, this is correct, thanks. The fix looks good to me. Do you have any plans

RFR 8230303 : JDB hangs when running monitor command

ch includes the new test and other jdb related tests. Would you please help review? Thanks in advance! -- With kind regards, Ivan Gerasimov

Re: RFR 8160892: VM warning: WaitForMultipleObjects timed out

Hey! I've updated the webrev in place at http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ On 15.07.2016 0:31, Daniel D. Daugherty wrote: On 7/14/16 12:46 PM, Ivan Gerasimov wrote: Thank you David for looking into this! Here's the webrev updated in accordance with your an

Re: RFR 8160892: VM warning: WaitForMultipleObjects timed out

Thank you David for looking into this! Here's the webrev updated in accordance with your and Daniel's suggestions: http://cr.openjdk.java.net/~igerasim/8160892/01/webrev/ Please see my answers inline Nit: can we change 'registered_itself" to just "registered" please. Done. Can you explain

Re: RFR 8160892: VM warning: WaitForMultipleObjects timed out

Thanks Daniel! I'll rearrange comments as you suggest. With kind regards, Ivan On 07.07.2016 0:21, Daniel D. Daugherty wrote: On 7/6/16 10:57 AM, Ivan Gerasimov wrote: Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and regi

RFR 8160892: VM warning: WaitForMultipleObjects timed out

Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and registers itself, 2) Thread B wants to call exit(), takes its turn and raises the flag `process_exiting`, 3) Thread A continues, and gets captured in the loop at 4020, in SuspendThread(G

RFR 8160892: VM warning: WaitForMultipleObjects timed out

Hello! When fixing JDK-8069048 a potential race was overlooked: 1) Thread A wants to call _endthreadex() and registers itself, 2) Thread B wants to call exit(), takes its turn and raises the flag `process_exiting`, 3) Thread A continues, and gets captured in the loop at 4020, in SuspendThread(G

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

or _endthreadex() The comment on L4033-4 is slightly misplaced now. It should be between L4031 and L4032. Thumbs up modulo the GetCurrentThreadId() return size question above. If that size is OK and you choose to make the comment changes, I don't need to see another webr

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

Thank you David for review! Sincerely yours, Ivan On 23.12.2015 7:41, David Holmes wrote: Looks okay. Second review needed though. Thanks, David On 19/12/2015 10:28 PM, Ivan Gerasimov wrote: We will suspend the current thread if two conditions are satisfied: process_exiting != 0 and

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

We will suspend the current thread if two conditions are satisfied: process_exiting != 0 and process_exiting != current thread id. But, yes, pr_ex isn't really needed, as we can use process_exiting directly. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8145127/01/webrev/ I

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

On 17.12.2015 8:45, David Holmes wrote: On 15/12/2015 10:18 PM, Ivan Gerasimov wrote: while(true) would convey that much more clearly - and perhaps obviate the need for pr_ex. Yes, I can surely transform the code - while (pr_ex != curr_id) { + if (pr_ex != curr_id

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

while(true) would convey that much more clearly - and perhaps obviate the need for pr_ex. Yes, I can surely transform the code - while (pr_ex != curr_id) { + if (pr_ex != curr_id) { + while (true} { The intention was to save a line :-) I'll use while (true), if it imp

Re: RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

eturn code replacement for sure. On 15/12/2015 12:09 AM, Ivan Gerasimov wrote: Hello! There was a timeout observed in os_windows.cpp at the line 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, handles, FALSE, EXIT_TIMEOUT); This means there were more than 64 threads exiting at the

RFR 8145127: VM warning: WaitForMultipleObjects timed out (0) ...

Hello! There was a timeout observed in os_windows.cpp at the line 3945 res = WaitForMultipleObjects(MAXIMUM_WAIT_OBJECTS, handles, FALSE, EXIT_TIMEOUT); This means there were more than 64 threads exiting at the same time and none of the first 64 threads could make any progress durin

Re: RFR (XXS) 8069068: VM warning: WaitForMultipleObjects timed out (0) ...

On 20.05.2015 18:19, Daniel D. Daugherty wrote: On 5/20/15 7:57 AM, Ivan Gerasimov wrote: On 20.05.2015 10:04, David Holmes wrote: Hi Ivan, On 20/05/2015 9:54 AM, Ivan Gerasimov wrote: Hello! Since the beginning of the year a warning about an expired timeout has been seen a few times

Re: RFR (XXS) 8069068: VM warning: WaitForMultipleObjects timed out (0) ...

On 20.05.2015 10:04, David Holmes wrote: Hi Ivan, On 20/05/2015 9:54 AM, Ivan Gerasimov wrote: Hello! Since the beginning of the year a warning about an expired timeout has been seen a few times. It is most likely to observe this under a heavy load, when many threads are exiting. The

RFR (XXS) 8069068: VM warning: WaitForMultipleObjects timed out (0) ...

Hello! Since the beginning of the year a warning about an expired timeout has been seen a few times. It is most likely to observe this under a heavy load, when many threads are exiting. The propose is to increase the timeout. The rationale is that if an application needs more time for the thr

Re: RFR 8069048: (process) Suspend finishing threads when process exits [win]

Thank you Daniel for your review! On 16.01.2015 3:01, Daniel D. Daugherty wrote: On 1/15/15 5:09 AM, Ivan Gerasimov wrote: Hello everyone! This is yet another iteration in the attempt to solve the 'wrong exit code' bug on Windows [1]. The wrong exit code has been observed once agai

RFR 8069048: (process) Suspend finishing threads when process exits [win]

Hello everyone! This is yet another iteration in the attempt to solve the 'wrong exit code' bug on Windows [1]. The wrong exit code has been observed once again with one of the regression tests. The suspicion is that this might be due to the critical section had been destroyed before all the

Re: Change "8057744: (process) Synchronize exiting of threads and process [win]" breaks HotSpot on Win Server 2003

ations. If there are no special reasons for keeping it closed, can you please make it visible to everybody. Thank you and best regards, Volker On Sun, Sep 7, 2014 at 8:07 AM, Ivan Gerasimov wrote: Hello! This is a proposal to address issue with wrong exit codes from a Java processes on Windows. I

Re: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects

On 11.12.2014 19:05, Daniel D. Daugherty wrote: On 12/11/14 3:01 AM, David Holmes wrote: On 11/12/2014 7:48 PM, David Holmes wrote: Hi Ivan, On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: Hello! After the fix for JDK-8064694 some more failures of WaitForMultipleObjects() were observed under

Re: RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects

On 11.12.2014 13:01, David Holmes wrote: On 11/12/2014 7:48 PM, David Holmes wrote: Hi Ivan, On 11/12/2014 4:52 PM, Ivan Gerasimov wrote: Hello! After the fix for JDK-8064694 some more failures of WaitForMultipleObjects() were observed under heavy load. The reason was that the limitation on

RFR 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects

Hello! After the fix for JDK-8064694 some more failures of WaitForMultipleObjects() were observed under heavy load. The reason was that the limitation on wait object number was overlooked. The total number of the objects should not be greater than MAXIMUM_WAIT_OBJECTS (= 64). The proposed fi

Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844

iel D. Daugherty wrote: > http://cr.openjdk.java.net/~igerasim/8064694/2/webrev/ src/os/windows/vm/os_windows.cpp No commments. Thumbs up. Dan On 11/18/14 12:29 AM, Ivan Gerasimov wrote: Hi Markus! The priority of the exiting thread will be raised for quite a short period of time -- righ

Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844

mplish the results without manipulating base services? Thanks Markus -Original Message- From: David Holmes Sent: den 17 november 2014 07:40 To: Ivan Gerasimov; Daniel Daugherty Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-dev Subject: Re: RFR 8064694: Kitchensink: WaitForMultipleObje

Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844

Thanks David! On 17.11.2014 9:40, David Holmes wrote: On 17/11/2014 7:23 AM, Ivan Gerasimov wrote: Thank you Daniel! Please find the updated webrev with your suggestions incorporated here: http://cr.openjdk.java.net/~igerasim/8064694/1/webrev/ Concerning the thread priority: If the

Re: RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844

herty wrote: On 11/14/14 5:35 AM, Ivan Gerasimov wrote: Hello! The recent fix for JDK-8059533 ((process) Make exiting process wait for exiting threads [win]) caused the warning message to be printed in some test environments: --- os_windows.cpp:3844 is in the newly updated os::

RFR 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844

Hello! The recent fix for JDK-8059533 ((process) Make exiting process wait for exiting threads [win]) caused the warning message to be printed in some test environments: --- os_windows.cpp:3844 is in the newly updated os::win32::exit_process_or_thread(Ept what, int exit_code) ---

RFR 8062647: Wrong indentation of arguments of annotated methods

Hello everybody! I noticed that the javadoc tool may produce the doc with misaligned arguments of annotated methods in the 'method details' section. For example: http://jre.us.oracle.com/java/re/jdk/9/nightly/latest/docs/api/java/util/EnumSet.html#of-E-E...- Would you please help review the fi

Re: RFR 8059533: (process) Make exiting process wait for exiting threads [win]

On 29.10.2014 13:15, David Holmes wrote: Great improvement thanks! One further suggestion - after line 3731 add a short overview eg: // Basic approach: // - Each exiting thread registers its intent to exit and then does so. // - A thread trying to terminate the process must wait for all //

Re: RFR 8059533: (process) Make exiting process wait for exiting threads [win]

f synchronized code (I've checked that abandoning the mutex owned by an exiting thread normally happens before WaitFor(... exiting thread...) returns). Thus, if the race had happened during this time window, it should be eliminated now. Sincerely yours, Ivan Thanks, David On 27/10/2014 6:35

Re: RFR 8059533: (process) Make exiting process wait for exiting threads [win]

On 27.10.2014 3:36, David Holmes wrote: On 27/10/2014 1:15 AM, Ivan Gerasimov wrote: David, would you approve this fix? Sorry Ivan I'm having trouble following the logic this time - could you add some comments about what we are checking at each step. Yes, sure. The main idea is to

Re: RFR 8059533: (process) Make exiting process wait for exiting threads [win]

David, would you approve this fix? Sincerely yours, Ivan On 26.10.2014 19:01, Daniel D. Daugherty wrote: On 10/25/14 12:23 PM, Ivan Gerasimov wrote: On 25.10.2014 3:06, Daniel D. Daugherty wrote: On 10/1/14 3:07 AM, Ivan Gerasimov wrote: Hello! The tests that continue to fail with wrong

Re: RFR 8059533: (process) Make exiting process wait for exiting threads [win]

On 25.10.2014 3:06, Daniel D. Daugherty wrote: On 10/1/14 3:07 AM, Ivan Gerasimov wrote: Hello! The tests that continue to fail with wrong exit codes suggest that the fix for JDK-8057744 wasn't sufficient. Here's another proposal, which expands the synchronized portion of the c

RFR 8059533: (process) Make exiting process wait for exiting threads [win]

Hello! The tests that continue to fail with wrong exit codes suggest that the fix for JDK-8057744 wasn't sufficient. Here's another proposal, which expands the synchronized portion of the code. It is proposed to make the exiting process wait for the threads that have already started exiting. T

Re: RFR [8057744] (process) Synchronize exiting of threads and process [win]

On 08.09.2014 17:31, Daniel D. Daugherty wrote: Ivan, I'll sponsor the change, but I want to push it after this week's RT_Baseline snapshot. We snapshot on Tuesday (2014.09.09 at 1900 PT) and if the nightly test results look reasonable Wednesday morning, then I'll push it on Wednesday. Does th

Re: RFR [8057744] (process) Synchronize exiting of threads and process [win]

Thanks Daniel and David! I'll need a sponsor to help me push the change. Sincerely yours, Ivan On 08.09.2014 6:03, David Holmes wrote: Hi Ivan, On 7/09/2014 4:07 PM, Ivan Gerasimov wrote: Hello! This is a proposal to address issue with wrong exit codes from a Java processes on Window

RFR [8057744] (process) Synchronize exiting of threads and process [win]

Hello! This is a proposal to address issue with wrong exit codes from a Java processes on Windows. In order to avoid a race, calls to _endthread(), exit and _exit() are explicitly synchronized. We allow simultaneous calls to _endthread() by multiple threads. However, at the time exit() or _exi

Re: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

On 20 aug 2014, at 21:36, Ivan Gerasimov wrote: Hello everyone! Here's the third version of the webrev: http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ The control build of the previous one was causing a lot of test failures. This one seems to be innocent enough: no new test failu

Re: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

Hello everyone! Here's the third version of the webrev: http://cr.openjdk.java.net/~igerasim/8055338/2/webrev/ The control build of the previous one was causing a lot of test failures. This one seems to be innocent enough: no new test failures so far. Additionally, this version keeps the timing

Re: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

14-08-18 23:19 GMT+02:00 Ivan Gerasimov : Hello! This is a request to temporarily add some instrumentation code to hotspot to help diagnose the intermittent failure on Windows, which results in a wrong exit code of (sub-)process. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 WEBREV:

Re: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

David - Ioi On 8/18/14, 2:19 PM, Ivan Gerasimov wrote: Hello! This is a request to temporarily add some instrumentation code to hotspot to help diagnose the intermittent failure on Windows, which results in a wrong exit code of (sub-)process. BUGURL: https://bugs.openjdk.java.net/browse/JDK-

Re: RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

ull and skip the check for java_thread being null? Neither thread nor java_thread can be NULL. Yes, I'll remove this unnecessary check. Sincerely yours, Ivan Just comments from the peanut gallery. ;) Ditto :) David H. -kto On Aug 18, 2014, at 3:14 PM, Daniel D. Daugherty wr

RFR [8055338]: (process) Add instrumentation to help diagnose JDK-6573254

Hello! This is a request to temporarily add some instrumentation code to hotspot to help diagnose the intermittent failure on Windows, which results in a wrong exit code of (sub-)process. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055338 WEBREV: http://cr.openjdk.java.net/~igerasim/805

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

src/share/classes/sun/misc/UUDecoder.java 126 StringBuilder x = new StringBuilder(); Is only filled, but doesn't seem to be used anyhow. Maybe just delete it? Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: Hi, This is a request for review of Otavio's patch replacing

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

Wouldn't it be a little bit more efficient to replace a string concatenation with yet another StringBuilder operation? src/share/classes/com/sun/java/util/jar/pack/BandStructure.java 631 StringBuilder sb = new StringBuilder(); ... 636 Utils.log.fine(" meta-c

Re: RFR: [8040790] TEST_BUG: tools/javac/innerClassFile/Driver.sh fails to cleanup files after it

le.com <mailto:lance.ander...@oracle.com> Sent from my iPad On Apr 29, 2014, at 4:48 AM, Ivan Gerasimov <mailto:ivan.gerasi...@oracle.com>> wrote: Hello! This is a 7u-only test-stabilization one-line fix. The test was reported to not clean after itself, which sometimes causes problem

RFR: [8040790] TEST_BUG: tools/javac/innerClassFile/Driver.sh fails to cleanup files after it

Hello! This is a 7u-only test-stabilization one-line fix. The test was reported to not clean after itself, which sometimes causes problems. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040790 WEBREV: http://cr.openjdk.java.net/~igerasim/8040790/0/we

Re: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework

istent with other else clauses in these files. Shouldn't it be places on the same line? Personally, I would prefer throw new AttachOperationFailedException(message != null ?message : "Command failed in target VM"); Sincerely yours, Ivan /Staffan On 11 apr 2014, at 09:32, Ivan Ger

Re: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework

ither). So the "keep it simple” principle here would be to remove the cap (which also makes the code in getErrorMessage() simpler). If someone has a better solution for propagating error messages from the operations, I’m all ears. Thanks, /Staffan On 4 apr 2014, at 14:41, Ivan Gerasi

Re: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework

off += n; return (off == 0) ? null : (off < len) ? new String(b, 0, off, "UTF-8") : new String(b, 0, maxlen, "UTF-8") + " ..."; } Not a big deal, of course. Sincerely yours, Ivan

Re: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework

uot;UTF-8"); } -if (off > b.length && message != null) { +if (!complete && message != null) { message += " ..."; } return message; On 4 apr 2014, at 13:55, Ivan Gerasimov wrote: Thank you Staffan for fix

Re: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework

p;& message != null) { +if (off > b.length && message != null) { message += " ..."; } return message; On 4 apr 2014, at 11:18, Ivan Gerasimov wrote: Hi Staffan! I think there is a couple of minor bugs in getErrorMessage(InputSt

Re: RFR: 8039173 Propagate errors from Diagnostic Commands as exceptions in the attach framework

Hi Staffan! I think there is a couple of minor bugs in getErrorMessage(InputStream sis, int maxlen). 1) If maxlen is exactly the size of the message to read, the function will add an ellipsis, even though the message isn't truncated, 2) If maxlen is greater than needed, then sis.read(b, off,

RFR [8030878] JConsole issues meaningless message if SSL connection fails

rrect lines into the massage.properties file. I also renamed the constants to make their names match those in the later releases. Here's the webrev, please have a chance to review. http://cr.openjdk.java.net/~igerasim/8030878/0/webrev/ Sincerely yours, Ivan Gerasimov

Re: RFR [8030698] Several GUI labels in jconsole need corrections

Thank you Staffan! On 20.12.2013 16:07, Staffan Larsen wrote: Looks good! I assume this is targeted for jdk9 and/or 8u20? Yes, it's for 9, 8u20 and 7u(80?). Ivan Thanks for fixing this, /Staffan On 20 dec 2013, at 12:05, Ivan Gerasimov wrote: Hello! Would you please review

RFR [8030698] Several GUI labels in jconsole need corrections

esources/JConsoleResources_zh_CN.java If approved, the fix will be pushed into 9 and then be backported into 8 and 7. Sincerely yours, Ivan Gerasimov

Re: RR(XS): JDK-6969276 minor memory leak detected by cppcheck in agent/src/os/linux/symtab.c

Hi Dmitry! I think you should surround the if body with braces, or you'll get unconditional return from the function otherwise. 217 if (last_slash == NULL) 218 free(debug_pathname); 219 return -1; Should be 217 if (last_slash == NULL) { 218 free(debug_pathname); 219

Re: RFR [8025886] replace == and [[ bash extensions

Hello all! Any chance to have this simple fix approved? The proposal is to get rid of == and [[ bash extensions, as this is the only place they are used in jdk regtests and sh-shell is not happy with them. Thanks in advance, Ivan Gerasimov --- a/test/sun/management/jmxremote/bootstrap

Re: RFR [8025886] typo in shell regtest == instead of =

Thanks, Dmitry! I assume I still need an approval from the Reviewer. Sincerely yours, Ivan On 05.10.2013 21:30, Dmitry Samersoff wrote: Ivan, Looks good for me. -Dmitry On 2013-10-05 17:04, Ivan Gerasimov wrote: Dmitry, thanks for suggestion! Yes, == comparison isn't the on

Re: RFR [8025886] typo in shell regtest == instead of =

Dmitry, thanks for suggestion! Yes, == comparison isn't the only sh-incompatible thing in the script. Sh may be unhappy with [[ as well. So I replaced it with case as you suggested. Grep shows that it was the only place where [[ and == were used in regtests, so it would be good to make things co

RFR [8025886] typo in shell regtest == instead of =

Hello! May I please have a review for a simple fix of the shell regtest? Bash seems to accept both = and == comparisons, but sh accepts only =. http://bugs.sun.com/view_bug.do?bug_id=8025886 (not yet visible.) Sincerely yours, Ivan --- a/test/sun/management/jmxremote/bootstrap/GeneratePropert

Re: RFR [8014792] Need a test to check if path to java debugger has spaces

od to have, though I think it's better to set it up in the testing environment. Please let me know if I misunderstood your test. Thanks, /Staffan On 24 sep 2013, at 08:12, Ivan Gerasimov wrote: Hello all! Would you please help review a new regression test? This is related to the fix fo

RFR [8014792] Need a test to check if path to java debugger has spaces

error message. Here's the webrev: http://cr.openjdk.java.net/~igerasim/8014792/0/webrev/ Here's the bug: http://bugs.sun.com/view_bug.do?bug_id=8014792 Here's the fix for 8014676: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/81c449fd18fe Sincerely yours, Ivan Gerasimov

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

(including 32-bit Linux) the tests passed as expected, on the Linux-x64 both tests were skipped. Virtual memory growth across {fastdebug,product}-{c1,c2} targets was in range from 1188K to 2584K which is less than the chosen threshold of 32M. Sincerely yours, Ivan Gerasimov On 10.07.2013 14

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

Linux-x64 both tests were skipped. Virtual memory growth across {fastdebug,product}-{c1,c2} targets was in range from 1188K to 2584K which is less than the chosen threshold of 32M. Sincerely yours, Ivan Gerasimov On 10.07.2013 14:38, Ivan Gerasimov wrote: Yes, I forgot to include the most

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

ev/ <http://cr.openjdk.java.net/%7Eigerasim/8016838/3/webrev/> One comment - should the test be excluded for all linux variants (i.e. linux-all) ? regards, Sean. On 09/07/2013 14:09, Ivan Gerasimov wrote: Please have a chance to review an updated webrev. It now includes a change to Pro

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

Please have a chance to review an updated webrev. It now includes a change to ProblemList.txt, so both modified tests are ignored for linux-x64. Sincerely yours, Ivan Gersimov On 08.07.2013 21:27, Seán Coffey wrote: On 08/07/13 17:55, Ivan Gerasimov wrote: Thanks, Seán! I located the

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

t until the new leak is sorted out for jdk8. The goal of JPRT runs is to have clean runs. If it's on the problemList, then it's a known issue and is normally tagged with the relevant bug ID so that the responsible engineer knows the current state. regards, Sean. On 05/07/2013 11

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

new memory leak in JDK8/HSX-25? The way to deal with that is to put the test on the Problem.list as part of the same changeset. However, the T&L folks might not like that either... Well, the leak is there, and why not have a failing test as a reminder to have it fixed? Sincerely yours, I

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

ak in JDK8/HSX-25? The way to deal with that is to put the test on the Problem.list as part of the same changeset. However, the T&L folks might not like that either... Dan On 7/4/13 6:59 PM, Ivan Gerasimov wrote: Thank you, Daniel! Please find an updated webrev at http://cr.openjdk.java

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

itter? Here's a link to hg export: http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.patch Thanks in advance, Ivan On 04.07.2013 21:45, Daniel D. Daugherty wrote: On 7/4/13 11:19 AM, Ivan Gerasimov wrote: Daniel, thank you for review! Here's the updated wi

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

I make it separately? Sincerely yours, Ivan On 04.07.2013 19:34, Daniel D. Daugherty wrote: On 7/3/13 11:12 AM, Ivan Gerasimov wrote: Hello everybody! We have a request to improve jtreg test. The test had been written to verify fix for memory leak during class redefinition. The problem is that

Re: RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

be related to the class redefinition and be related to [1] instead. However the webrev is still relevant, so welcome to review! [1] http://bugs.sun.com/view_bug.do?bug_id=8003419 Sincerely yours, Ivan Gerasimov

RFR [8016838] java/lang/instrument/RedefineBigClass.sh needs modification

leak with the latest JDK8! Latest 6 and 7 are fine, so it might be regression in JDK8. I've filled a bug http://bugs.sun.com/view_bug.do?bug_id=8019845 "Memory leak during class redefenition" (not yet available.) Sincerely yours, Ivan Gerasimov

Re: RFR [8014676] Java debugger may fail to run

On 16.05.2013 12:52, Alan Bateman wrote: On 15/05/2013 22:05, Ivan Gerasimov wrote: Hello everybody! Would you please help with reviewing the fix? The fix is for jdk8. It is also applicable to jdk7 and will be proposed, if it's accepted here. WEBREV: http://cr.openjdk.java.net/

RFR [8014676] Java debugger may fail to run

Hello everybody! Would you please help with reviewing the fix? The fix is for jdk8. It is also applicable to jdk7 and will be proposed, if it's accepted here. WEBREV: http://cr.openjdk.java.net/~robm/8014676/webrev.01/ BUG: http://bugs.s