On Thu, 6 Oct 2022 22:17:21 GMT, Chris Plummer wrote:
> [JDK-8208091](https://bugs.openjdk.org/browse/JDK-8208091) also addressed
> windows-x86. Any reason not to do the same here? I see bsd-x86 was neglected
> for [JDK-8208091](https://bugs.openjdk.org/browse/JDK-8208091). Would have
> been
On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen wrote:
>> Here's a suggested solution for the ticket mentioned and a use case for
>> outputStream. I'm not attached to the name.
>>
>> This saves space for all allocated outputStreams, which is nice. It also
>> makes the purpose of ResourceObj
On Thu, 6 Oct 2022 17:31:00 GMT, Serguei Spitsyn wrote:
>> The spec of JVM TI GetLocalXXX/SetLocalXXX functions is updated to require
>> the target thread to be suspended. If not suspended then the
>> JVMTI_ERROR_THREAD_NOT_SUSPENDED error code is returned by the
>> implementation.
>>
>> The
On Thu, 6 Oct 2022 18:59:57 GMT, Aleksey Shipilev wrote:
> See the description in the bug. This fixes only Linux x86_32, because only
> there I could reproduce the failure. Windows x86_32 seems to be fine. I have
> no access to BSD x86_32.
>
> Additional testing:
> - [x] Linux x86 fastdebug
See the description in the bug. This fixes only Linux x86_32, because only
there I could reproduce the failure. Windows x86_32 seems to be fine. I have no
access to BSD x86_32.
Additional testing:
- [x] Linux x86 fastdebug `serviceability/sa` now cleanly passes
-
Commit messages:
On Thu, 6 Oct 2022 15:31:02 GMT, Chris Plummer wrote:
> If these tests are ever run with the virtual thread wrapper, will we end up
> being short a carrier thread? It's unclear to me if the tests will always
> have at least one unpinned carrier thread to work with.
There's nothing inherit
> 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
On Thu, 6 Oct 2022 07:16:44 GMT, Dmitry Samersoff
wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressed review comments about is_JavaThread_current and @enablePreview
>> tag
>
>
> The spec of JVM TI GetLocalXXX/SetLocalXXX functions is updated to require
> the target thread to be suspended. If not suspended then the
> JVMTI_ERROR_THREAD_NOT_SUSPENDED error code is returned by the implementation.
>
> The CSR is: https://bugs.openjdk.org/browse/JDK-8294690
>
> A few
On Thu, 6 Oct 2022 00:50:50 GMT, Leonid Mesnik wrote:
>> The spec of JVM TI GetLocalXXX/SetLocalXXX functions is updated to require
>> the target thread to be suspended. If not suspended then the
>> JVMTI_ERROR_THREAD_NOT_SUSPENDED error code is returned by the
>> implementation.
>>
>> The
On Thu, 6 Oct 2022 02:24:12 GMT, Alex Menkov wrote:
> Test failure is a duplicate of
> [JDK-8284777](https://bugs.openjdk.org/browse/JDK-8284777), but the test
> needs to be updated:
> - the test instruments all loaded classes, so need to updated ASM version to
> support records and permits;
On Thu, 6 Oct 2022 13:39:25 GMT, Alan Bateman wrote:
>> This is a test only change for two tests for virtual threads that
>> hang/timeout on single core systems. The two tests involve pinning and
>> require at least two carrier threads. The test lib used by these tests is
>> updated to define
On Thu, 6 Oct 2022 14:26:27 GMT, Serguei Spitsyn wrote:
> Just a side note to be aware about a potential problem.
> This won't work correctly if there are more than one such tests executed in
> VM at the same time.
> Then there can be a race to restore the parallelism value.
> But it seems is
On Wed, 5 Oct 2022 22:49:20 GMT, Serguei Spitsyn wrote:
> The spec of JVM TI GetLocalXXX/SetLocalXXX functions is updated to require
> the target thread to be suspended. If not suspended then the
> JVMTI_ERROR_THREAD_NOT_SUSPENDED error code is returned by the implementation.
>
> The CSR is:
On Thu, 6 Oct 2022 13:39:25 GMT, Alan Bateman wrote:
>> This is a test only change for two tests for virtual threads that
>> hang/timeout on single core systems. The two tests involve pinning and
>> require at least two carrier threads. The test lib used by these tests is
>> updated to define
On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen wrote:
>> Here's a suggested solution for the ticket mentioned and a use case for
>> outputStream. I'm not attached to the name.
>>
>> This saves space for all allocated outputStreams, which is nice. It also
>> makes the purpose of ResourceObj
On Thu, 6 Oct 2022 12:44:23 GMT, Johan Sjölen wrote:
>> Here's a suggested solution for the ticket mentioned and a use case for
>> outputStream. I'm not attached to the name.
>>
>> This saves space for all allocated outputStreams, which is nice. It also
>> makes the purpose of ResourceObj
> This is a test only change for two tests for virtual threads that
> hang/timeout on single core systems. The two tests involve pinning and
> require at least two carrier threads. The test lib used by these tests is
> updated to define a new method that ensures parallelism is at least a given
On Wed, 5 Oct 2022 20:24:59 GMT, Chris Plummer wrote:
>> No, restoration requires a call to close. Maybe you are assuming that
>> AutoCloseable implementations setup a cleaner to do that?
>
> Yes, that was my point of confusion. I thought collection triggered calling
> close, but I see now
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
> Here's a suggested solution for the ticket mentioned and a use case for
> outputStream. I'm not attached to the name.
>
> This saves space for all allocated outputStreams, which is nice. It also
> makes the purpose of ResourceObj more clear ("please handle the life cycle
> for me"), reducing
> Here's a suggested solution for the ticket mentioned and a use case for
> outputStream. I'm not attached to the name.
>
> This saves space for all allocated outputStreams, which is nice. It also
> makes the purpose of ResourceObj more clear ("please handle the life cycle
> for me"), reducing
On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman wrote:
> This is a test only change to remove the granting of
> RuntimePermission("stopThread") from the tests. With Thread.stop changed to
> throw UOE it means there is nothing that requires this permission.
LGTM
-
Marked as
This change replaces the current stack-locking implementation with a
fast-locking scheme that 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 Lilliput, because it
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
On Mon, 12 Sep 2022 07:54:48 GMT, Roman Kennke wrote:
>>> How have you handled the interpreter lock-stack-area in your
>>> implementation? Is it worth to get rid of it and consolidate with the
>>> per-thread lock-stack?
>>
>> At the moment I had to store a "frame id" for each entry in the
On Mon, 12 Sep 2022 07:54:48 GMT, Roman Kennke wrote:
>>> How have you handled the interpreter lock-stack-area in your
>>> implementation? Is it worth to get rid of it and consolidate with the
>>> per-thread lock-stack?
>>
>> At the moment I had to store a "frame id" for each entry in the
On Mon, 12 Sep 2022 07:54:48 GMT, Roman Kennke wrote:
> Nice! From your snippets above I am gleaning that your implementation has the
> actual lock-stack in Java. Is that correct? Is there a particular reason why
> you need this? Is this for Loom? Would the implementation that I am proposing
On Mon, 12 Sep 2022 06:37:19 GMT, Robbin Ehn wrote:
> > How have you handled the interpreter lock-stack-area in your
> > implementation? Is it worth to get rid of it and consolidate with the
> > per-thread lock-stack?
>
> At the moment I had to store a "frame id" for each entry in the lock
On Fri, 9 Sep 2022 19:01:14 GMT, Roman Kennke wrote:
> How have you handled the interpreter lock-stack-area in your implementation?
> Is it worth to get rid of it and consolidate with the per-thread lock-stack?
At the moment I had to store a "frame id" for each entry in the lock stack.
The
On Tue, 30 Aug 2022 11:52:24 GMT, Roman Kennke wrote:
>> I didn't realize you still also is using the frame basic lock area. (in
>> other projects this is removed and all cases are handled via the threads
>> lock stack)
>> So essentially we have two lock stacks when running in interpreter the
On Wed, 17 Aug 2022 15:34:01 GMT, Roman Kennke wrote:
>>> Strictly speaking, I believe the conditions check for the (weaker) balanced
>>> property, but not for the (stronger) structured property.
>>
>> I know but the text says:
>> - "every exit on a given monitor matches a preceding entry on
On Wed, 17 Aug 2022 07:29:23 GMT, Robbin Ehn wrote:
> > Strictly speaking, I believe the conditions check for the (weaker) balanced
> > property, but not for the (stronger) structured property.
>
> I know but the text says:
>
> * "every exit on a given monitor matches a preceding entry on
On Tue, 16 Aug 2022 16:21:04 GMT, Roman Kennke wrote:
> Strictly speaking, I believe the conditions check for the (weaker) balanced
> property, but not for the (stronger) structured property.
I know but the text says:
- "every exit on a given monitor matches a preceding entry on that monitor."
On Tue, 16 Aug 2022 15:47:58 GMT, Robbin Ehn wrote:
> > @robehn or @dholmes-ora I believe one of you mentioned somewhere (can't
> > find the comment, though) that we might need to support the bytecode
> > sequence monitorenter A; monitorenter B; monitorexit A; monitorexit B;
> > properly. I
On Thu, 11 Aug 2022 11:39:01 GMT, Robbin Ehn wrote:
>>> > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
>>> > problem (seems weird that GHA did not catch it).
>>>
>>> NP, thanks. I notice some other user of owning_thread_from_monitor_owner()
>>> such as
On Thu, 11 Aug 2022 11:39:01 GMT, Robbin Ehn wrote:
> > > > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> > > > problem (seems weird that GHA did not catch it).
> > >
> > >
> > > NP, thanks. I notice some other user of
> > > owning_thread_from_monitor_owner() such
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
On Thu, 11 Aug 2022 11:19:31 GMT, Roman Kennke wrote:
> > > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> > > problem (seems weird that GHA did not catch it).
> >
> >
> > NP, thanks. I notice some other user of owning_thread_from_monitor_owner()
> > such as
On Tue, 9 Aug 2022 11:05:45 GMT, Robbin Ehn wrote:
> > Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> > problem (seems weird that GHA did not catch it).
>
> NP, thanks. I notice some other user of owning_thread_from_monitor_owner()
> such as
On Tue, 9 Aug 2022 09:32:47 GMT, Roman Kennke wrote:
> I am not aware, please refresh my memory if you know different, of any core
> hotspot subsystem just being replaced in one fell swoop in one single
> release. Yes this needs a lot of testing but customers are not beta-testers.
> If this
On Tue, 9 Aug 2022 10:46:51 GMT, Roman Kennke wrote:
> Thanks for giving this PR a spin. I pushed a fix for the aarch64 build
> problem (seems weird that GHA did not catch it).
NP, thanks.
I notice some other user of owning_thread_from_monitor_owner() such as
DeadlockCycle::print_on_with()
On Tue, 9 Aug 2022 09:19:54 GMT, Robbin Ehn wrote:
> I got this build problem on aarch64:
Thanks for giving this PR a spin. I pushed a fix for the aarch64 build problem
(seems weird that GHA did not catch it).
-
PR: https://git.openjdk.org/jdk/pull/9680
On Mon, 8 Aug 2022 18:29:54 GMT, Roman Kennke wrote:
> > I ran some test locally, 4 JDI fails and 3 JVM TI, all seems to fail in:
> > ```
> > #7 0x7f7cefc5c1ce in Thread::is_lock_owned
> > (this=this@entry=0x7f7ce801dd90, adr=adr@entry=0x1 > memory at address 0x1>) at
> >
On Mon, 8 Aug 2022 15:44:50 GMT, Robbin Ehn wrote:
> I ran some test locally, 4 JDI fails and 3 JVM TI, all seems to fail in:
>
> ```
> #7 0x7f7cefc5c1ce in Thread::is_lock_owned
> (this=this@entry=0x7f7ce801dd90, adr=adr@entry=0x1 memory at address 0x1>) at
>
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
On Mon, 8 Aug 2022 13:45:06 GMT, Roman Kennke wrote:
> The bar for acceptance for a brand new locking scheme with no fallback is
> extremely high and needs a lot of bake time and broad performance
> measurements, to watch for pathologies. That bar is lower if the scheme can
> be reverted to
On Mon, 8 Aug 2022 12:14:38 GMT, David Holmes wrote:
> The bar for acceptance for a brand new locking scheme with no fallback is
> extremely high and needs a lot of bake time and broad performance
> measurements, to watch for pathologies. That bar is lower if the scheme can
> be reverted to
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
On Sun, 7 Aug 2022 12:50:01 GMT, Roman Kennke wrote:
> > Happens when the main thread detaches itself upon VM exit. VM attempts to
> > release OMs that are owned by the finished main thread (side note: if that
> > is the sole surviving thread, maybe that step could be skipped?). That
> >
On Wed, 3 Aug 2022 07:17:51 GMT, Thomas Stuefe wrote:
> Happens when the main thread detaches itself upon VM exit. VM attempts to
> release OMs that are owned by the finished main thread (side note: if that is
> the sole surviving thread, maybe that step could be skipped?). That happens
>
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word.
This change replaces the current stack-locking implementation with a
fast-locking scheme that 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 Lilliput, because it
On Wed, 5 Oct 2022 22:49:20 GMT, Serguei Spitsyn wrote:
> The spec of JVM TI GetLocalXXX/SetLocalXXX functions is updated to require
> the target thread to be suspended. If not suspended then the
> JVMTI_ERROR_THREAD_NOT_SUSPENDED error code is returned by the implementation.
>
> The CSR is:
55 matches
Mail list logo
