RFR: 8003471 - Add Add instrumentation facilities for Throwables (original) (raw)

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/viewbug.do?bugid=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