Re: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

2022-05-09 Thread Chris Plummer
On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik wrote: > …resulting in failure to produce a stack when a test times out test/failure_handler/src/share/conf/common.properties line 67: > 65: > 66: jhsdb.app=jhsdb > 67: jhsdb.jstack.live.args=jstack --mixed --pid %p What is the plan to address

Re: RFR: 8285366: Fix typos in serviceability

2022-04-21 Thread Chris Plummer
On Thu, 21 Apr 2022 16:30:42 GMT, Daniel Fuchs wrote: > > @dfuch I have only updated files in `src`, so if the incorrect spelling is > > tested, that test will now fail. I'm unfortunately not well versed in what > > tests cover serviceability code. Can you suggest a suitable set of tests to >

Re: RFR: 8284853: Fix varios 'expected' typo

2022-04-13 Thread Chris Plummer
On Wed, 13 Apr 2022 20:36:48 GMT, Andrey Turbanov wrote: > Found various typos of expected: `exepected`, `exept`, `epectedly`, > `expeced`, `Unexpeted`, etc. test/jdk/java/lang/StackWalker/StackStreamTest.java line 218: > 216: private static void equalsOrThrow(String label, List list, >

Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2]

2022-03-10 Thread Chris Plummer
On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > moved CurrencyNames changes to jdk.localedata

Re: RFR: 8280166: Extend java/lang/instrument/GetObjectSizeIntrinsicsTest.java test cases

2022-01-18 Thread Chris Plummer
On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote: > While working on JDK-8280003, I noticed that > java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays > with more than 1-byte size elements, and no large arrays (past 4G limit) are > tested either. It would be

RFR: 8269556: sun/tools/jhsdb/JShellHeapDumpTest.java fails with RuntimeException 'JShellToolProvider' missing from stdout/stderr

2021-12-09 Thread Chris Plummer
The test searches for "JShellToolProvider" in the main thread's stack trace, which is pulled from an SA heap dump. Typically the main thread is blocked in Object.wait(), so SA can determine its stack trace. However, the wait has a 100ms timeout, so the thread does periodically wake up and does

Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string

2021-10-27 Thread Chris Plummer
On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app > (default is 1024, 8K should be enough for any environments) Marked as reviewed by cjplummer (Reviewer). Actually revoking my review for the moment. Do we have any

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v13]

2021-10-13 Thread Chris Plummer
On Wed, 13 Oct 2021 18:53:22 GMT, Mandy Chung wrote: >> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementation uses >> `VarHandle`.For

Re: RFR: 8274523: java/lang/management/MemoryMXBean/MemoryTest.java test should handle Shenandoah

2021-09-29 Thread Chris Plummer
On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote: > Currently it fails with: > > > $ CONF=linux-x86_64-server-fastdebug make run-test > TEST=java/lang/management/MemoryMXBean/MemoryTest.java > > STDERR: > java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but >

Re: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

2021-09-29 Thread Chris Plummer
On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf wrote: > Please review this test fix to work around a podman issue[1]. `podman` > expects for the "unlimited" option of `--pids-limit` to be `0` whereas > `docker` wants `-1`. See the JBS bug for details. Thoughts? > > Testing: hotspot/jdk

Re: RFR: 8271396: Spelling errors

2021-07-28 Thread Chris Plummer
On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg wrote: > This PR fixes the following spelling errors: > > choosen -> chosen > commad -> command > hiearchy -> hierarchy > leagacy -> legacy > minium -> minimum > subsytem -> subsystem > unamed -> unnamed jdi, jvmti, and dcmd

Re: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions=

2021-04-19 Thread Chris Plummer
On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of fix that removes the use of "=" together with > -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to > use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was

Re: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions=

2021-04-19 Thread Chris Plummer
On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of fix that removes the use of "=" together with > -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to > use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was

Re: RFR: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread

2021-02-24 Thread Chris Plummer
On Thu, 25 Feb 2021 03:54:35 GMT, Chris Plummer wrote: > This a new test that runs jstack on a process that is busy doing things. It > runs jstack 4 times as the process is starting up. > Sorry but I don't see how this ensures it runs jstack as the jshell is > starting up, the s

