From amp at cs.utexas.edu Fri Oct 13 00:47:51 2017 From: amp at cs.utexas.edu (Arthur Peters) Date: Thu, 12 Oct 2017 19:47:51 -0500 Subject: Detecting when compilations occur Message-ID: <1404935f-9951-dcb8-04ea-8ecc6f7f4836@cs.utexas.edu> Is there any way to detect when Truffle/Graal compilations happen? (for instance by getting a callback or even just accessing a count of how many compilations have happened so I can check if it has changed.) I would like to have this information for my benchmarking so I can easily tag repetitions of the benchmark that have a compilation. This would be useful for analyzing how fast the code generated by the compiler is independent of the compiler itself and visa versa. -Arthur PS: I'm not going to just remove all the repetitions with compilations. That would not really represent the performance of the language. But it would be nice to be able to do subgroup analysis. From petr.tuma at d3s.mff.cuni.cz Fri Oct 13 06:17:19 2017 From: petr.tuma at d3s.mff.cuni.cz (=?UTF-8?Q?Petr_T=c5=afma?=) Date: Fri, 13 Oct 2017 08:17:19 +0200 Subject: Detecting when compilations occur In-Reply-To: <1404935f-9951-dcb8-04ea-8ecc6f7f4836@cs.utexas.edu> References: <1404935f-9951-dcb8-04ea-8ecc6f7f4836@cs.utexas.edu> Message-ID: <76f0c02f-0e0d-59fa-77e9-129d61887bd5@d3s.mff.cuni.cz> Hi Arthur, some options, depending on what exactly you want: - you could catch the JVMTI CompiledMethodLoad event callback, this needs a C agent but otherwise should work quite well - you could query the CompilationMXBean in java.lang.management, this gives you the aggregate compilation time in milliseconds (this will jump forward on compilation end but sub millisecond compilation events will not be visible) - you can monitor the execution time of the compiler threads - you can enable the JVM compilation log (-XX:+PrintCompilation), this includes time relative to JVM start so can be correlated with benchmark iterations if they are long enough Some of these are implemented in https://github.com/D-iii-S/java-ubench-agent, you can take a look for inspiration. Hope this helps, Petr On 13/10/17 02:47, Arthur Peters wrote: > Is there any way to detect when Truffle/Graal compilations happen? (for > instance by getting a callback or even just accessing a count of how > many compilations have happened so I can check if it has changed.) > > I would like to have this information for my benchmarking so I can > easily tag repetitions of the benchmark that have a compilation. This > would be useful for analyzing how fast the code generated by the > compiler is independent of the compiler itself and visa versa. > > -Arthur > > PS: I'm not going to just remove all the repetitions with compilations. > That would not really represent the performance of the language. But it > would be nice to be able to do subgroup analysis. > From java at stefan-marr.de Fri Oct 13 09:34:57 2017 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 13 Oct 2017 10:34:57 +0100 Subject: Detecting when compilations occur In-Reply-To: <76f0c02f-0e0d-59fa-77e9-129d61887bd5@d3s.mff.cuni.cz> References: <1404935f-9951-dcb8-04ea-8ecc6f7f4836@cs.utexas.edu> <76f0c02f-0e0d-59fa-77e9-129d61887bd5@d3s.mff.cuni.cz> Message-ID: <8C179922-084E-4B2E-B2BF-4217EC932482@stefan-marr.de> Hi Petr: > On 13 Oct 2017, at 07:17, Petr T?ma wrote: > > Some of these are implemented in https://github.com/D-iii-S/java-ubench-agent, you can take a look for inspiration. Thanks for sharing. The agent looks very interesting. Best regards Stefan -- Stefan Marr School of Computing, University of Kent http://stefan-marr.de/research/ From amp at cs.utexas.edu Fri Oct 13 16:11:18 2017 From: amp at cs.utexas.edu (Arthur Peters) Date: Fri, 13 Oct 2017 11:11:18 -0500 Subject: Detecting when compilations occur In-Reply-To: <76f0c02f-0e0d-59fa-77e9-129d61887bd5@d3s.mff.cuni.cz> References: <1404935f-9951-dcb8-04ea-8ecc6f7f4836@cs.utexas.edu> <76f0c02f-0e0d-59fa-77e9-129d61887bd5@d3s.mff.cuni.cz> Message-ID: <80c62bfa-9eb1-6da4-476f-a1f1b09a5eff@cs.utexas.edu> Thanks! I had not thought of CompilationMXBean for some reason. Does CompilationMXBean.getTotalCompilationTime() include Truffle compile time? Looking at the numbers it seems like it might not, but it's hard to tell. -Arthur On 10/13/2017 01:17 AM, Petr T?ma wrote: > Hi Arthur, > > some options, depending on what exactly you want: > > - you could catch the JVMTI CompiledMethodLoad event callback, this > needs a C agent but otherwise should work quite well > > - you could query the CompilationMXBean in java.lang.management, this > gives you the aggregate compilation time in milliseconds (this will > jump forward on compilation end but sub millisecond compilation events > will not be visible) > > - you can monitor the execution time of the compiler threads > > - you can enable the JVM compilation log (-XX:+PrintCompilation), this > includes time relative to JVM start so can be correlated with > benchmark iterations if they are long enough > > Some of these are implemented in > https://github.com/D-iii-S/java-ubench-agent, you can take a look for > inspiration. > > Hope this helps, Petr > > > On 13/10/17 02:47, Arthur Peters wrote: >> Is there any way to detect when Truffle/Graal compilations happen? (for >> instance by getting a callback or even just accessing a count of how >> many compilations have happened so I can check if it has changed.) >> >> I would like to have this information for my benchmarking so I can >> easily tag repetitions of the benchmark that have a compilation. This >> would be useful for analyzing how fast the code generated by the >> compiler is independent of the compiler itself and visa versa. >> >> -Arthur >> >> PS: I'm not going to just remove all the repetitions with compilations. >> That would not really represent the performance of the language. But it >> would be nice to be able to do subgroup analysis. >> From jackson at jcdav.is Mon Oct 30 17:27:56 2017 From: jackson at jcdav.is (Jackson Davis) Date: Mon, 30 Oct 2017 10:27:56 -0700 Subject: An introduction and some questions Message-ID: Hello, I've been trying to finally introduce myself to graal over the last few days, with a hope I can maybe sneak in a few changes when I have time - its an interesting project :) On the non-technical side: Whats with the [GR-XXXX] in commit messages, is this a private issue tracker? I don't see anything on the graal project on openjdk jira, or anywhere else for that matter. On the technical side: I've been looking into optimizing the code generation on x86 for add/sub/shl. Currently, if reg1 and reg2 are different, reg2 = add reg1, C generates mov %reg1, %reg2 add C, %reg2 This can be folded into a single lea C(%reg1), %reg2 (if there is no resulting operation dependent on flags being set). We can do the same for sub, and for shl if C=1/2/3. I have a very basic attempt of this working-ish here: https://github.com/jcdavis/graal/commit/6d27c585726b64259635f36542263ca0cde3dcf1 . This currently always uses leaq, which is at best 1 byte longer than it needs to be for 32 bit operands (since the REX prefix isn't necessary), and at worst possibly wrong because over/underflow will set the high order 32 bits (which might be ok? But unsure). It also misses add/sub by 1 (since those are lowered to MOp, not ConstOp), and also doesn't consider %reg3 = %reg1 + %reg2 (which can also be represented as an lea) Where I am a little lost is how to clean this up properly. I was thinking a new emit function that also takes a source register x could be added, which be default would still call the same move + emit, and then, individual opcodes could override that behavior as necessary? Thanks, -Jackson From doug.simon at oracle.com Mon Oct 30 19:53:01 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 30 Oct 2017 20:53:01 +0100 Subject: An introduction and some questions In-Reply-To: References: Message-ID: <74643684-E1AA-4DA5-9E7E-1E23D390BA02@oracle.com> Welcome Jackson! > On 30 Oct 2017, at 18:27, Jackson Davis wrote: > > Hello, > > I've been trying to finally introduce myself to graal over the last few > days, with a hope I can maybe sneak in a few changes when I have time - its > an interesting project :) > > On the non-technical side: Whats with the [GR-XXXX] in commit messages, is > this a private issue tracker? I don't see anything on the graal project on > openjdk jira, or anywhere else for that matter. These are indeed related to an internal jira instance Graal shares with a number of other projects at Oracle Labs, some of which are not open source. We also respond to issues and pull requests at https://github.com/graalvm/graal. > On the technical side: I've been looking into optimizing the code > generation on x86 for add/sub/shl. Currently, if reg1 and reg2 are > different, reg2 = add reg1, C generates > mov %reg1, %reg2 > add C, %reg2 > > This can be folded into a single lea C(%reg1), %reg2 (if there is no > resulting operation dependent on flags being set). We can do the same for > sub, and for shl if C=1/2/3. I have a very basic attempt of this > working-ish here: > https://github.com/jcdavis/graal/commit/6d27c585726b64259635f36542263ca0cde3dcf1 > . This currently always uses leaq, which is at best 1 byte longer than it > needs to be for 32 bit operands (since the REX prefix isn't necessary), and > at worst possibly wrong because over/underflow will set the high order 32 > bits (which might be ok? But unsure). It also misses add/sub by 1 (since > those are lowered to MOp, not ConstOp), and also doesn't consider %reg3 = > %reg1 + %reg2 (which can also be represented as an lea) > > Where I am a little lost is how to clean this up properly. I was thinking a > new emit function that also takes a source register x could be added, which > be default would still call the same move + emit, and then, individual > opcodes could override that behavior as necessary? I would suggest implementing and testing your suggestion then submitting a PR on github to allow someone more familiar than I am with this part of the compiler to offer feedback. -Doug