Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Staffan Larsen
Looks good! Thanks, /Staffan On 4 mar 2015, at 15:14, Kevin Walls kevin.wa...@oracle.com wrote: Sure, I updated the webrev: http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/ Thanks Kevin On 04/03/2015 14:05, Staffan Larsen wrote: On 4 mar 2015, at 14:07, Kevin Walls

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Kevin Walls
Thanks!

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Kevin Walls
Thanks Dmitry - I will explain the counter's presence where we introduce it: // Counter to ensure read loops terminate: private static final int MAX_DUPLICATE_DEFINITIONS = 100; private static int duplicateDefCount = 0; Thanks Kevin On 03/03/2015 20:10, Dmitry Samersoff wrote: Kevin,

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Staffan Larsen
On 4 mar 2015, at 12:29, Kevin Walls kevin.wa...@oracle.com wrote: Thanks Dmitry - I will explain the counter's presence where we introduce it: // Counter to ensure read loops terminate: private static final int MAX_DUPLICATE_DEFINITIONS = 100; private static int duplicateDefCount

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Kevin Walls
Hi Staffan -- staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase? Any doubt I will make it per HotSpotTypeDatabase. As I sometimes load

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Staffan Larsen
On 4 mar 2015, at 14:07, Kevin Walls kevin.wa...@oracle.com wrote: Hi Staffan -- staticness: I could have argued that either way, it doesn't need to be static. A static count of how many HotSpotTypeDataBase duplicate type errors we have seen, or one count per HotSpotTypeDataBase?

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-04 Thread Kevin Walls
Sure, I updated the webrev: http://cr.openjdk.java.net/~kevinw/8073688/webrev.01/ Thanks Kevin On 04/03/2015 14:05, Staffan Larsen wrote: On 4 mar 2015, at 14:07, Kevin Walls kevin.wa...@oracle.com wrote: Hi Staffan -- staticness: I could have argued that either way, it doesn't need to

RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-03 Thread Kevin Walls
Hi, This is a review request for a way to make the SA tools protect themselves from infinite loops during initialisation. Attaching jmap (for example) to a JVM can fail, infinitely writing an error - and filling a disk if being logged to a file. This reproduces on a Solaris package based

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-03 Thread Dmitry Samersoff
Kevin, The fix looks good for me, but please add a comment explaining the problem we are solving here. -Dmitry On 2015-03-03 16:15, Kevin Walls wrote: Hi, This is a review request for a way to make the SA tools protect themselves from infinite loops during initialisation. Attaching jmap

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-03 Thread Mikael Gerdin
Kevin, On 2015-03-03 14:15, Kevin Walls wrote: Hi, This is a review request for a way to make the SA tools protect themselves from infinite loops during initialisation. Attaching jmap (for example) to a JVM can fail, infinitely writing an error - and filling a disk if being logged to a file.

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-03 Thread Kevin Walls
Hi, Yes that's true - the original problem is in 7u. We'll have it around for a while yet so I would like to get this change there to protect us. While we can't reproduce the same thing on 9 today, there's still a while loop that will never terminate if we read a zero for the stride size,

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

2015-03-03 Thread Mikael Gerdin
On 2015-03-03 14:57, Kevin Walls wrote: Hi, Yes that's true - the original problem is in 7u. We'll have it around for a while yet so I would like to get this change there to protect us. While we can't reproduce the same thing on 9 today, there's still a while loop that will never terminate