Hi Serguei,
Thanks for the review.
/Erik
On 2017-11-28 06:43, serguei.spit...@oracle.com wrote:
Hi Erik,
This looks good to me.
Thanks,
Serguei
On 11/27/17 05:22, Daniel D. Daugherty wrote:
Adding serviceability-dev@... since this is JVM/TI related...
Dan
On 11/27/17 6:28 AM, Erik
Hi Roman,
A few things:
1) The code uses the "mgr" short name for "manager" in a bunch of names.
I would be happy if we could write out the whole thing instead of the
abbreviation.
2) It would be great if a generation would have a pointer to its
manager, so we do not have to pass around the
Hi Roman,
This looks better now. Nice job.
I wonder though, is it possible to extract the creation of managers and
pools to a separate function for each collected heap?
Now I see managers are created in e.g. CMS constructor, and the pools
are created in CMSHeap::initialize(). Perhaps
Hi,
Some replies...
On 2017-11-21 18:36, Daniel D. Daugherty wrote:
Thanks for keeping all the OpenJDK aliases!
On 11/21/17 12:24 PM, coleen.phillim...@oracle.com wrote:
On 11/21/17 11:28 AM, Daniel D. Daugherty wrote:
On 11/20/17 3:12 PM, coleen.phillim...@oracle.com wrote:
I can't
Hi Dan,
On 2017-11-22 13:53, Daniel D. Daugherty wrote:
On 11/22/17 4:07 AM, Erik Österlund wrote:
Hi,
Some replies...
On 2017-11-21 17:28, Daniel D. Daugherty wrote:
Hi Coleen!
Thanks for making time to review the Thread-SMR stuff again!!
I have added back the other three OpenJDK aliases
Hi,
Some replies...
On 2017-11-21 17:28, Daniel D. Daugherty wrote:
Hi Coleen!
Thanks for making time to review the Thread-SMR stuff again!!
I have added back the other three OpenJDK aliases... This review is
being done on _four_ different OpenJDK aliases.
As always, replies are embedded
Hi Roman,
Looks good now. Thanks for doing this.
Thanks,
/Erik
On 2017-11-28 22:26, Roman Kennke wrote:
Hi Erik,
thank you for reviewing!
You are right. I think this is a leftover from when we tried to pass
the GCMemoryManager* into the Generation constructor. The way it is
done now
Hi Roman,
Looks good.
You do need a class GCMemoryManager; declaration in generation.hpp to
build without precompiled headers though.
I do not need a new webrev for that change.
Thanks,
/Erik
On 2017-11-30 15:22, Roman Kennke wrote:
Hi David,
I added the tag as you proposed:
Differential:
Hi JC,
I have looked through your changes.
In threadLocalAllocBuffer.cpp:
349 HeapWord* ThreadLocalAllocBuffer::allocate_sampled_object(size_t
size) {
350 Thread* thread = myThread();
351 thread->tlab().set_back_allocation_end();
352 HeapWord* result =
Hi Stefan,
Looks good.
Thanks,
/Erik
On 2018-05-31 15:53, Stefan Karlsson wrote:
Hi all,
Please review this patch to lower the minimum number of heap memory
pools in MemoryTest.java.
http://cr.openjdk.java.net/~stefank/8204173/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8204173
Hi Stefan,
Looks good.
Thanks,
/Erik
On 2018-05-31 15:38, Stefan Karlsson wrote:
Hi all,
Please review this patch to deal with the case when all available
MemoryPoolMXBeans support usage thresholds.
http://cr.openjdk.java.net/~stefank/8204170/webrev.01/
Hi JC,
Hope I am reviewing the right version of your work. Here goes...
src/hotspot/share/gc/shared/collectedHeap.inline.hpp:
159 AllocTracer::send_allocation_outside_tlab(klass, result, size
* HeapWordSize, THREAD);
160
161 THREAD->tlab().handle_sample(THREAD, result, size);
162
to do
it or add the support to the assembly side to handle this correctly.
What do you think?
I support removing TlabFastRefill, but I think it is good to not depend
on that happening first.
Now, below, inlined are my answers:
On Fri, Feb 2, 2018 at 8:44 AM, Erik Österlund
<erik.ost
all comments in one. I
apologize for that :)
On Mon, Feb 12, 2018 at 6:05 AM, Erik Österlund
<erik.osterl...@oracle.com <mailto:erik.osterl...@oracle.com>> wrote:
Hi JC,
Sorry for the delayed reply.
Inlined answers:
On 2018-02-06 00:04, JC Beyler
Hi Coleen,
Thank you for moving this stuff out of the class unloading path.
One tiny question... would it be possible to have
ClassLoaderDataGraph::should_clean_metaspaces() not have side effects,
and make the resetting explicit? I always get confused when getters have
side effects. Or maybe
Hi Robbin,
Looks good.
Thanks,
/Erik
On 2018-10-26 16:33, Robbin Ehn wrote:
Hi, please review.
When the VM thread executes a handshake it uses different ThreadsLists
during
the execution. A JavaThread that is armed for the handshake when it is
already
in the exit path in VM will cancel the
Hi Coleen,
Seems like the recreate_old_table() should be called reset_old_table()
as it does not really create anything.
The CodeCache::mark_all_nmethods_for_deoptimization function seems like
a general facility. I don't think I like passing in a boolean if class
redefinition-specific stuff
Hi Coleen,
Looks good. Thanks for doing this!
/Erik
On 2019-03-15 15:58, coleen.phillim...@oracle.com wrote:
From some offline feedback, I changed the name of has_evol_ics =>
has_evol_metadata and a couple of other small things. I reran this
though builds and tier1 tests.
Incremental:
Hi Stefan,
Looks good!
Thanks,
/Erik
On 2019-02-15 20:25, Stefan Karlsson wrote:
Testing showed that the re-enabling of the retiring of TLABs was
broken. This has been fixed with this patch:
http://cr.openjdk.java.net/~stefank/8218922/webrev.03.delta
Hi Stefan,
Given that the remark from Jini is fixed, this looks good. I don't need
another webrev.
Thanks,
/Erik
On 2019-02-11 19:09, Stefan Karlsson wrote:
Hi Jini,
On 2019-02-11 19:00, Jini George wrote:
Hi Stefan,
Looks good to me overall. One point though.
physicalFieldOffset =
Hi Stefan,
Looks good.
Thanks,
/Erik
On 2019-02-11 09:13, Stefan Karlsson wrote:
Hi all,
Please review this patch to remove the broken implementation of
CollectedHeap used() and capacity() and instead force all GCs to provide
their own implementations.
Hi Stefan,
This looks good and trivial.
Thanks,
/Erik
On 2019-02-11 08:47, Stefan Karlsson wrote:
Hi all,
I propose this simple change to use the concrete class as the return
type of VMObjectFactory.newObject.
https://cr.openjdk.java.net/~stefank/8218731/webrev.01
Hi Stefan,
Looks good.
Thanks,
/Erik
On 2019-02-11 13:36, Stefan Karlsson wrote:
Hi all,
Please review this patch to add support for large bitmaps in the SA.
http://cr.openjdk.java.net/~stefank/8218743/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8218743
I've added a minimal
Hi Stefan,
Looks good. One thing though...
At VMOopHandle.java line 38:
* Remove weird double indentation
* Remove weird double semicolon
* Use Field instead of AddressField
I don't think I need another webrev.
Thanks,
/Erik
On 2019-02-11 09:39, Stefan Karlsson wrote:
Hi all,
Please
Hi Stefan,
At ZExternalBitMap line 22:
* Maybe add a bounds check for offsets < 0 as well.
At ZExternalBitMap line 45:
* Remove weird whitespace in argument list.
* Consider inverting the condition to early exit. Don't mind if you
choose to do that or not.
Otherwise looks good. Don't need
Hi Stefan,
I think this makes things better. I like the cleanups and I like the
partial support for heap parsing. I think we should bring this in, and
it looks good to me.
Of course we can always improve this further at some point in the future
to deal with broken Klass pointers better.
Hi Dan,
Thanks for picking this up. The change looks good.
However, when reviewing this, I looked at the code for actually
restoring the table (ignore/notice safepoints). It copies the dispatch
table for the interpreter. There is a comment stating it is important
the copying is atomic for
Holmes wrote:
Hi Erik,
On 4/07/2019 5:10 pm, Erik Österlund wrote:
Hi Dan,
Thanks for picking this up. The change looks good.
However, when reviewing this, I looked at the code for actually
restoring the table (ignore/notice safepoints). It copies the
dispatch table for the interpreter
Hi David,
On 2019-07-23 09:34, David Holmes wrote:
Hi Erik,
On 23/07/2019 5:10 pm, Erik Österlund wrote:
Hi Martin,
1) In the x86_64 assembly, you can combine the movl; testl; into a
single test instruction with one memory operand to the counter, and
one immediate zero.
2) If libjvm.so
Hi Martin,
1) In the x86_64 assembly, you can combine the movl; testl; into a
single test instruction with one memory operand to the counter, and one
immediate zero.
2) If libjvm.so maps in far away, then the movl taking an
ExternalAddress, will actually scratch rscratch1, which is r10.
Hi Martin,
The new webrev looks good.
Note though the following though... it looks like the AArch64 code
doesn't do appropriate fencing if the field is volatile.
The normal JNI accessor goes through thread transitions causing the
following semantics:
fence()
load
fence()
Which is more than
Hi Coleen,
Still good BTW!
Thanks,
/Erik
On 2019-11-25 14:47, coleen.phillim...@oracle.com wrote:
Thanks for the code review, Serguei!
Coleen
On 11/22/19 6:34 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
+1
Thanks,
Serguei
On 11/22/19 14:53, Daniel D. Daugherty wrote:
Hi Zhengyu,
Can’t your barriers just perform a NULL check on the forwardee instead?
forwardee() == NULL never means forwarded, does it? Both JVMTI and JFR just
”mark” the markWord, leaving its forwardee == NULL.
That way you can solve the issue in the backend instead, and we don’t need to
do
Hi Zhengyu,
> On 24 Feb 2020, at 21:59, Zhengyu Gu wrote:
>
> Hi Erik,
>
>> On 2/24/20 12:04 PM, Erik Österlund wrote:
>> Hi Zhengyu,
>> Can’t your barriers just perform a NULL check on the forwardee instead?
>> forwardee() == NULL never means forward
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
On Mon, 14 Sep 2020 13:48:25 GMT, Daniel D. Daugherty
wrote:
>> @kimbarrett - Thanks for the review. I believe @fisk is going to
>> address your comments.
>
> @rkennke - Thanks for the review. I believe @fisk is going to address
> your comments.
Hi Kim,
Here is a partial reply to your review.
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
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
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
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 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
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
&g
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
&g
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,
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 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 yo
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())
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, 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, 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 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 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
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 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 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
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
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
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: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, _nothing_cl);
>>> 243: }
>>
>> I wonder if we
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 upda
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 leavin
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 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
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
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 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:
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 'master' in
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
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
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
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
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
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 scattered p
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
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
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 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
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 'master' in
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, 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
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
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
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
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
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
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
> afford kee
Hi Coleen,
Looks good. One thing though: in the replace() function, assert that the
obj_ptr != NULL instead of silently doing nothing.
Don't need another webrev.
Thanks,
/Erik
On 2020-07-22 22:55, coleen.phillim...@oracle.com wrote:
Summary: Add an assert to OopHandle assigment operator to
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
>
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 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
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 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
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
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
1 - 100 of 136 matches
Mail list logo
