> On 6 Jul 2016, at 12:04, Michael Haupt <michael.ha...@oracle.com> wrote: > > Hi Paul, > > thanks for your comments. > > Lazy initialisation of the PerfCounter is good, as is the warning suppression. > > I'll let Claes comment on the broader PerfCounter question, as he suggested > using them. I think PerfCounter is a convenient abstraction for what we want > to achieve, but the way it's used here may smell a bit abusive. >
Ok. > What do you mean with "differentiate between the two cases"? Assuming it's > Error/Exception vs. BytecodeGenerationException, here's the current > rationale. There are cases when it makes sense to fall back to LFI, e.g., > when, as here, methods grow too large. In many other cases it is justified to > bail altogether with an InternalError. Wrapping cw.toClassBytes() is a first > approximation. > I meant to say: >> Is it correct to say we *cannot* differentiate between the two cases. If so >> the danger is that we add another intrinsic and don’t realize it contains an >> actual error and we notice too late when we observe performance falling off >> a cliff. > I don’t know if we can differentiate between a valid error (reaching the certain byte code limits) and an unexpected error where say we add a new intrinsic and its code generation is faulty causing ASM to throw RuntimeException. A wild thought: is there anyway to add some context/data to the ASM processing indicating what intrinsic is being processed, so when you get the exception you can at least differentiate. Paul.