RFR: 8262271: SA: Add new stress test that tests getting the stack trace of an active thread

2021-02-24 Thread Chris Plummer
This a new test that runs jstack on a process that is busy doing things. It runs jstack 4 times as the process is starting up. - Commit messages: - Fix @bug - Add JStackStressTest Changes: https://git.openjdk.java.net/jdk/pull/2720/files Webrev:

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Chris Plummer
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v3]

2021-01-25 Thread Chris Plummer
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote: >> Please review the implementation of JEP 391: macOS/AArch64 Port. >> >> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and >> windows/aarch64. >> >> Major changes are in: >> * src/hotspot/cpu/aarch64: support of

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6]

2020-09-24 Thread Chris Plummer
On Thu, 24 Sep 2020 14:04:22 GMT, Monica Beckwith wrote: >> This is a continuation of >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

2020-04-18 Thread Chris Plummer
Hi Mandy, Comments inline. On 4/17/20 4:52 PM, Mandy Chung wrote: On 4/17/20 3:51 PM, Chris Plummer wrote: Hi Mandy, Thanks for updating the svc specs. Some comments below: In the JDWP spec update, you changed "JNI signature" to "type signature" in one place,

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

2020-04-18 Thread Chris Plummer
On 4/17/20 9:37 PM, serguei.spit...@oracle.com wrote: On 4/17/20 16:52, Mandy Chung wrote: On 4/17/20 3:51 PM, Chris Plummer wrote: Hi Mandy, Thanks for updating the svc specs. Some comments below: In the JDWP spec update, you changed "JNI signature" to "type signatur

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

