On 02/26/2013 12:18 AM, Mandy Chung wrote:
On 2/25/2013 8:30 AM, Nils Loodin wrote:
I changed it to
sun.throwables.numThrowables
in http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/
Is this better? However, bear in mind that it's not exactly specified
where this is going to be
Just to be clear, what I was trying to say that this review is just to
add the counter, and the discussion on how and when to access it is
something that I'd much rather have in context of a review of that code...
Then the counter name should not bind you to how it is counting. +1 for
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 02/24/2013 11:18 PM, David Holmes wrote:
We've not-so-slightly hijacked Nils' thread here - apologies for that.
David, Peter!
Yes you did :)
However, feel free to make it up to me by:
1. Suggest a good name for the counter
2. Plz to say yes to adding that counter
3. Profit!
Regards,
Nils
On 24/02/2013 20:57, David Holmes wrote:
Does jstat access these values directly or only via the synchronized
methods? If the latter then the value can't be torn that way. The
sync method will store the value in 2 32-bit registers, and the
variable load in jstat will take two instructions,
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
On 02/25/2013 11:15 AM, Alan Bateman wrote:
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,
On 02/25/2013 10:29 AM, Nils Loodin wrote:
On 02/24/2013 11:18 PM, David Holmes wrote:
We've not-so-slightly hijacked Nils' thread here - apologies for that.
David, Peter!
Yes you did :)
However, feel free to make it up to me by:
1. Suggest a good name for the counter
As Jason Mehrens
On 02/25/2013 02:30 PM, Peter Levart wrote:
On 02/25/2013 10:29 AM, Nils Loodin wrote:
On 02/24/2013 11:18 PM, David Holmes wrote:
We've not-so-slightly hijacked Nils' thread here - apologies for that.
David, Peter!
Yes you did :)
However, feel free to make it up to me by:
1. Suggest a good
On 02/25/2013 05:30 PM, Nils Loodin wrote:
On 02/25/2013 02:30 PM, Peter Levart wrote:
On 02/25/2013 10:29 AM, Nils Loodin wrote:
On 02/24/2013 11:18 PM, David Holmes wrote:
We've not-so-slightly hijacked Nils' thread here - apologies for that.
David, Peter!
Yes you did :)
However, feel
On 2/25/2013 8:30 AM, Nils Loodin wrote:
I changed it to
sun.throwables.numThrowables
in http://cr.openjdk.java.net/~nloodin/8007806/webrev.01/
Is this better? However, bear in mind that it's not exactly specified
where this is going to be incremented from yet. Nothing in this change
states
Hi David,
I thought it was ok to pass null, but I don't know the portability
issues in-depth. The javadoc for Unsafe says:
/This method refers to a variable by means of two parameters, and so it
provides (in effect) a double-register addressing mode for Java
variables. When the object
On 23/02/2013 23:35, David Holmes wrote:
Before we rush down this path. Atomic operations on 64-bit types are
not supported natively on all 32-bit platforms. Atomic updates on
those platforms will degenerate into locking - which is the barrier to
implementing frequently used counters in the
On 24/02/2013 6:50 PM, Peter Levart wrote:
Hi David,
I thought it was ok to pass null, but I don't know the portability
issues in-depth. The javadoc for Unsafe says:
/This method refers to a variable by means of two parameters, and so it
provides (in effect) a double-register addressing mode
On 02/24/2013 12:35 AM, David Holmes wrote:
On 24/02/2013 6:08 AM, Alan Bateman wrote:
On 23/02/2013 19:39, Peter Levart wrote:
Hi Nils,
If the counters are updated frequently from multiple threads, there
might be contention/scalability issues. Instead of synchronization on
updates, you
On 02/24/2013 11:31 AM, David Holmes wrote:
On 24/02/2013 6:50 PM, Peter Levart wrote:
Hi David,
I thought it was ok to pass null, but I don't know the portability
issues in-depth. The javadoc for Unsafe says:
/This method refers to a variable by means of two parameters, and so it
provides
Hi Alan, David, Nils,
I just want to clear something regarding PerfCounter implementation.
Access to 64bit value in native memory is through a direct buffer which
uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on
processors that don't support atomic 64bit stores/loads, each
On 25/02/2013 6:18 AM, Peter Levart wrote:
Hi Alan, David, Nils,
I just want to clear something regarding PerfCounter implementation.
Access to 64bit value in native memory is through a direct buffer which
uses normal read/write (non-volatile, Unsafe.[get|set]Long). So on
processors that don't
On 02/24/2013 09:57 PM, David Holmes wrote:
On 25/02/2013 6:18 AM, Peter Levart wrote:
Hi Alan, David, Nils,
I just want to clear something regarding PerfCounter implementation.
Access to 64bit value in native memory is through a direct buffer which
uses normal read/write (non-volatile,
Peter,
On 25/02/2013 7:25 AM, Peter Levart wrote:
On 02/24/2013 09:57 PM, David Holmes wrote:
On 25/02/2013 6:18 AM, Peter Levart wrote:
Hi Alan, David, Nils,
I just want to clear something regarding PerfCounter implementation.
Access to 64bit value in native memory is through a direct
We've not-so-slightly hijacked Nils' thread here - apologies for that.
On 25/02/2013 8:05 AM, Peter Levart wrote:
Just looked at one way jstat accesses the counters. It runs in a
separate VM and maps-in a file that is already mapped in the observing
VM in the direct buffer. It then accesses it
that a throwable
can be wrapped, suppressed, rethrown, etc.
Jason
Date: Fri, 22 Feb 2013 14:10:02 +0100
From: nils.loo...@oracle.com
To: core-libs-dev@openjdk.java.net; serviceability-...@openjdk.java.net
Subject: Fwd: RFR: 8007806: Need a Throwables performance counter
Does anyone have
Hi Nils,
If the counters are updated frequently from multiple threads, there
might be contention/scalability issues. Instead of synchronization on
updates, you might consider using atomic updates provided by
sun.misc.Unsafe, like for example:
Index:
On 23/02/2013 19:39, Peter Levart wrote:
Hi Nils,
If the counters are updated frequently from multiple threads, there
might be contention/scalability issues. Instead of synchronization on
updates, you might consider using atomic updates provided by
sun.misc.Unsafe, like for example:
Most
On 24/02/2013 6:08 AM, Alan Bateman wrote:
On 23/02/2013 19:39, Peter Levart wrote:
Hi Nils,
If the counters are updated frequently from multiple threads, there
might be contention/scalability issues. Instead of synchronization on
updates, you might consider using atomic updates provided by
Peter,
In your use of Unsafe you pass null as the object. I'm pretty certain
you can't pass null here. Unsafe operates on fields or array elements.
David
On 24/02/2013 5:39 AM, Peter Levart wrote:
Hi Nils,
If the counters are updated frequently from multiple threads, there
might be
don't really have a better alternative, but neither do I have strong
opinions, so feedback would be appreciated!
How about
sun.throwables.thrownThrowables ?
Regards,
Nils Loodin
Original Message
Subject: RFR: 8007806: Need a Throwables performance counter
Date: Fri, 08 Feb
On 22/02/2013 13:10, Nils Loodin wrote:
Does anyone have anything strongly against this? This is a small
change just to add a performance counter, the code to increment it and
read it will live in other parts of the code and be a part of a larger
separate commit.
Alan Bateman gave the
that a throwable can be wrapped, suppressed,
rethrown, etc. Jason
Date: Fri, 22 Feb 2013 14:10:02 +0100
From: nils.loo...@oracle.com
To: core-libs-dev@openjdk.java.net; serviceability-...@openjdk.java.net
Subject: Fwd: RFR: 8007806: Need a Throwables performance counter
Does anyone have anything
Hey Kasper!
You're right that there are methods that throw exceptions as a part of
the normal program flow.
However, this number can be (and has been) used as a very high level
telemetry for an application. Depending on exactly how large this number
is, and how fast it is growing, something
Jrockit mission control supports an exception count based on exception
type.
I have found the approach of just counting the total number of exception
completely useless.
Mainly because there are methods that throw exceptions as part of the
normal flow. For example, Class.forName() is commonly
On 08/02/2013 17:10, Nils Loodin wrote:
It would be interesting to know the number of thrown throwables in the
JVM, to be able to do some high level application diagnostics /
statistics. A good way to put this number would be a performance
counter, since it is accessible both from Java and
It would be interesting to know the number of thrown throwables in the
JVM, to be able to do some high level application diagnostics /
statistics. A good way to put this number would be a performance
counter, since it is accessible both from Java and from the VM.
33 matches
Mail list logo
