> On Sep 8, 2020, at 11:30 PM, Kim Barrett wrote:
>
> I reviewed all of v4, not just the gc parts this time.
I guess it was v5 I was reviewing. There seems to be an inconsistency in
numbering.
Hi Egor,
Thank you for finding this problem. I created a new Jira issue [1] for that.
[1] https://bugs.openjdk.java.net/browse/JDK-8252933
Best regards,
Daniil
On 9/8/20, 8:31 AM, "Egor Ushakov" wrote:
Hi Daniil,
we have some tests checking the number of jdwp packets and they've
> On Sep 8, 2020, at 9:27 AM, David Holmes wrote:
> David Holmes has updated the pull request incrementally with one additional
> commit since the last revision:
>
> This is a simpler approach to use the static_cast. Changes:
> - Change C-style cast to static_cast and move function definitions
> On Sep 8, 2020, at 6:06 AM, David Holmes wrote:
>
> Just to be clear please wait for v5 to appear before reviewing.
I think you meant “v4”, i.e. the 5th zero-based version?
On Tue, 8 Sep 2020 06:48:03 GMT, Aleksey Shipilev wrote:
>> - enable parallel heap inspecton for ShenandoahHeap
>> - preliminary evaluation:
>> Time of jmap histo on (8GB heap with 4GB objects)
>> * before: 5.186s
>> * after : 1.698s
>
> Thanks, this looks interesting.
>
> I need m
On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote:
> continuing the review thread from here
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
>
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jt
On Mon, 7 Sep 2020 07:10:49 GMT, Christoph Göttschkes wrote:
> The test case already handles out of memory conditions, but not if the whole
> JVM crashes because of it.
>
> This PR has already been discussed on the mailing list:
> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-
Hi Richard,
I suspect this one fell off the radar due to the extended review period.
The actual review started last December (there was prior discussion
IIRC) and only seemed to get partial reviews. I only looked at some
parts. Robbin may have given things a deeper look, but seemed focused on
Thanks for the review Coleen!
David
On 9/09/2020 5:10 am, Coleen Phillimore wrote:
On Tue, 8 Sep 2020 19:07:01 GMT, Coleen Phillimore wrote:
David Holmes has updated the pull request incrementally with one additional
commit since the last revision:
This is a simpler approach to use the
On Tue, 8 Sep 2020 20:49:26 GMT, Leonid Mesnik wrote:
>> The test case already handles out of memory conditions, but not if the whole
>> JVM crashes because of it.
>>
>> This PR has already been discussed on the mailing list:
>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-Se
On Mon, 7 Sep 2020 07:10:49 GMT, Christoph Göttschkes wrote:
> The test case already handles out of memory conditions, but not if the whole
> JVM crashes because of it.
>
> This PR has already been discussed on the mailing list:
> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-
On Mon, 7 Sep 2020 07:10:49 GMT, Christoph Göttschkes wrote:
> The test case already handles out of memory conditions, but not if the whole
> JVM crashes because of it.
>
> This PR has already been discussed on the mailing list:
> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-
On Mon, 7 Sep 2020 07:10:49 GMT, Christoph Göttschkes wrote:
> The test case already handles out of memory conditions, but not if the whole
> JVM crashes because of it.
>
> This PR has already been discussed on the mailing list:
> https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-
On Tue, 8 Sep 2020 13:27:17 GMT, David Holmes wrote:
>> This is a rather large but generally simple cleanup.
>>
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after
>> checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner we
On Tue, 8 Sep 2020 19:07:01 GMT, Coleen Phillimore wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> This is a simpler approach to use the static_cast. Changes:
>> - Change C-style cast to static_cast and move func
Hello Marty,
Sure. I'd be happy if Serguei could review the change.
Thanks, Richard.
-Original Message-
From: Marty Thompson
Sent: Dienstag, 8. September 2020 18:55
To: Reingruber, Richard ; Daniel Daugherty
; serviceability-dev
; hotspot-compiler-...@openjdk.java.net;
Hotspot dev r
Hello Richard,
It would be good if Serguei Spitsyn could review before this is pushed.
Serguei is out this week. Can you wait until Serguei is back in the office the
week of Sept 14?
Regards,
Marty
> -Original Message-
> From: Reingruber, Richard
> Sent: Tuesday, September 8, 2020
Hi Dan,
I'd be very happy about a review from somebody on the Serviceability team. I
have asked for reviews many times (kindly I hope). And the change is for review
for more than a year now.
According to [1] I'd think all requirements to push are met already. But maybe I
missed something?
After
Hi Richard,
I haven't seen a review from anyone on the Serviceability team and I
think you should get a review from them since JVM/TI is involved.
Perhaps I missed it...
Dan
On 9/7/20 10:09 AM, Reingruber, Richard wrote:
Hi,
I would like to close the review of this change.
It has received a
Hi Daniil,
we have some tests checking the number of jdwp packets and they've
detected a regression here:
com.jetbrains.jdi.ObjectReferenceImpl#validateAssignment now always
requests referenceType (requiring one more jdwp packet if value is not
yet cached),
previously it happened only for arr
On Mon, 7 Sep 2020 14:14:28 GMT, Robbin Ehn wrote:
> When these two methods (set_frame_pop/clear_frame_pop) are called in a
> handshake the requesting thread will have lock
> the JvmtiThreadState_lock. But the thread executing one of these in the
> handshake may not be the owner.
> So we only c
> This is a rather large but generally simple cleanup.
>
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking
> "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a
> convenience function Thread::as_Java_thread(
On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote:
> continuing the review thread from here
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
>
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jt
On Tue, 8 Sep 2020 10:44:24 GMT, David Holmes wrote:
>> When these two methods (set_frame_pop/clear_frame_pop) are called in a
>> handshake the requesting thread will have lock
>> the JvmtiThreadState_lock. But the thread executing one of these in the
>> handshake may not be the owner.
>> So we
Hi Robbin,
On 8/09/2020 5:39 pm, Robbin Ehn wrote:
Hi David,
When these two methods (set_frame_pop/clear_frame_pop) are called in a
handshake the requesting thread will have lock
the JvmtiThreadState_lock. But the thread executing one of these in the
handshake may not be the owner.
Ouch! W
On Mon, 7 Sep 2020 14:14:28 GMT, Robbin Ehn wrote:
> When these two methods (set_frame_pop/clear_frame_pop) are called in a
> handshake the requesting thread will have lock
> the JvmtiThreadState_lock. But the thread executing one of these in the
> handshake may not be the owner.
> So we only c
Just to be clear please wait for v5 to appear before reviewing.
Thanks,
David
On 8/09/2020 7:34 pm, David Holmes wrote:
This is a rather large but generally simple cleanup.
We use a lot of raw C-style casts to "(JavaThread*)" typically after checking
"thread->is_Java_thread()". To simplify
th
> On Sep 8, 2020, at 3:00 AM, David Holmes wrote:
>
> On 8/09/2020 4:34 pm, Kim Barrett wrote:
>> […]
>> src/hotspot/share/runtime/thread.hpp
>> 507 const JavaThread* as_const_Java_thread() const;
>> This missed part of what I'd suggested. I don't think the "const" part
>> of the name is need
> This is a rather large but generally simple cleanup.
>
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking
> "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we introduce a
> convenience function Thread::as_Java_thread(
Hi David, our mail service did the wrong thing here.
This was a reply to your comment, so you should have been in To-field,
this quote above "Hi David" should not have been here, and this was a
reply your mail (via github comment).
Thanks, Robbin
On 2020-09-08 09:39, Robbin Ehn wrote:
On M
On Mon, 7 Sep 2020 23:07:13 GMT, Yasumasa Suenaga wrote:
>> When these two methods (set_frame_pop/clear_frame_pop) are called in a
>> handshake the requesting thread will have lock
>> the JvmtiThreadState_lock. But the thread executing one of these in the
>> handshake may not be the owner.
>> S
On 8/09/2020 4:34 pm, Kim Barrett wrote:
On Sep 8, 2020, at 12:09 AM, David Holmes wrote:
David Holmes has updated the pull request incrementally with one additional
commit since the last revision:
Used static_cast instead of raw C-style cast
Moved inline functions to thread.inline.hpp
U
32 matches
Mail list logo
