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

[Michael Haupt]

Hi Paul,

> Am 06.07.2016 um 12:45 schrieb Paul Sandoz <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.

Best,

Michael

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment