RFR: 8007806: Need a Throwables performance counter
peter.levart at gmail.com
Mon Feb 25 13:30:02 UTC 2013
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!
> Nils Loodin
More information about the core-libs-dev