2020-04-17 Thread Chris Plummer
On 4/16/20 9:45 AM, Mandy Chung wrote: On 4/14/20 11:51 AM, Paul Sandoz wrote: Looks good to me (not familiar with all the code areas. Minor suggestion: MethodHandles.java 1811  * ASCII periods. For the instance of {@link java.lang.Class} representing {@code C}: 1812  *

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

2020-03-27 Thread Chris Plummer
Hi Mandy, A couple of very minor nits in the jvmtiRedefineClasses.cpp comments:  153 // classes for primitives, arrays, hidden and vm unsafe anonymous classes  154 // cannot be redefined.  Check here so following code can assume these classes  155 // are InstanceKlass.  156

RE: RFR JDK-8205540: hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 commands

2018-06-23 Thread Chris Plummer
Hi Peter, The changes looks good and also the test passes now. Thanks for fixing this. Chris Please review the following tiny change that delays TerminatingThreadLocal class initialization until the 1st thread that actually uses thread locals, exits:

Re: RFR(10)(XS) 8177015: STACK_SIZE_MINIMUM of 32k is not always enough for Mac OS X

2017-03-26 Thread Chris Plummer
Hi David, On 3/26/17 5:06 PM, David Holmes wrote: Hi Chris, On 25/03/2017 6:12 AM, Chris Plummer wrote: Hello, Please review changes for the following: http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8177015 Functional change seems okay

Re: RFR(10)(XS) 8177015: STACK_SIZE_MINIMUM of 32k is not always enough for Mac OS X

2017-03-24 Thread Chris Plummer
On 3/24/17 7:03 PM, Daniel D. Daugherty wrote: On 3/24/17 2:12 PM, Chris Plummer wrote: Hello, Please review changes for the following: http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/ > http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/webrev.hotspot/ test/runtime/Thr

RFR(10)(XS) 8177015: STACK_SIZE_MINIMUM of 32k is not always enough for Mac OS X

2017-03-24 Thread Chris Plummer
Hello, Please review changes for the following: http://cr.openjdk.java.net/~cjplummer/8177015/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8177015 The CR description explains the problem. I'm increasing the minimum allowed -Xss stack size from 32k to 64k. There are also a couple of

Re: RFR(XS)(10): 8175342: assert(InstanceKlass::cast(k)->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation

2017-03-17 Thread Chris Plummer
Thanks! On 3/17/17 1:14 AM, Dmitry Samersoff wrote: Chris, Looks good to me. -Dmitry On 2017-03-17 10:31, Chris Plummer wrote: I should have been more clear. I need one more "reviewer", not another review from David. thanks, Chris On 3/17/17 12:30 AM, Chris Plummer wrot

Re: RFR(XS)(10): 8175342: assert(InstanceKlass::cast(k)->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation

2017-03-17 Thread Chris Plummer
I should have been more clear. I need one more "reviewer", not another review from David. thanks, Chris On 3/17/17 12:30 AM, Chris Plummer wrote: Thanks for the review, David. I could still use one more review. Here's an updated webrev. http://cr.openjdk.java.net/~cjplummer/8175

Re: RFR(XS)(10): 8175342: assert(InstanceKlass::cast(k)->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation

2017-03-17 Thread Chris Plummer
Thanks for the review, David. I could still use one more review. Here's an updated webrev. http://cr.openjdk.java.net/~cjplummer/8175342/webrev.01/webrev.jdk cheers, Chris On 3/15/17 10:14 PM, David Holmes wrote: Hi Chris, On 16/03/2017 2:57 PM, Chris Plummer wrote: Hello, Please review

Re: RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

2017-03-16 Thread Chris Plummer
Hi Kumar, I explained the formatting changein a previous email, but I see now the formatting change I did on line 82 makes it inconsistent with similar source on line 82, so I'll change it back. thanks, Chris On 3/16/17 9:56 AM, Kumar Srinivasan wrote: Hello, I can't recall why String

Re: RFR(XS)(10): 8175342: assert(InstanceKlass::cast(k)->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation

2017-03-16 Thread Chris Plummer
On 3/15/17 10:14 PM, David Holmes wrote: Hi Chris, On 16/03/2017 2:57 PM, Chris Plummer wrote: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8175342 http://cr.openjdk.java.net/~cjplummer/8175342/webrev.00/webrev.jdk I think you want to disable the guardpage

RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small

2017-03-15 Thread Chris Plummer
Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8176797 http://cr.openjdk.java.net/~cjplummer/8176797/webrev.00/webrev.jdk After fixing 8175342 (see the other RFR I just posted), this test started to fail instead of assert. The problem is 256000 is too small of a

RFR(XS)(10): 8175342: assert(InstanceKlass::cast(k)->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation

2017-03-15 Thread Chris Plummer
Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8175342 http://cr.openjdk.java.net/~cjplummer/8175342/webrev.00/webrev.jdk The assert is somewhat misleading, although it did properly detect a "too small" stack issue. The test was run with -Xss256k on a system with

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

2016-11-21 Thread Chris Plummer
On 11/21/16 4:27 PM, Gustavo Romero wrote: Hi Joe, On 17-11-2016 19:33, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The reason for that is because historically the Solaris compilers have had sufficient discipline and

Re: PPC64: Poor StrictMath performance due to non-optimized compilation

2016-11-17 Thread Chris Plummer
On 11/17/16 1:33 PM, joe darcy wrote: Hi Gustavo, On 11/17/2016 10:31 AM, Gustavo Romero wrote: Hi Joe, Thanks a lot for your valuable comments. On 17-11-2016 15:35, joe darcy wrote: Currently, optimization for building fdlibm is disabled, except for the "solaris" OS target [1]. The

Re: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail

2016-08-03 Thread Chris Plummer
her code nearby uses =. I change it to = and the error message went away. I retested with various test cases that fail, pass, or run no tests, and all of them do as expected still. New webrev can be found at: http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ thanks, Chris On 8/2/16 7:

Re: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail

2016-08-02 Thread Chris Plummer
On 8/1/16 9:30 PM, Chris Plummer wrote: On 8/1/16 7:25 PM, David Holmes wrote: On 2/08/2016 12:11 PM, Chris Plummer wrote: On 8/1/16 5:58 PM, David Holmes wrote: Hi Chris, On 2/08/2016 8:46 AM, Chris Plummer wrote: Hello, Please review this simple change: https://bugs.openjdk.java.net

Re: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail

2016-08-01 Thread Chris Plummer
On 8/1/16 7:25 PM, David Holmes wrote: On 2/08/2016 12:11 PM, Chris Plummer wrote: On 8/1/16 5:58 PM, David Holmes wrote: Hi Chris, On 2/08/2016 8:46 AM, Chris Plummer wrote: Hello, Please review this simple change: https://bugs.openjdk.java.net/browse/JDK-8162670 http

Re: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail

2016-08-01 Thread Chris Plummer
On 8/1/16 5:58 PM, David Holmes wrote: Hi Chris, On 2/08/2016 8:46 AM, Chris Plummer wrote: Hello, Please review this simple change: https://bugs.openjdk.java.net/browse/JDK-8162670 http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ You've split a compound expression with your code

RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail

2016-08-01 Thread Chris Plummer
Hello, Please review this simple change: https://bugs.openjdk.java.net/browse/JDK-8162670 http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ Note the copyright dates haven't been updated in this webrev, but I did update them locally after noticing that. Tested with jprt test case

Re: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets

2015-12-07 Thread Chris Plummer
Thanks David! Can I get a second reviewer please? thanks, Chris On 12/6/15 3:52 PM, David Holmes wrote: Hi Chris, On 5/12/2015 7:00 AM, Chris Plummer wrote: Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144677 http://cr.openjdk.java.net/~cjplummer/8144677

Re: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets

2015-12-07 Thread Chris Plummer
Thanks Mikael! Chris On 12/7/15 3:22 PM, Mikael Vidstedt wrote: Thumbs up! Cheers, Mikael On 2015-12-07 14:27, Chris Plummer wrote: Thanks David! Can I get a second reviewer please? thanks, Chris On 12/6/15 3:52 PM, David Holmes wrote: Hi Chris, On 5/12/2015 7:00 AM, Chris Plummer

[RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets

2015-12-04 Thread Chris Plummer
Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8144677 http://cr.openjdk.java.net/~cjplummer/8144677/webrev.01/webrev/ Tested with JPRT with: • "-testset hotspot" • "-testset svc" • "-testset chris" from the example custom testset provided in the CR. • no

Re: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

2015-11-05 Thread Chris Plummer
Thanks David and Staffan! Chris On 11/4/15 11:25 PM, Staffan Larsen wrote: Looks good! Thanks, /Staffan On 5 nov. 2015, at 03:25, Chris Plummer <chris.plum...@oracle.com> wrote: Please review the following changes: http://cr.openjdk.java.net/~cjplummer/8141489/

Re: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

2015-11-05 Thread Chris Plummer
Hi Joe, Here's the updated webrev: http://cr.openjdk.java.net/~cjplummer/8141489/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8141489 These are all the repos that have been updated: >$ grep requiredVersion `find . -name TEST.ROOT` ./hotspot/test/TEST.ROOT:requiredVersion=4.1 b12

Re: [RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

2015-11-05 Thread Chris Plummer
On 11/5/15 10:16 AM, joe darcy wrote: Hi Chris, On 11/5/2015 9:26 AM, Chris Plummer wrote: Hi Joe, Is there a reason to upgrade them if the tests don't actually require b12? BTW, there are more than just those two repos. The following all have TEST.ROOT: bash-4.1$ find . -name TEST.ROOT

[RFR] (XS) 8141489: [TESTBUG] requiredVersion in TEST.ROOT needs to updated to 4.1 b12

2015-11-04 Thread Chris Plummer
Please review the following changes: http://cr.openjdk.java.net/~cjplummer/8141489/ https://bugs.openjdk.java.net/browse/JDK-8141489 The changes I did for 8140189 require that version 4.1 b12 of jtreg be used, so TEST.ROOT has been updated to reflect this. Testing with JPRT right now. I also

Re: [RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

2015-10-26 Thread Chris Plummer
mci tests locally. thanks, Chris On 10/23/15 7:50 AM, Staffan Larsen wrote: Looks good! Thanks for doing this. /Staffan On 23 okt. 2015, at 07:54, Chris Plummer <chris.plum...@oracle.com> wrote: Hello, Please review the following fix for 8140189: http://cr.openjdk.java.net/~cjplummer/8

[RFR] (S) 8140189: [TESTBUG] Get rid of "@library /../../test/lib" in jtreg tests

2015-10-22 Thread Chris Plummer
Hello, Please review the following fix for 8140189: http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.hotspot http://cr.openjdk.java.net/~cjplummer/8140189/webrev.00/webrev.jdk https://bugs.openjdk.java.net/browse/JDK-8140189 Please also see the following CR, which has much more

Re: [9] RFR (M) 8054386: Allow Java debugging when CDS is enabled

2015-06-04 Thread Chris Plummer
classes[]) 140 throws IOException 141 { Cheers, David On 2/06/2015 5:36 PM, Chris Plummer wrote: [Adding core-libs-dev@openjdk.java.net since this update includes changes to jdk/test library code] Please review the updated webrev: Webrev: http://cr.openjdk.java.net/~cjplummer/8054386

Re: [9] RFR (M) 8054386: Allow Java debugging when CDS is enabled

2015-06-03 Thread Chris Plummer
the folders are normally named in the lower case. Thanks, Serguei On 6/2/15 8:25 PM, Chris Plummer wrote: Ok, I'm going to keep this as one webrev, but I did create JDK-8081771 for the ProcessTool.java changes: https://bugs.openjdk.java.net/browse/JDK-8081771 I will commit ProcessTool.java under

Re: [9] RFR (M) 8054386: Allow Java debugging when CDS is enabled

2015-06-02 Thread Chris Plummer
the two versions are unified. thanks, Chris On 5/19/15 7:25 AM, Chris Plummer wrote: Hi, Please review the following changes for allowing java debugging when CDS is enabled. Webrev:http://cr.openjdk.java.net/~cjplummer/8054386/webrev.01/ Bug:https://bugs.openjdk.java.net/browse/JDK

Re: [9] RFR (M) 8054386: Allow Java debugging when CDS is enabled

2015-06-02 Thread Chris Plummer
I'm going to have to separate out the ProcessTool.java changes into a separate changeset (and CR). In the meantime, feel free to review what I have below. The code won't be changing at all when I separate out the ProcessTool.java changes. thanks, Chris On 6/2/15 12:36 AM, Chris Plummer

[9] RFR (XS) JDK-8081771: ProcessTool.createJavaProcessBuilder() needs new addTestVmAndJavaOptions argument

2015-06-02 Thread Chris Plummer
Please review the following: Webrev: http://cr.openjdk.java.net/~cjplummer/8054386/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8081771 This review only concerns the changes to ProcessTool.java. The CDSJDITests and filemapp.cpp changes will be committed under CR JDK-8054386, but

Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

2014-12-04 Thread Chris Plummer
On 12/3/14 4:56 AM, Alan Bateman wrote: On 02/12/2014 02:39, Chris Plummer wrote: Sorry about the long delay in getting back to this. I ran into two separate JPRT issues that were preventing me from testing these changes, plus I was on vacation last week. Here's an updated webrev. I'm

Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

2014-12-03 Thread Chris Plummer
with the integration, since it spans both HotSpot and JDK, and it appears the test will fail if the HotSpot changes are not integrated first, or has it already ? There are no hotspot changes. java.c is where the fix is. thanks, Chris Thanks Kumar On 12/1/2014 6:39 PM, Chris Plummer wrote

Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

2014-12-01 Thread Chris Plummer
http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/ thanks, Chris On 11/19/14 7:52 AM, Chris Plummer wrote: On 11/19/14 2:12 AM, David Holmes wrote: On 19/11/2014 6:49 PM, Chris Plummer wrote: I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k references, and also moved

Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

2014-11-19 Thread Chris Plummer
in the bits I needed into the script. http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/ I still need to rerun through JPRT. I'll do so once there are no more suggested changes. thanks, Chris On 11/18/14 2:08 PM, Chris Plummer wrote: Adding core-libs-dev@openjdk.java.net, since one

Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

2014-11-19 Thread Chris Plummer
On 11/19/14 2:12 AM, David Holmes wrote: On 19/11/2014 6:49 PM, Chris Plummer wrote: I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k references, and also moved the test from hotspot/test/runtime to jdk/test/tools/launcher as David requested. That required some adjustments

Re: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation fault

2014-11-19 Thread Chris Plummer
Adding core-libs-dev@openjdk.java.net, since one of the changes is in java.c. Chris On 11/12/14 6:43 PM, David Holmes wrote: Hi Chris, Sorry for the delay. On 13/11/2014 5:44 AM, Chris Plummer wrote: Hi, I'm still looking for reviewers. As the change is to the launcher it needs