Port call sites from VSJ 3 #13
Draft
Conversation
This file contains hidden or 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
This brings with it some binary call site apparatus, but it is not expected to work.
For clarity, we separate our tests of correctness and re-linking. We make the tests work with a mixture types and parameterise the operation, and that way end up with fewer test methods.
Quite complex, so committing now and adding tests next.
We create a custom sub-class to mix with built-in types in the test.
Owner
Author
|
I'm pleased this works, but its an awfully complicated handle, with multiple casts. Considering the limits to inlining of the call-site graph by the JVM, would I be better creating a trampoline method in Java and a handle on that? |
This greatly simplifies the bounce handle.
And add op_pos to tests because we foresee never needing a cache for that.
A second layer reveals a bug, and that we aren't using the generic handle enough (given we do not propagate change to subclasses).
We implement BinaryOpCallSite based on VSJ3. THere are substantial changes and a beefed up test. We discover the advantages of permitting the arguments on the cached method handle. Old code still lingers in PyRT as we haven't finished with the BinopGrid idea.
We used to throw EmptyException for all operations, but it is more efficient to insert a handle that returns NotImplemented. We add tests of raising a TypeError so we test all affected paths. Not yet testing caches for binary ops.
As the first cache for a binary special method, this exposes (and we fix) a number of bugs in handle formation and use in the call site.
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 objective is to get unary and binary call sites working for representative special methods.
A lot has changed in
SpecialMethodand the type system since VSJ3. We have a clearer notion of shared representation and mutable type. This affects the detail of call sites, although the VSJ 3 design stands up well.At present, all special methods are implemented by handles that look up a descriptor on the type, which is never going to be fast. Type object initialisation and update does not need to update handles cached on the
Representationbecause they are generic. We have not so far felt it worth updating call site targets to generic handles, so none of the architecture we intend is yet in play.In order to exercise this properly, we need to generate code with call sites. A separate sub-project seems appropriate (but not as messy as
dy3bm). We shall maybe dip a toe into the code generation end of compilation.Plenty to do.