RFR(S): 8160717: MethodHandles.loop() does not check for excessive signature
paul.sandoz at oracle.com
Wed Jul 6 09:30:32 UTC 2016
> 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:
More information about the core-libs-dev