Ignore JavaInteropSpeedTest. #112
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zapster
force-pushed
the
ignore-java-interop-speed-test
branch
from
b01d27c to
16f5898
Compare
|
Is there anyone who knows how to "Convert into a microbenchmark!"? Who will be responsible for that? |
|
@jtulach I can do that (actually I have already done it and I wanted to add it to this PR but then we stumbled over #113). But there are two question: First, the benchmark makes only sense if executed with the graal truffle implementation, right? If so I would put the benchmark inside the graal source tree. The infrastructure is already there. (If we put it into truffle we need to add a JMH dependency.) Second and even more important, who is going to monitor the benchmark? The unittest variant was flaky for weeks and it turned out that it was not doing anything (because of #113). |
|
As far as the monitoring goes, I'd suggest to follow work done in #101 - it allows downstream projects to run the test they need and still provide feedback to each truffle pull request. |
|
Sounds promising! But we need to keep in mind that this is not a test that says OK or NG. It is a performance number. Deciding automatically whether there is a regression is not trivial IMHO. |
|
The alternative is to have the test code in the truffle repository and only execute it if the optimizing runtime is present. Plus configure travis to get the latest binary of graal-core and run |
|
Well, it is not a unittest, it is an |
|
Truffle repository contains various distributions. Adding the JMH dependency to |
dougxc
pushed a commit
that referenced
this pull request
Jun 26, 2016
…/truffle:fix_dsl_for_eclipse_neon to master * commit '9d6708adf9d1a57d32f15ecd5bf2063790d83244': Fix DSL JDT compiler support for Eclipse Neon.
XiaohongGong
pushed a commit
to XiaohongGong/graal
that referenced
this pull request
Apr 20, 2020
…inter. Trapping nullcheck might generate two uncompress instructions for the same compressed oop in Graal. One is inserted by the backend when it emits nullcheck. If the pointer is a compressed object, it should be uncompressed before the nullcheck is emitted. And another one is generated by the normal uncompressing operation. These two instructions are duplicated with each other. The generated codes on AArch64 like: ldr w0, [x0,oracle#112] lsl x2, x0, oracle#3 ; uncompressing (first) ldr xzr, [x2] ; implicit exception: deoptimizes ...... ; fixed operations lsl x0, x0, oracle#3 ; uncompressing (second) str w1, [x0,oracle#12] A simple way to avoid this is to apply the nullcheck to the uncompressed result if it exists instead of to the compressed pointer when generating the trapping nullcheck. With the modification, the codes above could be optimized to: ldr w0, [x0,oracle#112] lsl x0, x0, oracle#3 ; uncompressing ldr xzr, [x0] ; implicit exception: deoptimizes ...... ; fixed operations str w1, [x0,oracle#12] Change-Id: Iabfe47bbf984ed11c42555f84bdd0ccf2a5bdddb
XiaohongGong
pushed a commit
to XiaohongGong/graal
that referenced
this pull request
Apr 23, 2020
…inter. Trapping nullcheck might generate two uncompress instructions for the same compressed oop in Graal. One is inserted by the backend when it emits nullcheck. If the pointer is a compressed object, it should be uncompressed before the nullcheck is emitted. And another one is generated by the normal uncompressing operation. These two instructions are duplicated with each other. The generated codes on AArch64 like: ldr w0, [x0,oracle#112] lsl x2, x0, oracle#3 ; uncompressing (first) ldr xzr, [x2] ; implicit exception: deoptimizes ...... ; fixed operations lsl x0, x0, oracle#3 ; uncompressing (second) str w1, [x0,oracle#12] A simple way to avoid this is to apply the nullcheck to the uncompressed result if it exists instead of to the compressed pointer when generating the trapping nullcheck. With the modification, the codes above could be optimized to: ldr w0, [x0,oracle#112] lsl x0, x0, oracle#3 ; uncompressing ldr xzr, [x0] ; implicit exception: deoptimizes ...... ; fixed operations str w1, [x0,oracle#12] Change-Id: Iabfe47bbf984ed11c42555f84bdd0ccf2a5bdddb
XiaohongGong
pushed a commit
to XiaohongGong/graal
that referenced
this pull request
May 9, 2020
Trapping nullcheck might generate two uncompress instructions for the same compressed oop on AArch64. One is inserted by the backend when it emits nullcheck. If the object is a compressed pointer, it is uncompressed before the nullcheck is emitted. And another one is generated by the uncompression node used for memory access. These two instructions are duplicated with each other. The generated codes on AArch64 like: ldr w0, [x0,oracle#112] lsl x2, x0, oracle#3 ; uncompressing (first) ldr xzr, [x2] ; implicit exception: deoptimizes ...... ; fixed operations lsl x0, x0, oracle#3 ; uncompressing (second) str w1, [x0,oracle#12] A simple way to avoid this is to creat a new uncompression node for the nullcheck, and let the value numbering remove the duplicated one if possible. Since the address lowering of AMD64 can handle the uncompressing computation for address, the created uncompression node is wrapped to an address node and the nullcheck is finally applied on the address. With the modification, the codes above could be optimized to: ldr w0, [x0,oracle#112] lsl x0, x0, oracle#3 ; uncompressing ldr xzr, [x0] ; implicit exception: deoptimizes ...... ; fixed operations str w1, [x0,oracle#12] Change-Id: Iabfe47bbf984ed11c42555f84bdd0ccf2a5bdddb
XiaohongGong
pushed a commit
to XiaohongGong/graal
that referenced
this pull request
May 13, 2020
Trapping nullcheck might generate two uncompress instructions for the same compressed oop on AArch64. One is inserted by the backend when it emits nullcheck. If the object is a compressed pointer, it is uncompressed before the nullcheck is emitted. And another one is generated by the uncompression node used for memory access. These two instructions are duplicated with each other. The generated codes on AArch64 like: ldr w0, [x0,oracle#112] lsl x2, x0, oracle#3 ; uncompressing (first) ldr xzr, [x2] ; implicit exception: deoptimizes ...... ; fixed operations lsl x0, x0, oracle#3 ; uncompressing (second) str w1, [x0,oracle#12] A simple way to avoid this is to creat a new uncompression node for the nullcheck, and let the value numbering remove the duplicated one if possible. Since the address lowering of AMD64 can handle the uncompressing computation for address, the created uncompression node is wrapped to an address node and the nullcheck is finally applied on the address. With the modification, the codes above could be optimized to: ldr w0, [x0,oracle#112] lsl x0, x0, oracle#3 ; uncompressing ldr xzr, [x0] ; implicit exception: deoptimizes ...... ; fixed operations str w1, [x0,oracle#12] Change-Id: Iabfe47bbf984ed11c42555f84bdd0ccf2a5bdddb
fniephaus
pushed a commit
to hpi-swa-lab/graal
that referenced
this pull request
Oct 19, 2020
…ontext-per-example Bugfix: use nested context for each example
XiaohongGong
pushed a commit
to XiaohongGong/graal
that referenced
this pull request
Nov 6, 2020
Trapping nullcheck might generate two uncompress instructions for the same compressed oop on AArch64. One is inserted by the backend when it emits nullcheck. If the object is a compressed pointer, it is uncompressed before the nullcheck is emitted. And another one is generated by the uncompression node used for memory access. These two instructions are duplicated with each other. The generated codes on AArch64 like: ldr w0, [x0,oracle#112] lsl x2, x0, oracle#3 ; uncompressing (first) ldr xzr, [x2] ; implicit exception: deoptimizes ...... ; fixed operations lsl x0, x0, oracle#3 ; uncompressing (second) str w1, [x0,oracle#12] A simple way to avoid this is to creat a new uncompression node for the nullcheck, and let the value numbering remove the duplicated one if possible. Since the address lowering of AMD64 can handle the uncompressing computation for address, the created uncompression node is wrapped to an address node and the nullcheck is finally applied on the address. With the modification, the codes above could be optimized to: ldr w0, [x0,oracle#112] lsl x0, x0, oracle#3 ; uncompressing ldr xzr, [x0] ; implicit exception: deoptimizes ...... ; fixed operations str w1, [x0,oracle#12]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The test tries to find performance regressions in the java interop implementation by comparing invocation time which is highly system dependent and fails regularly on different machines. Doing this in a unit test is sub-optimal. It should be converted into a microbenchmark.