Trying to build a more hackable compiler...

[Wieland, Jacob]

There seem to have been some checks for bridge-methods added for java 7 which were not done for java 6. As far as I understood, bridge methods can only occur in contexts where generic types occur.
Since I only generate java 1.4 code (with no generics), these checks are obviously totally unnecessary (as are other generics-related checks and all checks that only produce warnings).

I am told that they are the reason for the massive performance degradation from java 6 to java 7/8/9 of javac (uses 4 times the CPU power, much more memory and still needs 10 to 20% more time than java 6, in my opinion related to garbage collection).

I refer to the bug https://bugs.openjdk.java.net/browse/JDK-8039262 which I hope will be addressed again in the future because this degradation is still unacceptable to me.

Of course, I would be interested how much more efficient the parallel compiler fares with the given example code ;-) Feel free to use it as a benchmark. It makes heavy use of non-static nested and anonymous classes.

BR, Jacob
________________________________________
From: compiler-dev <compiler-dev-bounces at openjdk.java.net> on behalf of Jonathan Gibbons <jonathan.gibbons at oracle.com>
Sent: Tuesday, May 10, 2016 12:20:53 AM
To: compiler-dev at openjdk.java.net
Subject: Re: Trying to build a more hackable compiler...

You can already disable (or not enable) the "unnecessary" checks with
the -Xlint option.
In general, the rest of the semantic "checks" are necessary for javac to
figure out the
meaning of your programs.

Did you have any semantic checks or performance issues in mind?

-- Jon


On 05/09/2016 01:26 AM, Wieland, Jacob wrote:
>
> If you take suggestions, give the compiler the option to generate-bytecode-only (i.e. turn off all unnecessary semantic checks). This would solve a lot of performance issues I have when compiling generated java-surce-code (that I know is semantically correct, so semantic checks produce only warmth and consume time).
>
>
>
> Dr. Jacob Wieland
> Senior Software Engineer
> ________________________________________
> From: compiler-dev <compiler-dev-bounces at openjdk.java.net> on behalf of Robert Olofsson <robert.olofsson at khelekore.org>
> Sent: Tuesday, January 19, 2016 8:08:19 PM
> To: compiler-dev at openjdk.java.net
> Subject: Trying to build a more hackable compiler...
>
> Hi!
>
> Some time ago I started reading the code for javac and I realized that
> it is not a project that is easy to work on. I also realized that there
> are other people that want a compiler that is easier to hack. A few
> of the things that are requested are:
> * Grammar based parser
> * Better multi threading
>
> I did try to make a few patches for javac to at least make it better
> multi threaded, but realized that this was really hard to do, at
> least for the code I looked at. Too much global state in the lexer
> and parser.
>
> I realized that I actually did take a few compiler related courses
> so time to build something on my own, as a proof of concept. In case
> you want to take a look: https://github.com/robert-olofsson/parjac
>
> Initial thoughts:
> * Making lexing + parsing run in parallel is easy
> * Setting classes on types in parallel is easy
> * Checking other semantics in parallel is easy
> * Writing bytecode in parallel is easy
>
> Parsing a reasonably big code tree (27195 files with
> 11022 of them being java) and outputting class files
> containing hello-world like methods with the correct signatures
> is quite a lot faster than javac doing a full compile and my
> computer is a nuc i7, so not many cores.
> Sure, this is a bit of apples vs oranges, but it still
> indicates that it is quite possible to fulfill the wishes
> of a grammar based multi threaded compiler. The heavy
> part is currently parsing.
>
> I do know of the antlr-javac experiment, but it seems to
> have died, not sure what will happen to it. My experiments
> with antlr indicated that it is too hard to use for a java 8
> grammar and it seems like it ended up being slower than
> ordinary javac.
>
> If this is considered advertising a non javac-compiler I do
> apologize, my end goal is to make javac (based on current code or some
> other code) be a better compiler and for now I only want to show that it
> seems possible to make it better.
>
> /robo
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information belonging to Spirent Communications plc, its affiliates and / or subsidiaries. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution and / or the taking of any action based upon reliance on the contents of this transmission is strictly forbidden. If you have received this message in error please notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300