> 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
'sun
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 incremente
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
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 fre
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 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 point
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, thi
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 reviewing:
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 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 L
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
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 JDK 8.
David
On 23/02/2013 2:16 AM, Jaso
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
On 02/24/2013 10:48 PM, David Holmes wrote:
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 v
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 buff
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, Unsaf
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
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 ac
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
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 might
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 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 f
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 ref
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 conten
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
sun
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 of
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: jdk/src/share/classes/sun/misc/PerfCounte
>From this webrev
>http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ you are
>counting the number of throwables constructed. You might want to change the
>name to reflect that. I don't think anyone would want to write a spec for how
>many throwables are thrown given tha
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 us
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 from
31 matches
Mail list logo
