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

Michael Haupt michael.haupt at oracle.com
Wed Jul 6 10:04:49 UTC 2016

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.

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.



> Am 06.07.2016 um 11:30 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
>> On 6 Jul 2016, at 10:43, Michael Haupt <michael.haupt at oracle.com> wrote:
>> Hi Andrej,
>> thanks for your remarks; see below for a comment.
>> In addition, I need an upper-case Review, please.
> I am concerned that PerfCounter will introduce more dependencies and overhead to startup.
> Notice for other usages PerfCounter instances are lazily created.
> This seems a nice to have, but i think is not strictly necessary given this is not something that occurs all the time and is triggered more so by edge case limits producing incorrect byte code, or perhaps actual errors in code generation. i.e. it’s association with performance counters seems a little fuzzy compared to the other usages.
> Is it correct to say we can 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.
>>> Am 06.07.2016 um 10:25 schrieb Andrej Golovnin <andrej.golovnin at gmail.com>:
>>> 767         static final long serialVersionUID = -1L; // no serialisation
>>> Just because you set serialVersionUID to -1L, it does not mean that it
>>> is not serializable. Either remove the comment "// no serialisation"
>>> or remove the serialVersionUID at all because you never serialize this
>>> exception. And btw. serialVersionUID should be private if you decide
>>> to keep it.
>> I know that setting the field to -1 does not hinder serialisation. The comment was intended to make clear that no serialisation of instances of this class will ever happen. I'll make that more clear. Omitting the field is not possible; the compiler will complain. Having serialVersionUID is enforced in the build.
> You should be able to use the following on the exception class:
>  @SuppressWarnings("serial”)
> Paul.


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

More information about the core-libs-dev mailing list