Fwd: Java Performance Degradation in JDK7 and JDK8
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Jul 1 10:48:20 UTC 2015
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 <mailto: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
>> <mailto: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
>>>> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>> <mailto: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>
>>>>>>> <mailto: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>
>>>>>>> <mailto: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
>>>>>>> <tel:%2B49%2030%20726%2019%2019%2034>
>>>>>>> Email
>>>>>>> wieland at testingtech.com
>>>>>>> <mailto:wieland at testingtech.com>
>>>>>>> <mailto:stanca at testingtech.com
>>>>>>> <mailto:stanca at testingtech.com>>
>>>>>>>
>>>>>>>
>>>>>>> Fax
>>>>>>> +49
>>>>>>> 30
>>>>>>> 726
>>>>>>> 19
>>>>>>> 19
>>>>>>> 20
>>>>>>> <tel:%2B49%2030%20726%2019%2019%2020>
>>>>>>>
>>>>>>> Internet
>>>>>>> www.testingtech.com
>>>>>>> <http://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>
>>>>>>> <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/>
>>>>>>> <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>
>>>>>>> <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
>>>>>>> <tel:%2B49%2030%20726%2019%2019%2034>
>>>>>>> Email
>>>>>>> wieland at testingtech.com
>>>>>>> <mailto:wieland at testingtech.com>
>>>>>>> <mailto:stanca at testingtech.com
>>>>>>> <mailto:stanca at testingtech.com>>
>>>>>>> Fax +49
>>>>>>> 30 726 19 19
>>>>>>> 20
>>>>>>> <tel:%2B49%2030%20726%2019%2019%2020>
>>>>>>> Internet
>>>>>>> www.testingtech.com
>>>>>>> <http://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>
>>>>>>> <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/>
>>>>>>> <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>
>>>>>>> <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
> <mailto:stanca at testingtech.com>
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
> <http://www.testingtech.com>
>
> ---------------------------------------------------------------------------------------------------------------------
>
> UPCOMING EVENTS
>
> Jul 15-16, 2015 | German Testing Day
> Frankfurt, Germany | Booth #8
> www.germantestingday.info/ <http://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
> <http://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/
> <http://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 <http://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
> <mailto:stanca at testingtech.com>
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
> <http://www.testingtech.com>
>
> ---------------------------------------------------------------------------------------------------------------------
>
> UPCOMING EVENTS
>
> Jul 15-16, 2015 | German Testing Day
> Frankfurt, Germany | Booth #8
> www.germantestingday.info/ <http://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
> <http://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/
> <http://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 <http://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/a77d7ecf/attachment-0001.html>
More information about the compiler-dev
mailing list