On Fri, 28 Apr 2023 04:56:17 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use NamedTask library class
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java
>
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
On Thu, 27 Apr 2023 21:08:23 GMT, Chris Plummer wrote:
>> Convert this ThreadReference.interrupt() test to support virtual threads. I
>> believe this is the only test for ThreadReference.interrupt() that we have.
>>
>> Tested by running with and without -Dmain.wrapper=Virtual on all supported
On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote:
> Please review this change to the string deduplication thread to make it a kind
> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
> this change:
>
> (1) New class StringDedupThread (derived from JavaThread), separ
> Please review this change to the string deduplication thread to make it a kind
> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
> this change:
>
> (1) New class StringDedupThread (derived from JavaThread), separate from
> StringDedup::Processor (which is now just a
On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote:
>> Please review this change to the string deduplication thread to make it a
>> kind
>> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
>> this change:
>>
>> (1) New class StringDedupThread (derived from JavaThrea
On Fri, 28 Apr 2023 00:46:23 GMT, Serguei Spitsyn wrote:
>> Ok. How about "the function cannot be performed on the thread's current
>> frame". We already have a couple references to "the function" in the error
>> codes section.
>
> We have two suggestions:
>> - "or a function on a thread cannot
On Thu, 27 Apr 2023 19:14:56 GMT, Chris Plummer wrote:
>> I think the first part is okay because it's for functions that are about
>> frames. The NotifyFramePop specifies the depth so it may not be the current
>> frame. The second usage is the functions on a thread where we might do
>> better
On Thu, 27 Apr 2023 07:52:23 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 27 Apr 2023 21:08:23 GMT, Chris Plummer wrote:
>> Convert this ThreadReference.interrupt() test to support virtual threads. I
>> believe this is the only test for ThreadReference.interrupt() that we have.
>>
>> Tested by running with and without -Dmain.wrapper=Virtual on all supported
> Convert this ThreadReference.interrupt() test to support virtual threads. I
> believe this is the only test for ThreadReference.interrupt() that we have.
>
> Tested by running with and without -Dmain.wrapper=Virtual on all supported
> platforms.
Chris Plummer has updated the pull request incr
On Thu, 27 Apr 2023 19:43:51 GMT, Leonid Mesnik wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> some thread -> task renaming
>
> test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001a.java
>
> Convert this ThreadReference.interrupt() test to support virtual threads. I
> believe this is the only test for ThreadReference.interrupt() that we have.
>
> Tested by running with and without -Dmain.wrapper=Virtual on all supported
> platforms.
Chris Plummer has updated the pull request incr
On Thu, 27 Apr 2023 17:42:41 GMT, Chris Plummer wrote:
> Convert this ThreadReference.interrupt() test to support virtual threads. I
> believe this is the only test for ThreadReference.interrupt() that we have.
>
> Tested by running with and without -Dmain.wrapper=Virtual on all supported
> pl
On Thu, 27 Apr 2023 18:59:34 GMT, Alan Bateman wrote:
>> The wording starts off with "Information about the frame...", and you
>> haven't suggested to change that to "the current frame". We should be
>> consistent. Can't we just change both "the frame" references to "the current
>> frame", and
On Thu, 27 Apr 2023 18:49:40 GMT, Chris Plummer wrote:
>> src/hotspot/share/prims/jvmti.xml line 11984:
>>
>>> 11982:
>>> 11983: Information about the frame is not available (e.g. for native
>>> frames),
>>> 11984: or the frame is not suitable for the requested operation.
>>
>
On Thu, 27 Apr 2023 10:58:14 GMT, Alan Bateman wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> install_async_exception: set interrupt status for platform threads only
>
> src/hotspot/share/prims/jvmti.xml line 1
Convert this ThreadReference.interrupt() test to support virtual threads. I
believe this is the only test for ThreadReference.interrupt() that we have.
Tested by running with and without -Dmain.wrapper=Virtual on all supported
platforms.
-
Commit messages:
- Add vthread support to
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> atomic access.
>
> This leaves AccessFlags int size because Kla
On Thu, 27 Apr 2023 10:38:17 GMT, Albert Mingkun Yang wrote:
> > I think you are right about using is_humongous() directly here: the reason
> > we skip compacting of humongous regions during the "main" compaction is
> > intentional here
>
> However, I am unable to discern the difference -- why
On Thu, 27 Apr 2023 12:09:21 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/constMethodFlags.hpp line 53:
>>
>>> 51:flag(has_type_annotations , 1 << 9) \
>>> 52:flag(has_default_annotations , 1 << 10) \
>>> 53:flag(caller_sensitive , 1 << 11) \
>>
>> Nit: we
On Thu, 27 Apr 2023 04:35:10 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add is prefixes and some cleanups.
>
> src/hotspot/share/oops/constMethodFlags.hpp line 53:
>
>> 51:flag(has_
> This change moves the flags from AccessFlags to either ConstMethodFlags or
> MethodFlags, depending on whether they are set at class file parse time,
> which makes them essentially const, or at runtime, which makes them needing
> atomic access.
>
> This leaves AccessFlags int size because Kla
> Hi all,
>
> please review this change that removes the pinned tag from `HeapRegion`.
>
> So that "pinned" tag for G1 heap regions indicates that the region should not
> move during (young) gc. This applies to now removed archive regions and
> humongous objects/regions.
>
> With "real" g1 r
On Thu, 27 Apr 2023 04:28:31 GMT, David Holmes wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>> atom
On Thu, 27 Apr 2023 09:14:29 GMT, Serguei Spitsyn wrote:
>> This enhancement adds support of virtual threads to the JVMTI `StopThread`
>> function.
>> In preview releases before this enhancement the StopThread returned the
>> JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads.
>>
On Wed, 26 Apr 2023 09:12:24 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that removes the pinned tag from `HeapRegion`.
>>
>> So that "pinned" tag for G1 heap regions indicates that the region should
>> not move during (young) gc. This applies to now removed archive
On Sat, 15 Apr 2023 10:15:20 GMT, Kevin Walls wrote:
>> This test is failing often since 8304725 added a call to
>> Thread::current_in_asgct(). This can end up being called e.g. when
>> resolving calls, and then the OS last error value is lost.
>>
>> The test is reliable with a single warm-up
> This enhancement adds support of virtual threads to the JVMTI `StopThread`
> function.
> In preview releases before this enhancement the StopThread returned the
> JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads.
>
> The `StopThread` supports sending an asynchronous exception t
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with Li
On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl wrote:
> Hi all,
>
> please review this change that removes some remaining CMS related stuff.
>
> Testing: tier1-3, gha
>
> Thanks,
> Thomas
This pull request has now been integrated.
Changeset: d94ce656
Author:Thomas Schatzl
URL:
On Tue, 25 Apr 2023 16:43:27 GMT, Aleksey Shipilev wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> cplummer review
>
> Looks fine to me.
>
> But the synopsis has a typo, "remnants".
Thanks @shipilev @kimbarrett
33 matches
Mail list logo
