Re: RFR: 8275800: Redefinition leaks MethodData::_extra_data_lock [v3]
On Tue, 26 Oct 2021 11:43:42 GMT, Coleen Phillimore wrote: >> The Mutex destructor isn't called for the MDO lock. We found this leak with >> crashes for the patch to print all mutex locks on error, which is now >> withdrawn. It was easily reproduced with that patch. It is not easily >> reproduced otherwise. >> I tested this change with that patch though and it passes tier1-6, > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Move constant pool release_C_heap_structures to the end. Thanks David and Serguei! - PR: https://git.openjdk.java.net/jdk/pull/6105
Integrated: 8275800: Redefinition leaks MethodData::_extra_data_lock
On Mon, 25 Oct 2021 12:51:32 GMT, Coleen Phillimore wrote: > The Mutex destructor isn't called for the MDO lock. We found this leak with > crashes for the patch to print all mutex locks on error, which is now > withdrawn. It was easily reproduced with that patch. It is not easily > reproduced otherwise. > I tested this change with that patch though and it passes tier1-6, This pull request has now been integrated. Changeset: 40606021 Author:Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/40606021ee6b7d18674e36b3f6249f1ca8a7647e Stats: 35 lines in 5 files changed: 11 ins; 16 del; 8 mod 8275800: Redefinition leaks MethodData::_extra_data_lock Reviewed-by: sspitsyn, dholmes - PR: https://git.openjdk.java.net/jdk/pull/6105
Re: RFR: 8274621: NullPointerException because listenAddress[0] is null
On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization > issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not > updated). > The fix keeps existing functionality as is (as we have this behavior for a > long time and we have tests which expect STDERR output), but adds > synchronization to avoid calling predicate after previous call returned > "true". > Also updated javadoc to reflect actual behavior. Ping. Need 2nd reviewer - PR: https://git.openjdk.java.net/jdk/pull/5830
Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string
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) Ping. Need 2nd reviewer - PR: https://git.openjdk.java.net/jdk/pull/5858
Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string
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 tests that currently test the default PerfMaxStringConstLength, and this change could be subverting the test by making it so the length is never exceeded? - PR: https://git.openjdk.java.net/jdk/pull/5858
Re: RFR: 8271356: Modify jdb to treat an empty command as a repeat of the previous command [v6]
On Mon, 25 Oct 2021 19:50:54 GMT, Chris Plummer wrote: >> Based on my local testing it appears the localization system falls back to >> the English values when entries are missing, so it appears the current >> behavior does already match what you've suggested. However, I don't >> understand the mechanism that implements this fallback handling, so I'm not >> sure the behavior would be consistent across environments. At least for now >> I'll add those entries back with the English translations copied, since that >> seems better. > >> Based on my local testing it appears the localization system falls back to >> the English values when entries are missing, so it appears the current >> behavior does already match what you've suggested. However, I don't >> understand the mechanism that implements this fallback handling, so I'm not >> sure the behavior would be consistent across environments. At least for now >> I'll add those entries back with the English translations copied, since that >> seems better. > > Ok. That change looks good, but you need to update the copyright in those two > files. @plummercj Looks like this is all ready to go then. Would you be willing to sponsor it for integration? - PR: https://git.openjdk.java.net/jdk/pull/5290
Re: RFR: 8274621: NullPointerException because listenAddress[0] is null
On Tue, 5 Oct 2021 22:34:38 GMT, Alex Menkov wrote: > The change fixes ProcessTools.startProcess "warmup predicate" synchronization > issue. > Initially the predicate was called only for STDOUT; > From jdk8 it's called for STDERR too (but ProcessTools javadoc was not > updated). > The fix keeps existing functionality as is (as we have this behavior for a > long time and we have tests which expect STDERR output), but adds > synchronization to avoid calling predicate after previous call returned > "true". > Also updated javadoc to reflect actual behavior. Marked as reviewed by lmesnik (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5830
