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.
David
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