Fwd: Java Performance Degradation in JDK7 and JDK8
Jacob Wieland
wieland at testingtech.com
Wed Jul 1 11:26:40 UTC 2015
No, in reality, the generated code to be compiled is much larger, the given
small example is just a small sub-part of it (but large enough so that the
degradation is showing). Since memory issues scale up the larger the input
is, I am still stuck with a non-performance for the real-world input unless
I throw insane amounts of memory at the compiler (which some of our
customers cannot do).
2015-07-01 12:48 GMT+02:00 Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:
> What do you mean by 'full example' - the one you attached in the JBS bug?
>
> Maurizio
>
> On 01/07/15 09:58, Jacob Wieland wrote:
>
> I have tried again with the original code generation scheme (sorry, last
> tests were with the new modular one) for the full example and got the
> following measurements:
>
> 1.6 - 60 sec
> 1.8 - 90 sec (CPU > 300)
> 1.9 - 110 sec (CPU > 300)
>
> I also tried with the new modular code generation scheme (using
> top-level classes instead of inner classes)
>
> 1.6 - 86 sec
> 1.8 - 142 sec (CPU > 300)
> 1.9 - 128 sec (CPU > 300)
>
> The CPU usage of 1.8 and 1.9 where also much higher in 1.8 and 1.9.
>
> Using memory restrictions (-J-Xmx2000M), I got the following results on
> the modular scheme:
>
> 1.6 - 101 sec (CPU max 160, normally around 100)
> 1.8 - 1168 sec (CPU continuously around 350)
> 1.9 - 194 sec (CPU max 360, almost continuously)
>
> If you are interested, we can exchange the testcases in some other way,
> I guess. They are too large to send.
>
> BR
>
>
> 2015-06-30 15:38 GMT+02:00 Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com>:
>
>> I tried this on my not-so-good laptop, and I can get your originally
>> submitted test case to complete in 50 seconds with the latest JDK 9;
>> doesn't seem to even be able to complete with an older JDK 9 (I'm using
>> -Xmx764M to artificially limit the memory). So, it seems like performances
>> are back to what the bug report says you were getting for 1.6 ?
>>
>> Maurizio
>>
>>
>> On 30/06/15 13:56, Jacob Wieland wrote:
>>
>> sorry to say it, but the jdk 9 version isn't any better (in that respect)
>> either ...
>>
>> 2015-06-30 14:45 GMT+02:00 Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com>:
>>
>>> Also, please try with latest snapshot for JDK 9
>>>
>>> https://jdk9.java.net/download/
>>>
>>> It is possible that the 8 version is held back by something else
>>>
>>> Maurizio
>>>
>>> On 30/06/15 13:43, Maurizio Cimadamore wrote:
>>>
>>> (Adding Jan)
>>> this is weird - in our tests memory usage went down dramatically. Jan,
>>> is your fix for 8039262
>>> <https://bugs.openjdk.java.net/browse/JDK-8039262> in JDK 8u60 b21 (the
>>> latest from the early access page) ?
>>>
>>> Maurizio
>>>
>>>
>>> On 30/06/15 13:40, Jacob Wieland wrote:
>>>
>>> unfortunately, there doesn't seem to be any improvement with that build
>>> that I can observe. still uses up all cpu-capacity and doesn't take less
>>> time, either.
>>>
>>> 2015-06-30 12:48 GMT+02:00 Maurizio Cimadamore <
>>> maurizio.cimadamore at oracle.com>:
>>>
>>>>
>>>>
>>>> On 30/06/15 11:45, Jacob Wieland wrote:
>>>>
>>>> Thank you,
>>>>
>>>> why doesn't the bug appear in the change-set?
>>>>
>>>> It's been fixed in b20, so b21 changeset won't show it. Our early
>>>> access website only maintains info about the latest available build.
>>>>
>>>> Maurizio
>>>>
>>>> BR
>>>>
>>>> 2015-06-30 11:49 GMT+02:00 Maurizio Cimadamore <
>>>> maurizio.cimadamore at oracle.com>:
>>>>
>>>>> Hi Jacob,
>>>>> this has been fixed in 9 and 8 - our sustaining team will take it from
>>>>> there and backport to 7 eventually, but I don't have visibility over their
>>>>> integration schedule.
>>>>>
>>>>> The next JDK 8 public update should have the fix - in the meantime,
>>>>> you could try with an early access build here:
>>>>>
>>>>> https://jdk8.java.net/download.html
>>>>>
>>>>> Maurizio
>>>>>
>>>>>
>>>>> On 30/06/15 07:33, Jacob Wieland wrote:
>>>>>
>>>>> Hello Maurizio,
>>>>>
>>>>> any news on this issue?
>>>>>
>>>>> BR
>>>>>
>>>>> 2015-04-30 17:51 GMT+02:00 Maurizio Cimadamore <
>>>>> maurizio.cimadamore at oracle.com>:
>>>>>
>>>>>> On 30/04/15 16:15, Jacob Wieland wrote:
>>>>>>
>>>>>> thank you very much - very interesting.
>>>>>>
>>>>>> is there any estimate when a patch for 7/8 will be available?
>>>>>>
>>>>>> We are currently playing with different patches - we will update
>>>>>> this discussion when we know more about which steps will be taken.
>>>>>>
>>>>>> Regards
>>>>>> Maurizio
>>>>>>
>>>>>>
>>>>>> 2015-04-30 17:03 GMT+02:00 Maurizio Cimadamore <
>>>>>> maurizio.cimadamore at oracle.com>:
>>>>>>
>>>>>>> For the records - I've added a comment in
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039262
>>>>>>>
>>>>>>> Reporting in as much detail as possible the underlying cause of the
>>>>>>> performance regression.
>>>>>>>
>>>>>>> Maurizio
>>>>>>>
>>>>>>>
>>>>>>> On 29/04/15 18:38, Jan Lahoda wrote:
>>>>>>>
>>>>>>>> In 9, the Scope listeners are (AFAIK) only needed to update the
>>>>>>>> "mark" (so that the Types caches can detect obsolete entries). I think we
>>>>>>>> may be able to avoid the listeners at the cost of slowing down getMark
>>>>>>>> somewhat (getMark would ask the sub-scopes for their marks and sum the
>>>>>>>> result). I'll try.
>>>>>>>>
>>>>>>>> Jan
>>>>>>>>
>>>>>>>> On 29.4.2015 19:16, Maurizio Cimadamore wrote:
>>>>>>>>
>>>>>>>>> Found it.
>>>>>>>>>
>>>>>>>>> The big offender is the listeners field in the CompoundScope
>>>>>>>>> (which is a
>>>>>>>>> list).
>>>>>>>>>
>>>>>>>>> The test ends up creating huge listeners lists - probably because
>>>>>>>>> of
>>>>>>>>> very deep inheritance hierarchies.
>>>>>>>>>
>>>>>>>>> If I avoid adding stuff to the listeners field in the compound
>>>>>>>>> scope, I
>>>>>>>>> get back to a sane scenario:
>>>>>>>>>
>>>>>>>>> real 0m32.540s
>>>>>>>>> user 1m15.298s
>>>>>>>>> sys 0m1.126s
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And the profiled memory usage is much more under control.
>>>>>>>>>
>>>>>>>>> So, looks like we need a way to prevent these listeners list to
>>>>>>>>> overwhelm javac ;-)
>>>>>>>>>
>>>>>>>>> Maurizio
>>>>>>>>>
>>>>>>>>> On 29/04/15 17:51, Vicente-Arturo Romero-Zaldivar wrote:
>>>>>>>>>
>>>>>>>>>> On 04/29/2015 09:43 AM, Maurizio Cimadamore wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 29/04/15 17:01, Jan Lahoda wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 29.4.2015 16:06, Jacob Wieland wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I have to admit, the reproducer is only a small part of the
>>>>>>>>>>>>> actual
>>>>>>>>>>>>> generated code. In my preliminary tests, it already sufficed
>>>>>>>>>>>>> to show a
>>>>>>>>>>>>> difference (also, the smaller code still worked with 32 bit
>>>>>>>>>>>>> while the
>>>>>>>>>>>>> whole code runs out of memory in all 32 bit versions which
>>>>>>>>>>>>> makes
>>>>>>>>>>>>> comparison much harder ;-) and which is why I need the 64 bit
>>>>>>>>>>>>> versions).
>>>>>>>>>>>>> If I test with the complete code which is much bigger, the
>>>>>>>>>>>>> results are
>>>>>>>>>>>>> as follows:
>>>>>>>>>>>>>
>>>>>>>>>>>>> jdk1.6u45(64bit) 2GB MaxMem - 1:30 minutes
>>>>>>>>>>>>> jdk1.7u75(64bit) 2GB MaxMem - > 6 min
>>>>>>>>>>>>> jdk1.8u31(64bit) 1GB MaxMem - > 15 min
>>>>>>>>>>>>> jdk1.8u31(64bit) 2GB MaxMem - > 10 min
>>>>>>>>>>>>> jdk1.8u31(64bit) 4GB MaxMem - 2:20 min (-source/-target 6 does
>>>>>>>>>>>>> not
>>>>>>>>>>>>> seem
>>>>>>>>>>>>> to have any effect)
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, if you throw insane (in comparison with 1.6) amounts of
>>>>>>>>>>>>> memory at
>>>>>>>>>>>>> 1.7/1.8, it is only about a third as slow, but this still is
>>>>>>>>>>>>> unacceptable. I actually think it has to do with
>>>>>>>>>>>>> parallellization and
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When I was looking at JDK-8039262, a significant contributing
>>>>>>>>>>>> factor
>>>>>>>>>>>> to the slowdown (with enough memory and -source/-target 6)
>>>>>>>>>>>> appeared
>>>>>>>>>>>> to be Check.checkOverrideClashes - I believe this does checks
>>>>>>>>>>>> that
>>>>>>>>>>>> were not properly implemented in 6, contributing to the
>>>>>>>>>>>> difference
>>>>>>>>>>>> between 6 and 7 (which seems to be particularly visible for this
>>>>>>>>>>>> testcase). I was looking at the checks a few times, trying to
>>>>>>>>>>>> write
>>>>>>>>>>>> them differently/faster while still performing the checks, but
>>>>>>>>>>>> was
>>>>>>>>>>>> not successful in that yet, unfortunately.
>>>>>>>>>>>>
>>>>>>>>>>> I see the issue now - it is reproducible with the following
>>>>>>>>>>> memory
>>>>>>>>>>> parameter (at least in my machine):
>>>>>>>>>>>
>>>>>>>>>>> -J-Xmx768M
>>>>>>>>>>>
>>>>>>>>>>> This give around 20sec in JDK 6 and 10+ minutes in JDK 8.
>>>>>>>>>>>
>>>>>>>>>>> All the time seems to be spent in desugaring, most specifically
>>>>>>>>>>> in
>>>>>>>>>>> TransTypes.addBridges - it seems like that method calls
>>>>>>>>>>> Types.implementation a lot - so my theory was that the fact that
>>>>>>>>>>> javac consumes more memory, forces the GC to get rid of the
>>>>>>>>>>> cached
>>>>>>>>>>> entries in the implementation/members closure caches (since such
>>>>>>>>>>> entries are deliberately backed up by SoftReferences), which in
>>>>>>>>>>> turn
>>>>>>>>>>> completely trashes performances. I instrumented the code a bit
>>>>>>>>>>> and
>>>>>>>>>>> this is what I found:
>>>>>>>>>>>
>>>>>>>>>>> *) With -Xmx768M
>>>>>>>>>>>
>>>>>>>>>>> Impl cache misses = 3346926
>>>>>>>>>>> Members cache misses = 1042678
>>>>>>>>>>>
>>>>>>>>>>> real 7m0.335s
>>>>>>>>>>> user 25m51.517s
>>>>>>>>>>> sys 0m4.947s
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *) W/o -Xmx768M
>>>>>>>>>>>
>>>>>>>>>>> Impl cache misses = 3346839
>>>>>>>>>>> Members cache misses = 1042678
>>>>>>>>>>>
>>>>>>>>>>> real 0m32.377s
>>>>>>>>>>> user 1m25.881s
>>>>>>>>>>> sys 0m2.232s
>>>>>>>>>>>
>>>>>>>>>>> Long story short - cache misses do not play a factor in here -
>>>>>>>>>>> there
>>>>>>>>>>> are some minor differences, but nothing out of the ordinary and
>>>>>>>>>>> defo
>>>>>>>>>>> nothing that would explain a multi-minute slowdown! Any ideas?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> use flight recorder?
>>>>>>>>>>
>>>>>>>>>> Vicente
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Maurizio
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jan
>>>>>>>>>>>>
>>>>>>>>>>>> garbage collection.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2015-04-29 15:12 GMT+02:00 Maurizio Cimadamore
>>>>>>>>>>>>> <maurizio.cimadamore at oracle.com
>>>>>>>>>>>>> <mailto:maurizio.cimadamore at oracle.com>>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 29/04/15 12:44, Jacob Wieland wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Maurizio,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> are you sure that you used the 64bit versions of javac? I
>>>>>>>>>>>>>> could
>>>>>>>>>>>>>> only observe the behavior with these.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Yep I'm on a Ubuntu x64 machine. It's actually pretty
>>>>>>>>>>>>> standard
>>>>>>>>>>>>> hardware too - i.e. intel i5 (two cores, but OS sees 4
>>>>>>>>>>>>> because of
>>>>>>>>>>>>> hyper-threading).
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, I just tried with jdk8u31-64b and it takes AGES
>>>>>>>>>>>>>> (still
>>>>>>>>>>>>>> running after 17 minutes where the jdk6 was done after
>>>>>>>>>>>>>> 2), top
>>>>>>>>>>>>>> shows 4GB VIRT memory use and 350 % load (on a 4core
>>>>>>>>>>>>>> processor).
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe the reproducer you sent was incorrect?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maurizio
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, I don't think it was that problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2015-04-29 12:00 GMT+02:00 Maurizio Cimadamore
>>>>>>>>>>>>>> <maurizio.cimadamore at oracle.com
>>>>>>>>>>>>>> <mailto:maurizio.cimadamore at oracle.com>>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These are the numbers I'm getting:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JDK 9 (b42)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note: generated_ttcn/TTCN3_CommonDefs.java uses or
>>>>>>>>>>>>>> overrides a
>>>>>>>>>>>>>> deprecated API.
>>>>>>>>>>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> real 0m46.306s
>>>>>>>>>>>>>> user 2m17.489s
>>>>>>>>>>>>>> sys 0m2.166s
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JDK 8 (GA)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note: generated_ttcn/TTCN3_CommonDefs.java uses or
>>>>>>>>>>>>>> overrides a
>>>>>>>>>>>>>> deprecated API.
>>>>>>>>>>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> real 6m58.748s
>>>>>>>>>>>>>> user 8m43.546s
>>>>>>>>>>>>>> sys 0m2.132s
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JDK 7 (1.7.0_79)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note: generated_ttcn/TTCN3_CommonDefs.java uses or
>>>>>>>>>>>>>> overrides a
>>>>>>>>>>>>>> deprecated API.
>>>>>>>>>>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> real 0m28.341s
>>>>>>>>>>>>>> user 1m17.194s
>>>>>>>>>>>>>> sys 0m1.886s
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As you can see there is a significant regression from
>>>>>>>>>>>>>> JDK
>>>>>>>>>>>>>> 7 to
>>>>>>>>>>>>>> JDK 8 which was caused by
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043253
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (some stack trace analysis revealed the familiar
>>>>>>>>>>>>>> pattern).
>>>>>>>>>>>>>> This has also been fixed in JDK 8u20 (as stated in
>>>>>>>>>>>>>> the bug
>>>>>>>>>>>>>> evaluation).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, while JDK 8u20/9 is slower than JDK 7 (at least
>>>>>>>>>>>>>> on my
>>>>>>>>>>>>>> machine), the numbers are more or less in the same
>>>>>>>>>>>>>> ballpark
>>>>>>>>>>>>>> and the huge regression that was visible in earlier
>>>>>>>>>>>>>> JDK 8
>>>>>>>>>>>>>> releases has now been fixed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are still experiencing the problem - can you
>>>>>>>>>>>>>> please
>>>>>>>>>>>>>> also submit the specific compiler versions you are
>>>>>>>>>>>>>> using in
>>>>>>>>>>>>>> your benchmark?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maurizio
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 29/04/15 10:29, Maurizio Cimadamore wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Jacob,
>>>>>>>>>>>>>>> Stay assured - as we'll definitively look into this
>>>>>>>>>>>>>>> issue (I
>>>>>>>>>>>>>>> see it's already assigned to one of my colleagues).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What I can say (w/o looking too much at the attached
>>>>>>>>>>>>>>> artifacts) is that in general, javac has no issue
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> compiling a lot of sources at once; at one point the
>>>>>>>>>>>>>>> build
>>>>>>>>>>>>>>> system was structured in such a way that all the JDK
>>>>>>>>>>>>>>> classes
>>>>>>>>>>>>>>> were compiled at once - and that (which is way more
>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>> 187 sources - i.e. at least 10x that) took less than
>>>>>>>>>>>>>>> 20
>>>>>>>>>>>>>>> seconds. SO there must some specific pattern
>>>>>>>>>>>>>>> triggering that
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Given that you say you have 187 input sources and
>>>>>>>>>>>>>>> 48K output
>>>>>>>>>>>>>>> classes, I'd say you are using inner classes a lot.
>>>>>>>>>>>>>>> I wonder
>>>>>>>>>>>>>>> if you are hitting this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8000316
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maurizio
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 24/04/15 09:49, Jacob Wieland wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Folks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I still have the open problem
>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8039262 that the
>>>>>>>>>>>>>>>> javac performance has degraded significantly from
>>>>>>>>>>>>>>>> 1.6 to
>>>>>>>>>>>>>>>> 1.7
>>>>>>>>>>>>>>>> (and even worse to 1.8) in the 64bit versions.
>>>>>>>>>>>>>>>> Since in our
>>>>>>>>>>>>>>>> context, we are dealing with a lot of generated
>>>>>>>>>>>>>>>> source1.4
>>>>>>>>>>>>>>>> Java input (either split into very large files with
>>>>>>>>>>>>>>>> inner
>>>>>>>>>>>>>>>> classes or big packages with lots of smaller
>>>>>>>>>>>>>>>> classes),
>>>>>>>>>>>>>>>> compiler performance is critical for our tool and
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> degradation forces us to continue recommending to
>>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>> customers to use Java 1.6 for large projects (as is
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> norm) as 1.7 and 1.8 are pretty much unusable in
>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> respect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is anyone still working on this issue or is such
>>>>>>>>>>>>>>>> significant
>>>>>>>>>>>>>>>> performance degradation not a serious issue?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> My observations so far are:
>>>>>>>>>>>>>>>> - it gets worse the more class files are being
>>>>>>>>>>>>>>>> compiled/the
>>>>>>>>>>>>>>>> more files reside in the source path
>>>>>>>>>>>>>>>> - cpu usage goes through the roof over all available
>>>>>>>>>>>>>>>> kernels
>>>>>>>>>>>>>>>> - memory usage is much higher
>>>>>>>>>>>>>>>> - garbage collection seems to be much more active
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Using -proc:none alleviates the problem slightly
>>>>>>>>>>>>>>>> for the
>>>>>>>>>>>>>>>> 1.7
>>>>>>>>>>>>>>>> version, but not for 1.8 (last we tested with
>>>>>>>>>>>>>>>> jdk1.8.0_31) where the performance difference is a
>>>>>>>>>>>>>>>> factor 5
>>>>>>>>>>>>>>>> or more!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I can understand that a more advanced compiler has
>>>>>>>>>>>>>>>> capabilities that a previous version does not have
>>>>>>>>>>>>>>>> and thus
>>>>>>>>>>>>>>>> sometimes has
>>>>>>>>>>>>>>>> to do more work. But, it should still be possible
>>>>>>>>>>>>>>>> (especially if given the -source 1.4 or -source 1.5
>>>>>>>>>>>>>>>> option
>>>>>>>>>>>>>>>> as we do) to optimize it in such a way that
>>>>>>>>>>>>>>>> unnecessary
>>>>>>>>>>>>>>>> checks for generics, overriding methods, closures,
>>>>>>>>>>>>>>>> annotations and other newer features can be turned
>>>>>>>>>>>>>>>> off (if
>>>>>>>>>>>>>>>> they are to blame, which I actually doubt from my
>>>>>>>>>>>>>>>> observations).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would really appreciate your help in this regard
>>>>>>>>>>>>>>>> and I
>>>>>>>>>>>>>>>> think everyone would benefit from any bugfix you
>>>>>>>>>>>>>>>> can offer
>>>>>>>>>>>>>>>> for this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> BR, Jacob Wieland
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>>>> Dr. Jacob Wieland
>>>>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Testing Technologies IST GmbH
>>>>>>>>>>>>>>>> Michaelkirchstraße 17/18
>>>>>>>>>>>>>>>> 10179 Berlin, Germany
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Phone +49 30 726 19 19 34
>>>>>>>>>>>>>>>> <%2B49%2030%20726%2019%2019%2034> Email
>>>>>>>>>>>>>>>> wieland at testingtech.com <mailto:
>>>>>>>>>>>>>>>> stanca at testingtech.com>
>>>>>>>>>>>>>>>> Fax +49 30 726 19 19 20 Internet
>>>>>>>>>>>>>>>> www.testingtech.com
>>>>>>>>>>>>>>>> <http://www.testingtech.com>
>>>>>>>>>>>>>>>> ---------------------------------------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----------------------------------------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> UPCOMING EVENTS
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> SUBMIT YOUR TOPIC for the UCAAT 2015
>>>>>>>>>>>>>>>> Deadline: May 30, 2015
>>>>>>>>>>>>>>>> ucaat.etsi.org/2015/CallForPresentations.html
>>>>>>>>>>>>>>>> <http://ucaat.etsi.org/2015/CallForPresentations.html>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Apr 21-23, 2015 | SAE Conference & Exhibition
>>>>>>>>>>>>>>>> Detroit, Michigan, USA
>>>>>>>>>>>>>>>> www.sae.org/congress/ <http://www.sae.org/congress/
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Apr 28-30, 2015 | iqnite
>>>>>>>>>>>>>>>> Dusseldorf, Germany
>>>>>>>>>>>>>>>> www.iqnite-conferences.com/de/index.aspx
>>>>>>>>>>>>>>>> <http://www.iqnite-conferences.com/de/index.aspx>
>>>>>>>>>>>>>>>> -----------------------------------------------------------------------------------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Geschäftsführung: Theofanis Vassiliou-Gioles,
>>>>>>>>>>>>>>>> Stephan
>>>>>>>>>>>>>>>> Pietsch, Pete Nicholson Handelsregister HRB 77805 B,
>>>>>>>>>>>>>>>> Amtsgericht Charlottenburg Ust ID Nr.: DE 813 143
>>>>>>>>>>>>>>>> 070 This
>>>>>>>>>>>>>>>> email may contain confidential and privileged
>>>>>>>>>>>>>>>> material for
>>>>>>>>>>>>>>>> the sole use of the intended recipient. Any review,
>>>>>>>>>>>>>>>> use,
>>>>>>>>>>>>>>>> distribution or disclosure by others is strictly
>>>>>>>>>>>>>>>> prohibited.
>>>>>>>>>>>>>>>> If you are not the intended recipient (or
>>>>>>>>>>>>>>>> authorized to
>>>>>>>>>>>>>>>> receive for the recipient), please contact the
>>>>>>>>>>>>>>>> sender by
>>>>>>>>>>>>>>>> reply email and delete all copies of this message.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> ------------------------------
>>>>>>>>>>>>>> -------------------------------------------
>>>>>>>>>>>>>> Dr. Jacob Wieland
>>>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Testing Technologies IST GmbH
>>>>>>>>>>>>>> Michaelkirchstraße 17/18
>>>>>>>>>>>>>> 10179 Berlin, Germany
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Phone +49 30 726 19 19 34 Email
>>>>>>>>>>>>>> wieland at testingtech.com
>>>>>>>>>>>>>> <mailto:stanca at testingtech.com>
>>>>>>>>>>>>>> Fax +49 30 726 19 19 20 <%2B49%2030%20726%2019%2019%2020>
>>>>>>>>>>>>>> Internet www.testingtech.com
>>>>>>>>>>>>>> <http://www.testingtech.com>
>>>>>>>>>>>>>> ---------------------------------------------------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----------------------------------------------------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> UPCOMING EVENTS
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SUBMIT YOUR TOPIC for the UCAAT 2015
>>>>>>>>>>>>>> Deadline: May 30, 2015
>>>>>>>>>>>>>> ucaat.etsi.org/2015/CallForPresentations.html
>>>>>>>>>>>>>> <http://ucaat.etsi.org/2015/CallForPresentations.html>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Apr 21-23, 2015 | SAE Conference & Exhibition
>>>>>>>>>>>>>> Detroit, Michigan, USA
>>>>>>>>>>>>>> www.sae.org/congress/ <http://www.sae.org/congress/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Apr 28-30, 2015 | iqnite
>>>>>>>>>>>>>> Dusseldorf, Germany
>>>>>>>>>>>>>> www.iqnite-conferences.com/de/index.aspx
>>>>>>>>>>>>>> <http://www.iqnite-conferences.com/de/index.aspx>
>>>>>>>>>>>>>> -----------------------------------------------------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ...
>>
>> [Nachricht gekürzt]
>
>
>
>
> --
> --
> ------------------------------
> -------------------------------------------
> Dr. Jacob Wieland
> Senior Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email wieland at testingtech.com
> <stanca at testingtech.com>
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>
>
> ---------------------------------------------------------------------------------------------------------------------
>
> UPCOMING EVENTS
>
> Jul 15-16, 2015 | German Testing Day
> Frankfurt, Germany | Booth #8
> www.germantestingday.info/
>
> Sep 15-17, 2015 | Accredited TTCN-3 Training "Test Automation with
> TTCN-3"
> Berlin, Germany
> www.testingtech.com/services/ttcn3_training.php
>
> Oct 5-9, 2015 | 22nd ITS World Congress
> Bordeaux, France | At Spirent's Booth #122
> www.itsineurope.com/bordeaux-2015/
>
>
> -----------------------------------------------------------------------------------------------------------------
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18, 10179 Berlin, Germany
> Office: +49 (30) 726 19 19 0
> Fax: +49 (30) 726 19 19 20
> Internet www.testingtech.com
> ------------------------------------------------------------
> -----------------------------------------------------
>
> Executive Board: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete
> Nicholson
> Handelsregister HRB 77805 B, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
>
>
> --
> --
> ------------------------------
> -------------------------------------------
> Dr. Jacob Wieland
> Senior Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email wieland at testingtech.com
> <stanca at testingtech.com>
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>
>
> ---------------------------------------------------------------------------------------------------------------------
>
> UPCOMING EVENTS
>
> Jul 15-16, 2015 | German Testing Day
> Frankfurt, Germany | Booth #8
> www.germantestingday.info/
>
> Sep 15-17, 2015 | Accredited TTCN-3 Training "Test Automation with
> TTCN-3"
> Berlin, Germany
> www.testingtech.com/services/ttcn3_training.php
>
> Oct 5-9, 2015 | 22nd ITS World Congress
> Bordeaux, France | At Spirent's Booth #122
> www.itsineurope.com/bordeaux-2015/
>
>
> -----------------------------------------------------------------------------------------------------------------
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18, 10179 Berlin, Germany
> Office: +49 (30) 726 19 19 0
> Fax: +49 (30) 726 19 19 20
> Internet www.testingtech.com
> ------------------------------------------------------------
> -----------------------------------------------------
>
> Executive Board: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete
> Nicholson
> Handelsregister HRB 77805 B, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
>
>
--
--
------------------------------
-------------------------------------------
Dr. Jacob Wieland
Senior Software Engineer
Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany
Phone +49 30 726 19 19 34 Email wieland at testingtech.com
<stanca at testingtech.com>
Fax +49 30 726 19 19 20 Internet www.testingtech.com
---------------------------------------------------------------------------------------------------------------------
UPCOMING EVENTS
Jul 15-16, 2015 | German Testing Day
Frankfurt, Germany | Booth #8
www.germantestingday.info/
Sep 15-17, 2015 | Accredited TTCN-3 Training "Test Automation with TTCN-3"
Berlin, Germany
www.testingtech.com/services/ttcn3_training.php
Oct 5-9, 2015 | 22nd ITS World Congress
Bordeaux, France | At Spirent's Booth #122
www.itsineurope.com/bordeaux-2015/
-----------------------------------------------------------------------------------------------------------------
Testing Technologies IST GmbH
Michaelkirchstraße 17/18, 10179 Berlin, Germany
Office: +49 (30) 726 19 19 0
Fax: +49 (30) 726 19 19 20
Internet www.testingtech.com
------------------------------------------------------------
-----------------------------------------------------
Executive Board: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete Nicholson
Handelsregister HRB 77805 B, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by
reply email and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150701/dd55b348/attachment-0001.html>
More information about the compiler-dev
mailing list