On 02/25/2013 12:03 AM, David Holmes wrote:
I'm getting very confused regarding the different threads on this. But
this webrev:
http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/
shows the intrusive event tracing that I'm sure we said we would
grudgingly accept for 7u but not for
On 25/02/2013 09:23, Nils Loodin wrote:
David et al: No!
That showed the intrusive event tracing that we will not implement ever.
It also has nothing to do with this code review, which is only to
implement a performance counter.
Just to confirm, this is the webrev that we should be
Hi all,
When I used CLHSDB just now I met this error:
hsdb inspect 0xee255080
instance of java/io/InputStream @ 0xee255080 @ 0xee255080
(size = 24)
Exception in thread main java.lang.InternalError: unimplemented
at
Kevin,
looks good to me. (Not a Reviewer).
/R
On Feb 25, 2013, at 7:21 PM, Kevin Walls wrote:
Hi,
This is a crash I stumbled upon: jstack -m will crash when it doesn't match
the bitness of its target. On Solaris we check and give an exception
message, Linux should do similarly.
On Feb 21, 2013, at 9:09 PM, Coleen Phillimore coleen.phillim...@oracle.com
wrote:
I'm sorry about this but I need one more review. I omitted one instance of
JVM_CONSTANT_Object in templateTable_sparc.cpp and I forgot that you can't
make any edit to the VM without making a duplicate edit
Looks good Staffan (not a Reviewer).
Thanks
Markus
-Original Message-
From: Staffan Larsen
Sent: den 18 februari 2013 11:16
To: serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net
Subject: RFR(S): 8005572: fatal error: acquiring lock JfrBuffer_lock/19 out of
order
