RFR: 8007806: Need a Throwables performance counter (original) (raw)
Peter Levart peter.levart at gmail.com
Mon Feb 25 13:30:02 UTC 2013
- Previous message: RFR: 8007806: Need a Throwables performance counter
- Next message: RFR: 8007806: Need a Throwables performance counter
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 pointed out in this thread, the "thrownThrowables" might be misleading if the counter is incremented in the Throwable constructors (or are you going to instrument the throw sites?). So it might better be called what it is: "constructedThrowables". Yes, this is a common idiom:
throw new ThrowableSubclass(...);...but the number of thrown and constructed throwables may diverge considerably in situations like for example:
- preallocated throwable instances used (and reused) as a form of "long return" (from lambdas).
- deserialized throwables on RMI clients that are thrown on the server side, transfered over the wire and re-thrown on client side (de-seriailization does not call the constructor)
2. Plz to say yes to adding that counter
It's not my call but I would be concerned about performance. Current set of counters that are updated from Java is not that critical, but having a counter of constructed objects updated via synchronized method (or a CAS) can have a negative impact on application performance. See what happened with HashMap constructor. The same could happen in situations where Throwable subclass is (miss)used for example to "long return" a result from... say a lambda (again). This is perfectly performant and scalable now (just override the Throwable.fillInStackTrace with empty implementation and you get a "long return(value)"). I'm not saying that this is a good practice, but such usages will emerge with lambdas.
So although this thread is only about counter name, I think care should be put also on it's implementation. Perhaps with an option to disable instrumentation if requested from user? On a per-Throwable-subclass basis (like Logger levels)? Using external configuration (system properties) or special @DontTrace annotation?
3. Profit!
:-)
Regards, Peter
Regards, Nils Loodin
- Previous message: RFR: 8007806: Need a Throwables performance counter
- Next message: RFR: 8007806: Need a Throwables performance counter
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]