On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Tue, 30 Nov 2021 02:37:47 GMT, Coleen Phillimore wrote:
> This change seems to keep the test case in the bug from crashing in the
> ResourceMark destructor. We have a ResourceMark during stack walking in
> AsyncGetCallTrace. Also RegisterMap during jvmti shouldn't process oops, fix
> care
On Mon, 22 Nov 2021 13:49:02 GMT, Erik Österlund wrote:
> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is
> constructed right before running a parallel operation with a work gang, but
> freed in the destructor of the VM_HeapDumper. This means it is creat
On Tue, 23 Nov 2021 09:42:10 GMT, Per Liden wrote:
>> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is
>> constructed right before running a parallel operation with a work gang, but
>> freed in the destructor of the VM_HeapDumper. This means it is created on
>> one
The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is
constructed right before running a parallel operation with a work gang, but
freed in the destructor of the VM_HeapDumper. This means it is created on one
thread and deleted on another thread. This becomes a bit problema
On Mon, 23 Aug 2021 13:03:10 GMT, Coleen Phillimore wrote:
>> I moved nonleaf ranked locks to be leaf (or leaf+something). Many of the
>> leaf locks are safepoint_check_never. Segregating this rank into safepoint
>> checking and non-safepoint checking is left for a future RFE.
>> Tested with
On Tue, 1 Jun 2021 04:23:43 GMT, Leonid Mesnik wrote:
> Thank you for your prompt response. I meant that it makes sense to update
> comments for RegisterMap to mention this. Currently, the doc says how to use
> it and how to disable update:
>
> "Updating of the RegisterMap can be turned off by
On Tue, 1 Jun 2021 03:00:23 GMT, Leonid Mesnik wrote:
> Let me check with Erik if it makes sense to put more generic comments about
> the usage of stackwatermark frame processing in RegisterMap, frames etc.
> They can't be updated in an arbitrary thread state. It makes sense describe
> this i
On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote:
> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace
Looks good, but please test with ZGC before integrating.
-
Marked as reviewed by eosterlund (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/4217
On Fri, 21 May 2021 09:11:09 GMT, Stefan Karlsson wrote:
>> I'd like to propose a small adjustment to how we write .inline.hpp files, in
>> the hope to reduce include problems because of circular dependencies between
>> inline headers.
>>
>> This is a small, contrived example to show the probl
On Sat, 23 Jan 2021 03:23:58 GMT, Yasumasa Suenaga wrote:
>> I saw the exception as following when I chose "Monitor Cache Dump" menu on
>> HSDB:
>>
>> Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
>> at
>> jdk.hotspot.agent/sun.jvm.hotspot.ui.MonitorCache
On Thu, 24 Dec 2020 22:01:38 GMT, Erik Österlund wrote:
>> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the
>> likelihood of crashes during error reporting. Uses Threads_lock->try_lock()
>> for safety and restricts some reporting to when the
On Thu, 24 Dec 2020 17:33:21 GMT, Daniel D. Daugherty
wrote:
> A small robustness fix in ThreadsSMRSupport::print_info_on() to reduce the
> likelihood of crashes during error reporting. Uses Threads_lock->try_lock()
> for safety and restricts some reporting to when the Threads_lock has been
> ac
On Wed, 11 Nov 2020 15:23:15 GMT, Daniel D. Daugherty
wrote:
>> Our int types are really confused. AvgMonitorsPerThreadEstimate is defined
>> as an intx which is intptr_t and the range of it is 0..max_jint which is 0
>> .. 0x7fff . jint is long on windows (the problematic type) and int on
On Tue, 10 Nov 2020 02:35:17 GMT, Daniel D. Daugherty
wrote:
>> Changes from @fisk and @dcubed-ojdk to:
>>
>> - simplify ObjectMonitor list management
>> - get rid of Type-Stable Memory (TSM)
>>
>> This change has been tested with Mach5 Tier[1-3],4,5,6,7,8; no new
>> regressions.
>> Aurora Pe
On Sat, 7 Nov 2020 17:22:21 GMT, Daniel D. Daugherty wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 1520:
>>
>>> 1518: // deflated in this cycle.
>>> 1519: size_t deleted_count = 0;
>>> 1520: for (ObjectMonitor* monitor: delete_list) {
>>
>> I didn't realize C++ has a "fo
On Sat, 7 Nov 2020 17:11:42 GMT, Daniel D. Daugherty wrote:
>> src/hotspot/share/runtime/synchronizer.cpp line 94:
>>
>>> 92: // Find next live ObjectMonitor.
>>> 93: ObjectMonitor* next = m;
>>> 94: while (next != NULL && next->is_being_async_deflated()) {
>>
>> Nit: This loo
On Sat, 7 Nov 2020 17:01:42 GMT, Daniel D. Daugherty wrote:
>> src/hotspot/share/runtime/objectMonitor.cpp line 380:
>>
>>> 378: if (event.should_commit()) {
>>> 379: event.set_monitorClass(object()->klass());
>>> 380: event.set_address((uintptr_t)this);
>>
>> This looks wrong - the e
On Thu, 29 Oct 2020 12:44:58 GMT, Erik Österlund wrote:
> The imasm::remove_activation() call does not deal with safepoints very well.
> However, when the MethodExit JVMTI event is being called, we call into the
> runtime in the middle of remove_activation(). If the value being re
On Wed, 4 Nov 2020 13:22:57 GMT, Coleen Phillimore wrote:
>> For the GCs that call the num_dead notification in a pause it is much worse
>> than what we had. As I pointed out elsewhere, it used to be that tagmap
>> processing was all-in-one, as a single serial subtask taken by the first
>> thr
On Wed, 4 Nov 2020 13:32:07 GMT, Coleen Phillimore wrote:
>> I know of nothing that leads to "presumably during GC" being a requirement.
>> Having all pending events of some type occur before that type of event is
>> disabled seems like a reasonable requirement, but just means that event
>> di
On Tue, 3 Nov 2020 21:14:04 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 3018:
>>
>>> 3016: }
>>> 3017: // Later GC code will relocate the oops, so defer rehashing
>>> until then.
>>> 3018: tag_map->_needs_rehashing = true;
>>
>> This is
On Tue, 3 Nov 2020 17:49:38 GMT, Serguei Spitsyn wrote:
> Hi Erik,
>
> I'm not sure, if this fragment is still needed:
>
> ```
> 1620 if (state == NULL || !state->is_interp_only_mode()) {
> 1621 // for any thread that actually wants method exit, interp_only_mode
> is set
> 1622 retur
-Xint" ; done
>
> With my fix I can run this repeatedly without any more failures. I have also
> sanity checked the patch by running tier 1-5, so that it does not introduces
> any new issues on its own. I have also used Stefan's nice external GC
> stressing with jcmd
On Mon, 2 Nov 2020 21:00:23 GMT, Serguei Spitsyn wrote:
> Erik,
>
> Thank you for the update! It looks more elegant.
>
> One concern is that after the move of this fragment to the
> post_method_exit_inner:
>
> ```
> 1614 if (state == NULL || !state->is_interp_only_mode()) {
> 1615 // fo
-Xint" ; done
>
> With my fix I can run this repeatedly without any more failures. I have also
> sanity checked the patch by running tier 1-5, so that it does not introduces
> any new issues on its own. I have also used Stefan's nice external GC
> stressing with jcmd
On Tue, 3 Nov 2020 12:58:22 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>> ta
On Mon, 2 Nov 2020 16:22:57 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 345:
>>
>>> 343:
>>> 344: // Check if we have to process for concurrent GCs.
>>> 345: check_hashmap(false);
>>
>> Maybe add a comment stating the parameter name, as was done in other
On Mon, 2 Nov 2020 16:19:59 GMT, Coleen Phillimore wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Coleen CR1: Refactoring
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1570:
On Mon, 2 Nov 2020 12:50:23 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 954:
>>
>>> 952: o->klass()->external_name());
>>> 953: return;
>>> 954: }
>>
>> Why is this done as a part of this RFE? Is this a bug fix that should be
>>
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>> ta
On Sat, 31 Oct 2020 09:54:09 GMT, Serguei Spitsyn wrote:
> Hi Erik,
>
> Nice discovery! Indeed, this is a long standing issue. It looks good in
> general.
> I agree with Coleen, it would be nice if there is an elegant way to move the
> oop_result saving/restoring code to InterpreterRuntime::po
On Fri, 30 Oct 2020 14:09:46 GMT, Erik Österlund wrote:
>> Oh that's actually horrible. I wonder if it's possible to hoist saving the
>> result oop into the InterpreterRuntime entry. And pass the Handle into
>> JvmtiExport::post_method_exit().
>
> I tri
On Sat, 31 Oct 2020 09:54:09 GMT, Serguei Spitsyn wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Coleen CR1: Refactoring
>
> Hi Erik,
>
> Nice discovery! Indeed, this is a l
-Xint" ; done
>
> With my fix I can run this repeatedly without any more failures. I have also
> sanity checked the patch by running tier 1-5, so that it does not introduces
> any new issues on its own. I have also used Stefan's nice external GC
> stressing with jcmd
On Fri, 30 Oct 2020 16:02:41 GMT, Erik Österlund wrote:
> > Hi Erik,
> > is it possible for GC to mistake a primitive value for a reference when
> > posting the exit event?
> > My understanding is: we are at a random bci of a method that is forced to
> > return
On Fri, 30 Oct 2020 14:20:42 GMT, Erik Österlund wrote:
>> Marked as reviewed by dlong (Reviewer).
>
>> I think you've discovered JDK-6449023. And you fix looks like the workaround
>> I tried:
>> https://bugs.openjdk.java.net/browse/JDK-644902
On Fri, 30 Oct 2020 08:49:08 GMT, Dean Long wrote:
>> The imasm::remove_activation() call does not deal with safepoints very well.
>> However, when the MethodExit JVMTI event is being called, we call into the
>> runtime in the middle of remove_activation(). If the value being returned is
>> an
On Fri, 30 Oct 2020 00:58:06 GMT, Coleen Phillimore wrote:
>> Thanks for having a look coleen. In fact, not doing the JRT_BLOCK for the
>> exception entry is intentional, because that entry goes through a different
>> JRT_ENTRY (not JRT_BLOCK_ENTRY), that already transitions. So if I do the
>>
On Thu, 29 Oct 2020 21:23:12 GMT, Coleen Phillimore wrote:
>> The imasm::remove_activation() call does not deal with safepoints very well.
>> However, when the MethodExit JVMTI event is being called, we call into the
>> runtime in the middle of remove_activation(). If the value being returned i
On Fri, 23 Oct 2020 10:25:43 GMT, Erik Österlund wrote:
> The escape barrier reallocates scalarized objects potentially deep into the
> stack of a remote thread. Each allocation can safepoint, causing referenced
> frames to be invalid. Some sprinklings were added that deal with th
The imasm::remove_activation() call does not deal with safepoints very well.
However, when the MethodExit JVMTI event is being called, we call into the
runtime in the middle of remove_activation(). If the value being returned is an
object type, then the top-of-stack contains the oop. However, th
On Wed, 28 Oct 2020 19:44:33 GMT, Serguei Spitsyn wrote:
> Hi Erik and Richard,
>
> Changes in the serviceability files looks fine.
>
> Thanks,
>
> Serguei
>
>
Thanks for the review Serguei!
-
PR: https://git.openjdk.java.net/jdk/pull/832
easy and intuitive to understand why this works
> correctly. The RAII object basically just has to cover the code block that
> pokes at the remote stack and goes in and out of safepoints, arbitrarily.
> Arguably, this escape barrier doesn't need to be blazingly fast, and can
>
On Mon, 26 Oct 2020 15:19:51 GMT, Richard Reingruber wrote:
>>> Hi Erik, the last commit in
>>> https://github.com/reinrich/jdk/commits/pr-832-with-better-encapsulation
>>> would be the refactoring I would like to do. It removes the code not
>>> compliant with concurrent thread stack processin
On Thu, 22 Oct 2020 08:42:40 GMT, Richard Reingruber wrote:
>> Stack frames are counted beginning at 0. The top frame has depth 0. So
>> object deoptimization happens in the top frame.
>>
>> Still the used method is not optimal because it assumes that objects of
>> frames within the given dept
On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote:
>> The main point of this change-set is to make it easier to implement S/R on
>> top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the
>> handshake functionality).
>> But we also remove some complicated
On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote:
>> The main point of this change-set is to make it easier to implement S/R on
>> top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the
>> handshake functionality).
>> But we also remove some complicated
On Wed, 21 Oct 2020 08:40:47 GMT, Robbin Ehn wrote:
>> The main point of this change-set is to make it easier to implement S/R on
>> top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the
>> handshake functionality).
>> But we also remove some complicated
On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote:
> I hit the following assert in some tests runs that I've been doing:
> # Internal Error
> (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67),
> pid=828170,
> tid=828734 # assert(processing_started()) fail
On Tue, 22 Sep 2020 11:43:41 GMT, Erik Österlund wrote:
> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
> Processing" (cf.
> https://openjdk.java.net/jeps/376).
> Basically, this patch modifies the epilog safepoint when returning from a
> fram
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Wed, 7 Oct 2020 18:03:10 GMT, Stuart Monteith wrote:
> I've been reviewing this and stepping through the debugger. It looks OK to me.
Thanks for the review Stuart.
-
PR: https://git.openjdk.java.net/jdk/pull/296
On Tue, 6 Oct 2020 12:18:39 GMT, Erik Österlund wrote:
>>> Hi Erik,
>>> Can you give an overview of the use of the "poll word" and its relation to
>>> the "poll page" please?
>>> Thanks,
>>> David
>>
>> Hi David,
&g
On Tue, 6 Oct 2020 07:35:16 GMT, Erik Österlund wrote:
>> Hi Erik,
>> Can you give an overview of the use of the "poll word" and its relation to
>> the "poll page" please?
>> Thanks,
>> David
>
>> Hi Erik,
>> Can you give an o
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Tue, 6 Oct 2020 02:57:00 GMT, David Holmes wrote:
> Hi Erik,
> Can you give an overview of the use of the "poll word" and its relation to
> the "poll page" please?
> Thanks,
> David
Hi David,
Thanks for reviewing this code.
There are various polls in the VM. We have runtime transitions, in
On Tue, 6 Oct 2020 02:40:12 GMT, David Holmes wrote:
>> Erik Österlund has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains 16 commits:
>> - Review: Deal with new assert from mainline
>>
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Tue, 6 Oct 2020 02:26:16 GMT, David Holmes wrote:
>> Erik Österlund has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains 16 commits:
>> - Review: Deal with new assert from mainline
>>
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Thu, 1 Oct 2020 09:50:45 GMT, Erik Österlund wrote:
>> Marked as reviewed by rehn (Reviewer).
>
>> _Mailing list message from [Kim Barrett](mailto:kim.barr...@oracle.com) on
>> [hotspot-dev](mailto:hotspot-...@openjdk.java.net):_
>> I've only looked at scatte
On Tue, 29 Sep 2020 16:09:48 GMT, Robbin Ehn wrote:
>> Erik Österlund has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains 12 commits:
>> - Review: Move barrier detach
>> - Review: Remove assert
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Tue, 29 Sep 2020 14:39:23 GMT, Zhengyu Gu wrote:
>>> Hi Erik,
>>>
>>> I have been playing with this patch for past a few days. Great work!
>>>
>>> I found that this patch seems to break an early assumption.
>>> We have a comment in JavaThread::exit() says:
>>>
>>> // We need to cache the
On Tue, 29 Sep 2020 13:13:55 GMT, Zhengyu Gu wrote:
>> I see; thank you for the explanation.
>
> Hi Erik,
>
> I have been playing with this patch for past a few days. Great work!
>
> I found that this patch seems to break an early assumption.
> We have a comment in JavaThread::exit() says:
>
On Tue, 29 Sep 2020 09:22:18 GMT, Roman Kennke wrote:
>> I've also has problems with this assert in the past, and I think that the
>> underlying assumption of the assert is wrong.
>> I would not miss it.
>
> IMO it's ok to remove it.
> However, it can be argued that is_in() should not check for
On Mon, 28 Sep 2020 17:20:49 GMT, Aleksey Shipilev wrote:
>> We call frame::oops_do from the GC to make bad oops good. But the oops_do
>> logic assers the oop is good *before* the
>> closure is applied. Every time I do something, I run i to issues with this
>> assert. It seems like an invalid a
On Mon, 28 Sep 2020 15:22:55 GMT, Roman Kennke wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review: Albert CR2 and defensive programming
>
> src/hotspot/share/compiler/oopMap.c
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Thu, 24 Sep 2020 21:20:19 GMT, Albert Mingkun Yang wrote:
> Thank you for the comments and diagrams; they make the code much more
> digestible. From that diagram, I get the
> impression that the watermark is associated with stack pointer, so it should
> be 1:1 relation, but `class Thread`
>
On Thu, 24 Sep 2020 14:28:44 GMT, Coleen Phillimore wrote:
> To be clear, my comments about boolean parameters to vframeStream/RegMap can
> be addressed in a follow up RFE. That
> would be better.
Thanks for reviewing Coleen!
-
PR: https://git.openjdk.java.net/jdk/pull/296
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Thu, 24 Sep 2020 12:49:06 GMT, Coleen Phillimore wrote:
>> Erik Österlund has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains seven commits:
>> - Review: Per CR 1
>> - Merge branch 'maste
On Thu, 24 Sep 2020 12:45:00 GMT, Coleen Phillimore wrote:
>> Erik Österlund has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains seven commits:
>> - Review: Per CR 1
>> - Merge branch 'maste
On Thu, 24 Sep 2020 12:32:36 GMT, Nils Eliasson wrote:
> I did a pre-reviewed of the compiler parts, and have now done a second
> reading.
>
> The compiler parts looks good!
Thanks for the review, Nils.
-
PR: https://git.openjdk.java.net/jdk/pull/296
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Thu, 24 Sep 2020 11:29:36 GMT, Per Liden wrote:
> I had also pre-reviewed, but did a final semi-quick review. Looks good
> overall. Just found a couple of minor nitpicks.
Thansk for the review Per. I uploaded fixes to your nitpicks.
-
PR: https://git.openjdk.java.net/jdk/pull/2
On Thu, 24 Sep 2020 12:23:50 GMT, Erik Österlund wrote:
> Looks good.
Thanks for the review Robbin.
-
PR: https://git.openjdk.java.net/jdk/pull/296
On Wed, 23 Sep 2020 15:45:12 GMT, Albert Mingkun Yang wrote:
>> Marked as reviewed by stefank (Reviewer).
>
> Given names like `StackWatermarkSet::lowest_watermark`, I wonder if some
> diagrams could be provided in the code
> comments for `class StackWatermarks` so that readers will have the cor
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Wed, 23 Sep 2020 12:59:40 GMT, Erik Österlund wrote:
>> src/hotspot/share/runtime/stackWatermarkSet.cpp line 112:
>>
>>> 110: return;
>>> 111: }
>>> 112: verify_poll_context();
>>
>> There's a verfy_poll_context here, but no
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Wed, 23 Sep 2020 10:27:05 GMT, Stefan Karlsson wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review: SteafanK CR 2
>
> I've gone over the entire patch, but I'm le
On Wed, 23 Sep 2020 08:33:20 GMT, Erik Österlund wrote:
>> src/hotspot/share/compiler/oopMap.cpp line 243:
>>
>>> 241: } else {
>>> 242: all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl);
>>> 243: }
>>
>> I wonder if we s
t) is only performed
> by the thread itself. So sliding the
> watermark up will require one runtime call for a thread to note that nothing
> needs to be done, and then update the poll
> word accordingly. Downgrading the poll word concurrently by other threads was
> simply not wort
On Wed, 23 Sep 2020 08:51:08 GMT, Stefan Karlsson wrote:
>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a
>> frame (supporting interpret
On Wed, 23 Sep 2020 07:39:55 GMT, Stefan Karlsson wrote:
>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a
>> frame (supporting interpret
On Wed, 23 Sep 2020 07:17:31 GMT, Stefan Karlsson wrote:
>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a
>> frame (supporting interpret
On Tue, 22 Sep 2020 13:45:16 GMT, Stefan Karlsson wrote:
>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a
>> frame (supporting interpret
On Tue, 22 Sep 2020 13:17:05 GMT, Stefan Karlsson wrote:
>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a
>> frame (supporting interpret
On Tue, 22 Sep 2020 14:38:05 GMT, Daniel D. Daugherty
wrote:
> @fisk - You are missing testing information for this PR.
Sorry about that. I have performed testing with ZGC enabled from tier1-7
(multiple times), and standard testing
tier1-5. I have also stress tested the change with gc-test-sui
This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
Processing" (cf.
https://openjdk.java.net/jeps/376).
Basically, this patch modifies the epilog safepoint when returning from a frame
(supporting interpreter frames, c1, c2,
and native wrapper frames), to compare the stack point
On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty
wrote:
>> This RFE is to migrate the following field to OopStorage:
>>
>> class ObjectMonitor {
>>
>> void* volatile _object; // backward object pointer - strong root
>>
>> Unlike the previous patches in this series, there are a lot of c
On Wed, 16 Sep 2020 00:21:02 GMT, Serguei Spitsyn wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rkennke, coleenp, fisk CR - delete random assert() that knows too much
>> about markWords.
>
> Marked as rev
On Mon, 14 Sep 2020 20:51:58 GMT, Roman Kennke wrote:
>> @fisk - please chime in here...
>
> I agree. Also, the assert becomes true somewhat obviously because of its
> first clause, which is already guaranteed
> because of its placement in the surrounding else-branch (unless something
> really
On Mon, 14 Sep 2020 14:24:02 GMT, Roman Kennke wrote:
> > @rkennke - Thanks for the review. I believe @fisk is going to address
> > your comments.
>
> Actually, if I understand it correctly, OopStorage already gives us full
> barriers, so we should be covered, and we can
> simply revert JDK-825
On Mon, 14 Sep 2020 02:01:58 GMT, David Holmes wrote:
> Not sure about the JVM TI changes!
Here is a generic comment. You mention that the specification doesn't make it
clear whether the roots reported are
strong or weak. This is true. There is no mention about roots being strong or
weak here.
On Mon, 14 Sep 2020 14:15:41 GMT, Erik Österlund wrote:
>> @rkennke - Thanks for the review. I believe @fisk is going to address
>> your comments.
>
> Hi Kim,
>
> Here is a partial reply to your review. Thanks for reviewing!
> Hmm seems like your email was only sent
1 - 100 of 136 matches
Mail list logo
