> On 6 Jul 2016, at 14:32, Michael Haupt <michael.ha...@oracle.com> wrote: > > Hi Paul, > >> Am 06.07.2016 um 12:45 schrieb Paul Sandoz <paul.san...@oracle.com >> <mailto: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. >
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.
