-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interop: annotation processor to generate classes for message resolution #12
Interop: annotation processor to generate classes for message resolution #12
Conversation
Please don't create additional branches in the main repo. (feature/instrumentation_api is an exception). |
Please delete this branch after you have closed the pull-request. |
I did an API signature check and following generated classes are public. I think they should be package private:
|
@@ -16,6 +16,8 @@ CLSS public abstract interface !annotation com.oracle.truffle.api.interop.java.M | |||
intf java.lang.annotation.Annotation | |||
meth public abstract java.lang.String message() | |||
|
|||
CLSS abstract interface com.oracle.truffle.api.interop.java.package-info | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't change the signature files, please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
package-info should never be part of a signature file, or should it?
@jtulach shouldn't be the API signature check be part of the gate? Or is it and it was just not run? We have the ability to spawn arbitrary stuff in parallel in travis, we should probably do that for the api signature check. Re. (by @jtulach): yes, we can run it but how it shall report the "failure"? |
* @throws IllegalAccessError if the <code>receiver</code> does not support the | ||
* {@link Message#createNode() message represented} by <code>foreignNode</code> | ||
* @throws IllegalStateException if any error occurred while accessing the <code>receiver</code> | ||
* object | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't you want to deprecate this method?
I would like to see some examples of the code generated by this annotation processor rather than having to infer it from the source code. |
Unless there are objections, let this be merged on Wed. |
* @throws UnsupportedMessageException if the <code>receiver</code> does not support the | ||
* {@link Message#createNode() message represented} by <code>executeNode</code> | ||
*/ | ||
public static Object sendExecute(Node executeNode, VirtualFrame frame, TruffleObject receiver, Object[] arguments) throws UnsupportedTypeException, ArityException, UnsupportedMessageException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using varargs for the arguments argument might be more comfortable for the caller.
I like the change and I am about to merge it once we solve problems with Javadoc. |
…lasses-for-message-resolution
…enerate-classes-for-message-resolution AcceptMessage annotation. Its annotation processor. InteropException and its subclasses. Specialized sendXYZ methods in ForeignAccess class.
For the record, I didn't review this change (not enough time). |
* commit '3ca08c7bb8628665580317807776648d5504d6db': Add failing test for DSL processor bug with negated guard + @cached.
This patch adds the following match rules to generate bitfield move instruction on AArch64: * (RightShift (LeftShift value a) b) -> SBFX/SBFIZ * (UnsignedRightShift (LeftShift value a) b) -> UBFX/UBFIZ * (LeftShift (SignExtend value) a) -> SBFIZ Eg: lsl w0, w1, oracle#8 asr w0, w0, oracle#15 is optimized to: sbfx w0, w1, oracle#7, oracle#17 It also adds the rules to integrate the ZeroExtend with unsigned bitfield move operation. Eg: ubfiz w0, w1, oracle#5, oracle#12 and x0, x0, #0xffffffff is optimized to: ubfiz x0, x1, oracle#5, oracle#12 Change-Id: I2b635d4895db0d5f4c30630176f336e9a226ccaf
…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
…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
Add support for killing compiler threads
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
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
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]
There is a need to simplify interop API to: