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.
Best,
Michael
> Am 06.07.2016 um 11:30 schrieb Paul Sandoz <paul.san...@oracle.com>:
>
>
>> On 6 Jul 2016, at 10:43, Michael Haupt <michael.ha...@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.golov...@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.
--
<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
