On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote:
> There are 2 tests that should be deleted. They test Thread.suspend/resume and
> don't have a sense if these functions don't work.
Looks good.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.open
On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote:
>> Test update to cope with heap size changing (shrinking) in the early life of
>> the test app.
>>
>> A change in GC timing affects this test which reads eden size and heap size.
>> Both eden and heap are likely to shrink initially for this
On Tue, 13 Sep 2022 21:03:13 GMT, Alex Menkov wrote:
>> The problem is RedefineClasses does not update cached_class_bytes, so
>> subsequent RetransformClasses gets obsolete class bytes (this are testcases
>> 3-6 from the new test)
>>
>> cached_class_bytes are set when an agent instruments the
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote:
> There are 2 tests that should be deleted. They test Thread.suspend/resume and
> don't have a sense if these functions don't work.
Marked as reviewed by cjplummer (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10255
There are 2 tests that should be deleted. They test Thread.suspend/resume and
don't have a sense if these functions don't work.
-
Commit messages:
- 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume
Changes: https://git.openjdk.org/jdk/pull/10255/files
Webrev: htt
On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote:
>> Test update to cope with heap size changing (shrinking) in the early life of
>> the test app.
>>
>> A change in GC timing affects this test which reads eden size and heap size.
>> Both eden and heap are likely to shrink initially for this
On Tue, 13 Sep 2022 09:49:58 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> s/verity/verify/
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransfo
> The problem is RedefineClasses does not update cached_class_bytes, so
> subsequent RetransformClasses gets obsolete class bytes (this are testcases
> 3-6 from the new test)
>
> cached_class_bytes are set when an agent instruments the class from
> ClassFileLoadHook.
> After successful Redefine
On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman wrote:
> > There is a bunch of VM code for this too. Should we clean that up
> > separately?
>
>
>
> Yes chatted with @dholmes-ora about this recently and he suggested separating
> out so there is a follow-on JBS issue created for that. Aside fr
On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan wrote:
> What about also removing and undocumenting `RuntimePermission("stopThread")`
> as part of this change?
Ah yes, the table RuntimePermission can be updated as part of this (and the
corresponding constant in sun/security/util/SecurityConstant
On Tue, 13 Sep 2022 19:06:14 GMT, Erik Österlund wrote:
> There is a bunch of VM code for this too. Should we clean that up separately?
Yes chatted with @dholmes-ora about this recently and he suggested separating
out so there is a follow-on JBS issue created for that. Aside from
JVM_StopThrea
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote:
> Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often
> can be simplified by using their pair methods
> `parseInt`/`parseBoolean`/`parseLong`.
This pull request has now been integrated.
Changeset: 7e020398
Autho
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (199
Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
removal, and remove the remaining special handling of ThreadDeath from the JDK.
Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998)
with a link to a supplementary page that explains the rational
On Mon, 12 Sep 2022 20:30:04 GMT, Alex Menkov wrote:
>> The problem is RedefineClasses does not update cached_class_bytes, so
>> subsequent RetransformClasses gets obsolete class bytes (this are testcases
>> 3-6 from the new test)
>>
>> cached_class_bytes are set when an agent instruments the
On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote:
> This is an MR which partially reverts JDK-8289091 such that
> JavaThread::threadObj() does not call Thread::current().
>
> A JVMTI operation could call threadObj() and clear the Windows GetLastError
> value.
>
> Partial, because I haven't
On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote:
> Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often
> can be simplified by using their pair methods
> `parseInt`/`parseBoolean`/`parseLong`.
Marked as reviewed by stsypa...@github.com (no known OpenJDK username
22 matches
Mail list logo
