RFR: 8003471 - Add Add instrumentation facilities for Throwables

David Holmes david.holmes at oracle.com
Fri Nov 16 03:35:10 UTC 2012

+2 Intrusive instrumentation just can't be the way to go.

In addition though you need to be very careful about the impact on the 
initialization sequence of classes here. I suspect your instrumentation 
may be activated early during VM initialization where your 
instrumentation framework will not be able to be used.


On 16/11/2012 4:09 AM, Mandy Chung wrote:
> On 11/15/2012 4:28 AM, Alan Bateman wrote:
>> On 15/11/2012 12:19, Nils Loodin wrote:
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322
>>>> Nils - you can explain why the byte code instrumentation can't be used
>>>> here?
>>> No real reason it couldn't, I just hadn't implemented it that way for
>>> simplicity's sake.
>> I think it would be great if you could explore that. I think it would
>> be a lot preferable than using invasive instrumentation as proposed.
>> Also it would eliminate any concerns about stack overflow and whether
>> this is a supported interface or not.
> +1.
> You can check out hprof that uses dynamic bytecode instrumentation.
> Mandy

More information about the core-libs-dev mailing list