Skip to content

Conversation

@jeff5
Copy link
Owner

@jeff5 jeff5 commented Jan 1, 2026

The objective is to get unary and binary call sites working for representative special methods.

A lot has changed in SpecialMethod and 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 Representation because 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.

This brings with it some binary call site apparatus, but it is not
expected to work.
@jeff5 jeff5 marked this pull request as draft January 1, 2026 09:24
jeff5 added 3 commits January 3, 2026 08:08
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.
@jeff5
Copy link
Owner Author

jeff5 commented Jan 5, 2026

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?

jeff5 added 3 commits January 5, 2026 11:27
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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants