Thanks for making the changes, Aleksey. The changes look good.
Thanks,
Jini.
On 6/5/2018 9:16 PM, Aleksey Shipilev wrote:
Hi Jini,
Thanks for taking a look, see comments inline.
On 06/01/2018 10:13 AM, Jini George wrote:
==> share/classes/sun/jvm/hotspot/oops/ObjectHeap.java
444 live
On Thu, Jun 7, 2018 at 7:14 AM, David Holmes wrote:
> Hi Thomas,
>
> On 7/06/2018 2:36 PM, Thomas Stüfe wrote:
>>
>> Ping...
>>
>> may I please have a second review?
>
>
> Seems fine in terms of overall code structure etc. I can't comment on the
> output produced as such. :)
>
> Some minor code-st
Hi Thomas,
On 7/06/2018 2:36 PM, Thomas Stüfe wrote:
Ping...
may I please have a second review?
Seems fine in terms of overall code structure etc. I can't comment on
the output produced as such. :)
Some minor code-style nits (just to prove I read it):
- inconsistent placement of opening {
Ping...
may I please have a second review?
For your convenience, the latest webrev with Coleen's requests worked in is:
http://cr.openjdk.java.net/~stuefe/webrevs/8203682-jcmd-print-classloader-hierarchy/webrev.01/webrev/
JBS issue: https://bugs.openjdk.java.net/browse/JDK-8203682
Thank you ve
On 7/06/2018 7:58 AM, Stuart Marks wrote:
Serguei, great! Thanks.
All, I've updated the webrev to with changes to
threadPrimitiveDeprecation.html to remove the sections that mention the
removed methods.
That reads much better!
Thanks,
David
http://cr.openjdk.java.net/~smarks/reviews/82042
Ok, I'll update the comment. I think I'll still mention and CDS and
maybe add AOT as examples.
thanks,
Chris
On 6/6/18 7:01 PM, David Holmes wrote:
Hi Chris,
Great sleuthing on this one and thanks for explaining things for me in
the bug report!
The fix you have addresses the problem obser
Hi Chris,
Great sleuthing on this one and thanks for explaining things for me in
the bug report!
The fix you have addresses the problem observed with the "vm info"
string. One small request, can you update this comment in thread.cpp please:
// We need this for ClassDataSharing - the initia
On 6/6/18 17:37, David Holmes wrote:
Looks okay.
I didn't mention the spelling issues because they were everywhere and
would just have obscured the fix initially. Once you start cleaning up
these old tests you might never stop. ;-)
It is why I'm against filing a bug on the Debugee class. :
Looks okay.
I didn't mention the spelling issues because they were everywhere and
would just have obscured the fix initially. Once you start cleaning up
these old tests you might never stop. ;-)
Thanks,
David
On 7/06/2018 6:04 AM, Daniil Titov wrote:
Hi Serguei,
I updated the webrev to cor
Hi Chris,
It looks good.
Thank you for taking care about this!
Thanks,
Serguei
On 6/6/18 15:24, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8203329
http://cr.openjdk.java.net/~cjplummer/8203329/webrev.00/
The native version of the java.
Thank you, Dan!
Serguei
On 6/6/18 16:52, Daniel D. Daugherty wrote:
On 6/6/18 6:44 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Thank you for the review!
As always, you're welcome.
The fix has been already pushed.
Yup. I noticed that after I finished the review.
I hope, it is Okay
On 6/6/18 6:44 PM, serguei.spit...@oracle.com wrote:
Hi Dan,
Thank you for the review!
As always, you're welcome.
The fix has been already pushed.
Yup. I noticed that after I finished the review.
I hope, it is Okay with you.
Of course. I'm playing catch up after being off-the-air for
Hi Dan,
Thank you for the review!
The fix has been already pushed.
I hope, it is Okay with you.
Are you Okay with the release note sub-task? :
https://bugs.openjdk.java.net/browse/JDK-8192891
It tells:
A NotifyFramePop request was only cleared if the
JVMTI_EVENT_FRAME_POP is enabled.
No
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8203329
http://cr.openjdk.java.net/~cjplummer/8203329/webrev.00/
The native version of the java.vm.info property was getting out of sync
with the java version. Details can be found here:
https://bugs.openjdk.java.ne
Hi, Stuart.
http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.2/
The simple update to remove references to the removed methods looks good.
Thanks,
iris
From: Stuart Marks
Sent: Wednesday, June 6, 2018 2:58 PM
To: Serguei Spitsyn ; David Holmes
; Alan Bateman ; Iris Clark
Stuart,
The update looks good.
Thanks,
Serguei
On 6/6/18 14:58, Stuart Marks wrote:
Serguei, great! Thanks.
All, I've updated the webrev to with changes to
threadPrimitiveDeprecation.html to r
Serguei, great! Thanks.
All, I've updated the webrev to with changes to threadPrimitiveDeprecation.html
to remove the sections that mention the removed methods.
http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.2/
s'marks
On 6/6/18 2:37 PM, serguei.spit...@oracle.com wrote:
Stuart,
Stuart,
Thank you for explanation!
I'm Okay with the fix it is now.
Thanks,
Serguei
On 6/6/18 14:02, Stuart Marks wrote:
On 6/6/18 10:58 AM, serguei.spit...@oracle.com wrote:
But the fix below
Yeah, maybe it's better simply to remove the mentions of the methods that are
being removed. I'll do so.
I note that there are many other updates that could be done (the examples use
applets!) but I think that's a task for another time.
s'marks
On 6/6/18 9:28 AM, Iris Clark wrote:
Hi, Stua
On 6/6/18 10:58 AM, serguei.spit...@oracle.com wrote:
But the fix below is not clear to me:
http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/src/hotspot/share/prims/jvmti.xml.udiff.html
Stop Thread
- Send the specified asynchronous exception to the specified
On 5/23/18 3:33 PM, Alex Menkov wrote:
Hi all,
Please take a look at a fix for
https://bugs.openjdk.java.net/browse/JDK-8187289
webrev: http://cr.openjdk.java.net/~amenkov/notifyFramePop/webrev/
src/hotspot/share/prims/jvmtiEventController.cpp
No comments.
src/hotspot/share/prims/jvmtiEx
Hi Daniil,
Looks good.
Thank you for fixing these!
I don't think we have to care about the shared classes at this
point.
Thanks,
Serguei
On 6/6/18 13:04, Daniil Titov wrote:
Hi Serguei,
I updated the webrev to correct typo for debuggee instances as well. However,
I didn’t rename the shared class nsk.share.jdi.Debugee and
nsk.share.jdi.Binder.bindToDebugee method since I am not sure it should be
done as a part of this fix. I would suggest filing a separate issu
On 6/6/18 11:52 AM, Gary Adams wrote:
On 6/6/18, 2:20 PM, Chris Plummer wrote:
If that were the case, shouldn't
the delay be added to sendCommand() instead?
I'm still a bit unsure about how this sequence is sup
It looks good.
There are also instances of "debugee" but they are
because of the supporting class named "Debugee".
Thanks,
Serguei
On 6/6/18 12:09, Daniil Titov wrote:
Thank you, Serguei and David,
Thank you, Serguei and David, for reviewing this change.
Please review a new version of the change that corrects the diagnostic message
as Serguei suggested and fixes typos.
Webrev: http://cr.openjdk.java.net/~dtitov/8203033/webrev.03
Issue: https://bugs.openjdk.java.net/browse/JDK-8203
On 6/6/18, 2:20 PM, Chris Plummer wrote:
If that were the case, shouldn't the delay be added to sendCommand()
instead?
I'm still a bit unsure about how this sequence is suppose to work in
the first place:
sendCommand(command);
return receiveReply(startPos, compoundPromptOnl
Hi Daniil,
It looks good.
One minor comment.
http://cr.openjdk.java.net/~dtitov/8203033/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jdi/TypeComponent/isSynthetic/issynthetic002.java.frames.html
153 log.complain("debuger FAILURE 3> Meth
If that were the case, shouldn't the
delay be added to sendCommand() instead?
I'm still a bit unsure about how this sequence is suppose to work
in the first place:
sendCommand(command);
return receiveReply(startPos, com
Hi Stuart,
The Serviceability changes look good.
But the fix below is not clear to me:
http://cr.openjdk.java.net/~smarks/reviews/8204243/webrev.1/src/hotspot/share/prims/jvmti.xml.udiff.html
Stop Thread
-Send the specif
On Wed, Jun 6, 2018 at 6:18 PM, Kirk Pepperdine
wrote:
>
>> On Jun 6, 2018, at 6:05 PM, Thomas Stüfe wrote:
>>
>> Dear all,
>>
>> may I please have feedback and if possible reviews for this small addition:
>
>
> I can see the need to visualize this but the output looks easily parsable so
> it al
On 6/6/18, 1:26 PM, Chris Plummer wrote:
Hi Gary,
I thought the issue was having 1 command like "cont" or "step"
producing two prompts, and the first prompt ending up in the middle of
the output for the breakpoint. So instead of:
main[1] cont
main[1]
"Breakpoint hit:"
main[1]
We sometimes
Hi Gary,
I thought the issue was having 1 command like "cont" or "step" producing
two prompts, and the first prompt ending up in the middle of the output
for the breakpoint. So instead of:
main[1] cont
main[1]
"Breakpoint hit:"
main[1]
We sometimes get:
main[1] cont
"Breakpoint hit:" main[
It may be sufficient when the command prompt is delivered
to introduce a brief pause to allow an asynchronous event to
be processed before another command can be sent. e.g.
throttling the stream of commands being sent
diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Jdb.java
b/test/hotsp
On 6/6/18 8:51 AM, Daniel D. Daugherty wrote:
The two prompts are for two different things so I don't think
that removing one of the prompts is the right solution either.
In the case of an asynchronous command like 'cont', you get
the '' right away because the command
processor is ready for anot
Hi,
This is fifth (and hopefully final) round of code review for Epsilon GC
changes. It includes the
fixes done as the result of fourth round of reviews, mostly in Serviceability.
The build parts are
the same since last few reviews, so this is not posted to build-dev@.
Webrev:
http://cr.openj
Hi, Stuart.
I think you need to make changes to this file too:
http://hg.openjdk.java.net/jdk/jdk/file/tip/src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html
Thanks,
iris
-Original Message-
From: Alan Bateman
Sent: Wednesday, June 6, 2018 3:40 AM
To: Stuart
> On Jun 6, 2018, at 6:05 PM, Thomas Stüfe wrote:
>
> Dear all,
>
> may I please have feedback and if possible reviews for this small addition:
I can see the need to visualize this but the output looks easily parsable so it
all looks good from my perspective.
Not an official review
— Kirk
Dear all,
may I please have feedback and if possible reviews for this small addition:
CR: https://bugs.openjdk.java.net/browse/JDK-8203343
Webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8203343-VM.metaspace-show-reflection-invocation-targets/webrev.00/webrev/
(Note: this patch goes atop of
The two prompts are for two different things so I don't think
that removing one of the prompts is the right solution either.
In the case of an asynchronous command like 'cont', you get
the '' right away because the command
processor is ready for another command. You will also get the
'' prompt wh
On 06/06/2018 01:05, Stuart Marks wrote:
[adding serviceability-dev]
Hi serviceability folks,
I'm in the process of removing Thread.destroy() and
Thread.stop(Throwable) from the Java SE API. Alan and David have
pointed out that there are some cross-references to
Thread.stop(Throwable) in the
41 matches
Mail list logo
