RFR: 8007806: Need a Throwables performance counter

[Peter Levart]

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