On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman wrote:
>> xpbob has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> update header
>
> It's not clear that introducing this as a standard API is the right thing to
> do. Are you 100% confident th
On Wed, 6 Jul 2022 05:59:21 GMT, Alan Bateman wrote:
>> xpbob has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> update header
>
> It's not clear that introducing this as a standard API is the right thing to
> do. Are you 100% confident th
On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote:
> This change removes the last remnants of sun/hotspot/WhiteBox.java and other
> classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
> deleted the old files a
On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore wrote:
> This change removes the last remnants of sun/hotspot/WhiteBox.java and other
> classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and
> deleted the old files a
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish event, that results, sometimes, it
> only captures partial or even empty unload
On Fri, 1 Jul 2022 18:36:26 GMT, Chris Plummer wrote:
>> Zhengyu Gu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Incorporated plummercj's test changes
>
> test/jdk/com/sun/jdi/TestClassUnloadEvents.java line 61:
>
>> 59:
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish event, that results, sometimes, it
> only captures partial or even empty unload
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
> the `Subject`
On Mon, 11 Jul 2022 18:49:26 GMT, Sean Mullan wrote:
>> Add null-checks in all `LoginModule` implementations. It's possible that an
>> application calls `logout` after a login failure, where most internal
>> variables for principals and credentials are null and removing a null from
>> the `Sub
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
> the `Subject`
On Mon, 11 Jul 2022 20:09:31 GMT, Sean Mullan wrote:
>> Add null-checks in all `LoginModule` implementations. It's possible that an
>> application calls `logout` after a login failure, where most internal
>> variables for principals and credentials are null and removing a null from
>> the `Sub
On Mon, 11 Jul 2022 19:49:13 GMT, Weijun Wang wrote:
>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java
>> line 289:
>>
>>> 287: subject.getPrincipals().remove(GIDPrincipal);
>>> 288: }
>>> 289: if (supplementaryGroups != null) {
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
> the `Subject`'s principals and credentials sets will trigger a
> `
On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote:
> Add null-checks in all `LoginModule` implementations. It's possible that an
> application calls `logout` after a login failure, where most internal
> variables for principals and credentials are null and removing a null from
> the `Subject`
On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn wrote:
>> This is a test bug. The test should filter out non-tested threads to avoid
>> generating such kind of deadlocks.
>>
>> In short, the deadlock dependencies are:
>>
>> - The `Common-Cleaner` thread is executing the JVM TI agent `Method
On Sat, 9 Jul 2022 06:43:12 GMT, Serguei Spitsyn wrote:
> This is a test bug. The test should filter out non-tested threads to avoid
> generating such kind of deadlocks.
>
> In short, the deadlock dependencies are:
>
> - The `Common-Cleaner` thread is executing the JVM TI agent `MethodEntry`
On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn wrote:
>> This is a test bug. The test should filter out non-tested threads to avoid
>> generating such kind of deadlocks.
>>
>> In short, the deadlock dependencies are:
>>
>> - The `Common-Cleaner` thread is executing the JVM TI agent `Method
On Sun, 10 Jul 2022 10:12:54 GMT, Serguei Spitsyn wrote:
>> This is a test bug. The test should filter out non-tested threads to avoid
>> generating such kind of deadlocks.
>>
>> In short, the deadlock dependencies are:
>>
>> - The `Common-Cleaner` thread is executing the JVM TI agent `Method
On Mon, 11 Jul 2022 15:00:41 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that results,
On Mon, 11 Jul 2022 15:00:41 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that results,
> Currently, jdi only check and process class unloading event when it detects a
> new GC cycle.
>
> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
> class events can overlap with GC finish event, that results, sometimes, it
> only captures partial or even empty unload
On Tue, 12 Jul 2022 01:44:28 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that results,
On Tue, 12 Jul 2022 01:44:28 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that results,
On Tue, 12 Jul 2022 01:44:28 GMT, Zhengyu Gu wrote:
>> Currently, jdi only check and process class unloading event when it detects
>> a new GC cycle.
>>
>> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting
>> class events can overlap with GC finish event, that results,
26 matches
Mail list logo
