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

New disp nativecall #4645

Merged
merged 13 commits into from Nov 19, 2021
Merged

New disp nativecall #4645

merged 13 commits into from Nov 19, 2021

Conversation

lizmat
Copy link
Contributor

@lizmat lizmat commented Nov 19, 2021

No description provided.

This lets callable objects have a say in which dispatcher is used when
they are invoked.
This can be used to conditionally compile backend specific code in
modules like NativeCall
The trick of replacing the native routine's $!do attribute has never
worked perfectly as closure cloning could lead to the generic code
getting executed. For unknown reason that got a lot worse on new-disp.

Get around that by replacing the fragile $!do replacement with a
dispatcher. Using the new CUSTOM-DISPATCHER hook, native routines get
their own raku-nativecall dispatcher which for now just invokes the
optimized body or the generic one, depending on availability.

This removes the equally fragile trick with generating function bodies
in an exported CHECK phaser. To be replaced by dispatch programs at a
later point.
For explicitly managed strings, we need to pass the contained CStr value
instead of the string object itself. This way NativeCall knows not to free
the created C string after the call.

Note that the generated function bodies have never supported this. The problem
just hasn't surfaced before, because the test runs the call only once and in
the previous implementation the first call always went through the generic
calling code (which does support explicitly managed strings).
For now if we find a Proxy in a native routine's arguments, just wrap the call
in a simple function that fetches values from proxies as a side-effect.
Unboxing in HLL code can help spesh avoid boxing in the first place, thus speed
up the calls. In addition, doing concreteness checks in HLL code can get rid of
unnecessary branching.
When looking for a CUSTOM-DISPATCHER method on an object that is called, we
want to ignore fallback methods (like FALLBACK or the junction autothreader),
as those may give us an answer, even if there is no suitable CUSTOM-DISPATCHER
method available, leading to very confusing errors.
CPointer supports unboxing to int, so we should do that for the same reasons
as for which we already do this with Ints.
The raku-nativecall dispatcher handles everything these native function bodies
were needed for in a better way. Note that this means that non-MoarVM backends
use the generic nqp::nativecall op for all calls again, so this is a technically
a performance regression there. The proper fix however is for them to support
dispatchers.
We have to conditionally load this code as its using backend-specific NQP ops,
but we can at least do so at BEGIN time instead of every time someone loads the
NativeCall module.
@lizmat lizmat merged commit 254a9cb into master Nov 19, 2021
@lizmat lizmat deleted the new-disp-nativecall branch November 19, 2021 09:18
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.

None yet

2 participants