On 21/02/2018 4:50 PM, serguei.spit...@oracle.com wrote:
Hi Karen and David,
On 2/20/18 19:52, David Holmes wrote:
Hi Karen,
On 21/02/2018 1:54 AM, Karen Kinnear wrote:
Folks,
As part of the Valhalla EG discussions for JVMTI changes for
nestmates (thank you Serguei and David),
IBM brought
Hi Karen and David,
On 2/20/18 19:52, David Holmes wrote:
Hi
Karen,
On 21/02/2018 1:54 AM, Karen Kinnear wrote:
Folks,
As part of the Valhalla EG discussions for JVMTI changes for
Hi David,
On 2/20/18 20:02, David Holmes wrote:
Hi Daniil,
Good find on this!
What does the actual spec say about the length of things and how they
may be split across multiple packets? Are we guaranteed that at most
two packets will be involved? What about for other things eg:
68
On Wednesday 21 February 2018 01:51 AM, mandy chung wrote:
The code review and CSR review can be in parallel. For this case,
I agree with Kumar to have CSR written that would help the code
review. Please specify the behavior and its relationship with
jcmd and other relevant diagnosability
Hi Harsha,
Not a review, but just a request that you add the explanation of the
problem to the CR so we have a record of it. Also, the copyright needs
to be updated.
thanks,
Chris
On 2/20/18 3:30 AM, Harsha Wardhana B wrote:
Hi All,
Please find the fix below for the Jdp test-case.
Hi Serguei,
It is correct. I was able to reproduce it locally and on Mach5. Before the fix
the failure rate on Mach5 was about 15%. After the fix I run it on Mach5 400
times and no any failure was reported.
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Hi Daniil,
Good find on this!
What does the actual spec say about the length of things and how they
may be split across multiple packets? Are we guaranteed that at most two
packets will be involved? What about for other things eg:
68 protected byte[] readJdwpString(DataInputStream ds)
Hi Karen,
On 21/02/2018 1:54 AM, Karen Kinnear wrote:
Folks,
As part of the Valhalla EG discussions for JVMTI changes for nestmates (thank
you Serguei and David),
IBM brought up a request that we update the JVMTI documentation to reflect that
we allow addition
of private methods.
Is there a
Hi Daniil,
It looks good to me.
It seems, you have been able to reproduce this failure, and with
this fix
the test does not fail anymore. Is that right?
Just wanted to be sure.
Thanks,
Serguei
On 2/20/18
Hi Jeremy,
Another approach is to change ThreadInfoCompositeData::validateCompositeData
to validate the given CompositeData. I also revised
ThreadInfoCompositeData to
return the default value of the attributes, if not present.
This is the patch:
Hi Serguei,
A new version of the webrev that has these strings reformatted is at
http://cr.openjdk.java.net/~dtitov/8170541/webrev.02/
Thank you!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, February 20, 2018 at 3:00 PM
Hi Daniil,
Interesting issue...
Thank you for finding to the root cause so quickly!
The fix looks good.
Could I ask you to reformat these lines to make the L54 shorter ?:
54 System.out.println("[" + getClass().getName() + "]
The code review and CSR review can be in parallel. For this case,
I agree with Kumar to have CSR written that would help the code
review. Please specify the behavior and its relationship with
jcmd and other relevant diagnosability tools.
On 2/20/18 6:41 AM, Kumar Srinivasan wrote:
What is
Please review the changes that fix intermittent failure of
serviceability/jdwp/AllModulesCommandTest.java test.
The problem here is that for a large data the JDWP agent
(socketTransport_writePacket() method in
src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c ) sends 2
packets
Folks,
As part of the Valhalla EG discussions for JVMTI changes for nestmates (thank
you Serguei and David),
IBM brought up a request that we update the JVMTI documentation to reflect that
we allow addition
of private methods.
Is there a reason we do not document this? I’m inviting those who
[Correcting bug Id in the subject]
Thanks Erik.
Harsha
On Tuesday 20 February 2018 08:44 PM, Erik Gahlin wrote:
Looks OK.
Erik
Hi All,
Please find the fix below for the Jdp test-case.
issue: https://bugs.openjdk.java.net/browse/JDK-8196028
webrev :
Looks OK.
Erik
Hi All,
Please find the fix below for the Jdp test-case.
issue: https://bugs.openjdk.java.net/browse/JDK-8196028
webrev : http://cr.openjdk.java.net/~hb/8196028/webrev.00/
Fix details : The test was receiving JDP packets from other VM and
hence the multi-cast socket was not
You are going backwards. You need to have a CSR approved first.
Kumar
Ping. Could I please have reviews for below webrev.
Thanks
Harsha
On Wednesday 14 February 2018 09:59 PM, Harsha Wardhana B wrote:
Hi,
Below is the updated webrev.
http://cr.openjdk.java.net/~hb/8187498/webrev.03/
On
Ping. Could I please have reviews for below webrev.
Thanks
Harsha
On Wednesday 14 February 2018 09:59 PM, Harsha Wardhana B wrote:
Hi,
Below is the updated webrev.
http://cr.openjdk.java.net/~hb/8187498/webrev.03/
On Wednesday 14 February 2018 01:15 AM, mandy chung wrote:
On 2/13/18
Hi All,
Please find the fix below for the Jdp test-case.
issue: https://bugs.openjdk.java.net/browse/JDK-8196028
webrev : http://cr.openjdk.java.net/~hb/8196028/webrev.00/
Fix details : The test was receiving JDP packets from other VM and hence
the multi-cast socket was not timing-out. The
20 matches
Mail list logo