Skip to content
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

Conversation

grimmerm
Copy link
Contributor

There is a need to simplify interop API to:

  • make it more type-safe
  • encourage exception handling
  • make its use less verbose

@chumer
Copy link
Member

chumer commented Jan 25, 2016

Please don't create additional branches in the main repo. (feature/instrumentation_api is an exception).
Instead create a fork and create a pull-request from your fork. Give people access to your fork for those you want to collaborate with.

@chumer
Copy link
Member

chumer commented Jan 25, 2016

Please delete this branch after you have closed the pull-request.

@jtulach
Copy link
Contributor

jtulach commented Jan 25, 2016

I did an API signature check and following generated classes are public. I think they should be package private:

Added Classes
-------------

com.oracle.truffle.tck.ComplexNumberAEntryForeign
com.oracle.truffle.tck.ComplexNumberBEntryForeign
com.oracle.truffle.tck.ComplexNumberForeign
com.oracle.truffle.tck.ComplexNumbersAForeign
com.oracle.truffle.tck.ComplexNumbersBForeign

@@ -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

Copy link
Contributor

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.

Copy link
Member

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?

@chumer
Copy link
Member

chumer commented Jan 25, 2016

@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
*/
Copy link
Contributor

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?

@woess
Copy link
Member

woess commented Jan 25, 2016

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.

@grimmerm
Copy link
Contributor Author

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 {
Copy link
Contributor

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.

@jtulach
Copy link
Contributor

jtulach commented Jan 27, 2016

I like the change and I am about to merge it once we solve problems with Javadoc.

@jtulach jtulach self-assigned this Jan 27, 2016
jtulach added a commit that referenced this pull request Jan 27, 2016
…enerate-classes-for-message-resolution

AcceptMessage annotation. Its annotation processor. InteropException and its subclasses. Specialized sendXYZ methods in ForeignAccess class.
@jtulach jtulach merged commit bce21f2 into master Jan 27, 2016
@jtulach jtulach deleted the interop/annotation-processor-to-generate-classes-for-message-resolution branch January 27, 2016 10:50
@woess
Copy link
Member

woess commented Jan 27, 2016

For the record, I didn't review this change (not enough time).

dougxc pushed a commit that referenced this pull request Jul 11, 2016
* commit '3ca08c7bb8628665580317807776648d5504d6db':
  Add failing test for DSL processor bug with negated guard + @cached.
XiaohongGong pushed a commit to XiaohongGong/graal that referenced this pull request Feb 24, 2020
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
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
kipply added a commit to Shopify/graal that referenced this pull request Apr 24, 2020
Add support for killing compiler threads
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
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants