Re: RFR: 8286956: Loom: Define test groups for development/porting use

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the > loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 >

Re: RFR: 8286681: ShenandoahControlThread::request_gc misses the case of GCCause::_codecache_GC_threshold

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu wrote: > Hi all, > > Some tests fail with Shenandoah GC after JDK-8282191. > The reason is that the assert in `ShenandoahControlThread::request_gc` misses > the case of `GCCause::_codecache_GC_threshold`. > It would be better to fix it. > > Thanks. >

Integrated: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results > not releasing native `jchar` array returned by `GetStringChars()`. This pull request has now been integrated. Changeset: 2cddf3f5 Author:Zhengyu G

Re: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

On Thu, 10 Mar 2022 19:46:28 GMT, Naoto Sato wrote: >> Please review this small patch that fixes early `CHECK_NULL_RETURN` results >> not releasing native `jchar` array returned by `GetStringChars()`. > > LGTM. Thanks, @naotoj @AlanBateman - PR:

Re: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows

On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results > not releasing native `jchar` array returned by `GetStringChars()`. Friendly ping. May I have a second review, please! - PR:

RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocalProviderAdapterImpl.getNumberPattern() on Windows

Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. - Commit messages: - 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on

Integrated: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c

On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu wrote: > Please review this trivial patch to correct last parameter of > `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean` This pull request has now been integrated. Changeset: 879b6445 Author:Zhengyu G

Re: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c

On Thu, 10 Mar 2022 17:25:55 GMT, Naoto Sato wrote: > LGTM. Thanks for the fix! Thanks for the review. - PR: https://git.openjdk.java.net/jdk/pull/7775

Re: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c

On Thu, 10 Mar 2022 15:28:15 GMT, Aleksey Shipilev wrote: > Looks fine to me. Thanks, @shipilev - PR: https://git.openjdk.java.net/jdk/pull/7775

RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c

Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean` - Commit messages: - 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c Changes:

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2]

On Tue, 8 Mar 2022 21:05:13 GMT, Alexey Ivanov wrote: >> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which >> one you pick. > >> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which >> one you pick. > > Yes. > > But we're discussing whether a

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2]

On Tue, 8 Mar 2022 20:57:27 GMT, Alexey Ivanov wrote: >>> ??? You want to check and cleanup if NewStringUTF fails. You only want to >>> call SetObjectElementArray if NewStringUTF succeeds. >> >> If the SetObjectArrayElement will throw an exception we will call the >> NewStringUTF while the

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2]

On Tue, 8 Mar 2022 15:58:57 GMT, Alexey Ivanov wrote: > > I did a quick grep, there are a few suspicious spots, e.g. > > [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), > > I have yet take a close look. > > It doesn't leak

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2]

> Please review this small patch that fixes a potential memory leak that > exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 Zhengyu Gu has updated the pull request incrementally with one additional commit since

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()

On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that > exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 > > > The macros are used t

Re: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()

On Fri, 4 Mar 2022 21:30:53 GMT, David Holmes wrote: > I would have just inlined JNU_CHECK_EXCEPTION and added the cleanup code > directly. The additional macro wasn't really necessary and would not really > be usable for any kind of general cleanup actions beyond a one-liner. > > But it is

RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig()

Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` Test: - [x] jdk_desktop on Linux x86_64 - Commit messages: - 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() Changes:

Re: RFR: JDK-8256844: Make NMT late-initializable [v2]

On Wed, 4 Aug 2021 03:36:11 GMT, Thomas Stuefe wrote: > Nightlies at SAP showed no problems for several runs now. The failed GHA test > (StringDeduplication) seems to have nothing to do with my patch. > > @zhengyu123 are you fine with the latest version of this patch? Still good.

Re: RFR: JDK-8256844: Make NMT late-initializable

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe wrote: > Short: this patch makes NMT available in custom-launcher scenarios and during > gtests. It simplifies NMT initialization. It adds a lot of NMT-specific > testing, cleans them up and makes them sideeffect-free. > > - > > NMT

Re: RFR: JDK-8256844: Make NMT late-initializable

On Fri, 30 Jul 2021 16:36:41 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/nmtPreInit.hpp line 309: >> >>> 307: ::memcpy(p_new, a->payload(), MIN2(a->size, new_size)); >>> 308: (*rc) = p_new; >>> 309: _num_reallocs_pre_to_post++; >> >> post-NMT-init counter

Re: RFR: JDK-8256844: Make NMT late-initializable

On Fri, 30 Jul 2021 16:33:17 GMT, Zhengyu Gu wrote: >> The code is implicitly thread-safe because the hashmap is only modified in >> the pre-NMT-init phase. After NMT initialization, the table is read-only. >> During pre-NMT-init we are effectively single-threaded - a

Re: RFR: JDK-8256844: Make NMT late-initializable

On Fri, 30 Jul 2021 16:28:54 GMT, Thomas Stuefe wrote: >> src/hotspot/share/services/nmtPreInit.hpp line 202: >> >>> 200: assert((*aa) != NULL, "Entry not found: " PTR_FORMAT, p2i(p)); >>> 201: NMTPreInitAllocation* a = (*aa); >>> 202: (*aa) = (*aa)->next; // remove from its

Re: RFR: JDK-8256844: Make NMT late-initializable

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe wrote: > Short: this patch makes NMT available in custom-launcher scenarios and during > gtests. It simplifies NMT initialization. It adds a lot of NMT-specific > testing, cleans them up and makes them sideeffect-free. > > - > > NMT

Re: RFR: 8254598: StringDedupTable should use OopStorage [v4]

processing phases by >> supporting GCs. >> >> (The Shenandoah update was contributed by Zhengyu Gu.) >> >> This change significantly simplifies the interface between a given GC and >> the String Deduplication facility, which should make it much easier for >> other

Re: RFR: 8254598: StringDedupTable should use OopStorage

; supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly [v3]

On Wed, 20 Jan 2021 01:47:54 GMT, Alex Menkov wrote: >> The fix adds NMT handling for non-java launchers > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > Updated comment Sorry, I overlooked some of details. Final change

Re: RFR: 8258917: NativeMemoryTracking is handled by launcher inconsistenly

On Fri, 15 Jan 2021 23:50:16 GMT, Alex Menkov wrote: > The fix adds NMT handling for non-java launchers Looks good - Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2106

Re: RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

On 06/05/2018 12:10 PM, Thomas Stüfe wrote:> On Tue, Jun 5, 2018 at 3:46 PM, Adam Farley8 wrote: Hi All, Native memory allocation for DBBs is tracked in java.nio.Bits, but that only includes what the user thinks they are allocating. Which is exactly what I would expect as a user... I

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

Think of it as an NMT upgrade. Here's an example of what the output should look like: https://developer.ibm.com/answers/questions/288697/why- does-nativememinfo-in-javacore-show-incorrect.html?sort=oldest - Adam I think NMT walks the stack, so we should get allocation points grouped by

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

On 02/14/2018 08:16 AM, Thomas Stüfe wrote: On Wed, Feb 14, 2018 at 1:53 PM, David Holmes wrote: On 14/02/2018 10:43 PM, David Holmes wrote: Adding in core-libs-dev as there's nothing related to hotspot directly here. Correction, this is of course leading to a

Re: Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement

as your prototype suggested. I'll get right on it. -neil On 6/25/2014 12:05 PM, Zhengyu Gu wrote: Hi Neil, I tried out this patch with my hotspot, it does not work. The reason is that, the environment variable is setup too late, it has to be set before it launches JavaVM (before calling LoadJavaVM

Re: Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement

For the future, are there any other possibilities? Thanks -neil On 6/26/2014 10:57 AM, Zhengyu Gu wrote: Hi Neil, There is still an issue. Apparently, you can NOT free the buffer for the environment variable. 678 char * pbuf = (char*)JLI_MemAlloc(pbuflen); 679

Re: Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement

complain. Thanks Zhengyu. I'll make sure these are non-null. -neil On 6/20/2014 5:01 AM, Zhengyu Gu wrote: Neil, Thanks for quick implementation. java.c: Did not check return values of malloc(), I wonder if source code analyzers will complain. -Zhengyu On 6/19/2014 8:29 PM, Neil Toda wrote

Re: Ready for Review : 8042469 : Launcher changes for native memory tracking scalability enhancement

Neil, Thanks for quick implementation. java.c: Did not check return values of malloc(), I wonder if source code analyzers will complain. -Zhengyu On 6/19/2014 8:29 PM, Neil Toda wrote: Launcher support for modified Native Memory Tracking mechanism in JVM in JDK9. Webrev :

hg: jdk8/tl/jdk: 8006691: Remove jvm_version_info-is_kernel_jvm field

Changeset: cd111064d4e9 Author:zgu Date: 2013-02-12 14:47 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd111064d4e9 8006691: Remove jvm_version_info-is_kernel_jvm field Summary: Remove is_kernel_jvm field in jvm_version_info structure, as kernel VM has been deprecated

Code review request: 8006691: Remove jvm_version_info.is_kernel_jvm field

Kernel VM has been deprecated since JDK7 and related JVM code has also been removed recently. This change is to remove is_kernel_jvm flag from jvm_version_info structure in jvm.h on JDK side. Bug: http://bugs.sun.com/view_bug.do?bug_id=8006691 CCC: http://ccc.us.oracle.com/8006691 JDK7:

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 2381e810330b Author:zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter