RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature

[Paul Sandoz]

> On 6 Jul 2016, at 12:04, Michael Haupt <michael.haupt at 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.