Re: Need reviewer: a couple of hprof fixes for Parfait

On Jun 12, 2012, at 7:41 PM, David Holmes wrote: > On 13/06/2012 3:23 AM, Kelly O'Hair wrote: >> >> Ok, I have to confess, I had to look at this hprof table logic more. >> >> This generic "table" is used all over the place in hprof, so I had to dust >> off some brain cells. >> The info structu

Re: Need reviewer: a couple of hprof fixes for Parfait

On 13/06/2012 3:23 AM, Kelly O'Hair wrote: Ok, I have to confess, I had to look at this hprof table logic more. This generic "table" is used all over the place in hprof, so I had to dust off some brain cells. The info structures are extra structures or extra "info" for each table element, and

Re: Need reviewer: a couple of hprof fixes for Parfait

On Jun 12, 2012, at 7:23 PM, David Holmes wrote: > On 13/06/2012 1:06 AM, Kelly Ohair wrote: >> if size is zero it returns null >> thats the cascading error that parfait is finding >> asserts turn into nothing with product builds so i need a dead stop here to >> shut up parfait :( > > Seems ra

Re: Request for review: 6310967: SA: jstack -m produce failures in output

On 13/06/2012 12:25 PM, Poonam Bajaj wrote: Hi David, On 6/13/2012 7:35 AM, David Holmes wrote: Hi Poonam, It seems to me that rather than passing the ThreadProxy through to f.sender the frame, which has to be a frame of some thread, should already know what that thread is and so be able to ac

Re: Request for review: 6310967: SA: jstack -m produce failures in output

Hi David, On 6/13/2012 7:35 AM, David Holmes wrote: Hi Poonam, It seems to me that rather than passing the ThreadProxy through to f.sender the frame, which has to be a frame of some thread, should already know what that thread is and so be able to access it directly. In other words: shouldn

Re: Need reviewer: a couple of hprof fixes for Parfait

On 13/06/2012 1:06 AM, Kelly Ohair wrote: if size is zero it returns null thats the cascading error that parfait is finding asserts turn into nothing with product builds so i need a dead stop here to shut up parfait :( Seems rather strange to me. Elsewhere where the assert is used a zero siz

Re: Request for review: 6310967: SA: jstack -m produce failures in output

Hi Poonam, It seems to me that rather than passing the ThreadProxy through to f.sender the frame, which has to be a frame of some thread, should already know what that thread is and so be able to access it directly. In other words: shouldn't each CFrame maintain a reference to the thread it

hg: jdk8/tl/jdk: 7171918: XmlReaderContentHandler.endElement does not handle a Delete Tag properly

Changeset: 6b6a73e8c036 Author:lancea Date: 2012-06-12 17:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b6a73e8c036 7171918: XmlReaderContentHandler.endElement does not handle a Delete Tag properly Reviewed-by: joehw ! src/share/classes/com/sun/rowset/internal/XmlReade

Re: Need reviewer: a couple of hprof fixes for Parfait

On 06/12/12 13:49, Kelly O'Hair wrote: Calling table_get_info() kind of assumes you are asking for an info structure, and that info structures exist. Again, no change from the way it always was. The only real change is get_info(), which no longer explicitly returns NULL. There is really nothing

Re: Need reviewer: a couple of hprof fixes for Parfait

On Jun 12, 2012, at 12:55 PM, Daniel D. Daugherty wrote: > On 6/12/12 11:23 AM, Kelly O'Hair wrote: >> Ok, I have to confess, I had to look at this hprof table logic more. >> >> This generic "table" is used all over the place in hprof, so I had to dust >> off some brain cells. >> The info struc

Re: Need reviewer: a couple of hprof fixes for Parfait

On 6/12/12 11:23 AM, Kelly O'Hair wrote: Ok, I have to confess, I had to look at this hprof table logic more. This generic "table" is used all over the place in hprof, so I had to dust off some brain cells. The info structures are extra structures or extra "info" for each table element, and it

Re: Need reviewer: a couple of hprof fixes for Parfait

Ok, I have to confess, I had to look at this hprof table logic more. This generic "table" is used all over the place in hprof, so I had to dust off some brain cells. The info structures are extra structures or extra "info" for each table element, and it's perfectly valid for the info structure

hg: jdk8/tl/jaxp: 7144423: StAX EventReader swallows the cause of error

Changeset: 0c7f86d9ff8b Author:joehw Date: 2012-06-12 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0c7f86d9ff8b 7144423: StAX EventReader swallows the cause of error Summary: make sure the cause of the error is properly reported Reviewed-by: lancea, psandoz ! src/co

Re: Need reviewer: a couple of hprof fixes for Parfait

if size is zero it returns null thats the cascading error that parfait is finding asserts turn into nothing with product builds so i need a dead stop here to shut up parfait :( Sent from my iPhone On Jun 11, 2012, at 22:56, David Holmes wrote: > On 12/06/2012 12:48 PM, Kelly O'Hair wrote: >>

Re: Need reviewer: a couple of hprof fixes for Parfait

i am just trying to prevent the fd leak i vaguely recall that connect() was not consistent on all os implementations so makes me nervous to change that logic Sent from my iPhone On Jun 12, 2012, at 1:38, Dmitry Samersoff wrote: > Changes looks good for me. > > but logic below always was cryp

Request for review: 6310967: SA: jstack -m produce failures in output

Hi, Please review this fix for bug 6310967 . 6310967 : SA: jstack -m produce failures in output http://cr.openjdk.java.net/~poonam/6310967/webrev.00/ Problem: jstack -m f

Re: Need reviewer: a couple of hprof fixes for Parfait

Changes looks good for me. but logic below always was cryptic for me: 139 /* now try connecting */ 140 if (-1 == connect(fd, (struct sockaddr*)&s, sizeof(s))) { 141 (void)close(fd); 142 return 0; 143 } we returns -1 if gethostbyname fail, but 0 if we can't connec