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

[Paul Sandoz]

> On 6 Jul 2016, at 14:32, Michael Haupt <michael.haupt at oracle.com> wrote:
> 
> Hi Paul,
> 
>> Am 06.07.2016 um 12:45 schrieb Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>>:
>>> 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.
> 
> thanks for clarifying that.
> 
> The way it's implemented now treats anything that occurs during bytecode assembly as a Real Problem and consequently raises an InternalError. Any RuntimeException raised from ASM during class file generation (cw.toByteArray()) is treated as a problem that should imply falling back to LFI mode. Given ASM only throws RuntimeExceptions, their messages could be used to distinguish between problem types, but that is brittle.
> 
> It is definitely possible to attach additional information, such as the current LambdaForm or Intrinsic, to the wrapping exception, but the approach does not scale very well. There is, in principle, nothing that prevents a LambdaForm from containing multiple intrinsifiable idioms in a row. When a problem arises only during class file generation, it will not be easy to trace that back to the problematic intrinsic. Also, inlining at LF level is conceivable, complicating the matter further.
> 

Ok, so on a best-effort basis this is probably the best we have at the moment :-)

I am still skeptical of the value of the perf counter, but i will place my objections to the side to unblock the review.

Paul.