Hi Paul, > Am 06.07.2016 um 12:45 schrieb Paul Sandoz <paul.san...@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
