-
Notifications
You must be signed in to change notification settings - Fork 97
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
Add kani::spawn and an executor to the Kani library #1659
Conversation
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.
More tests please! :)
|
The latest CI run failed for @celinval: could this be related to the new linker? If the scheduling code is in the same file, like in |
Yes,
Yes, the main purpose of the new linker was to get rid of the undefined symbols from the standard library. Fixing this issue meant that some models got bigger and harder to process. |
@celinval That makes sense. What I don't get is that it works fine if all the scheduling code is in the same file, see |
I see. Let me take a look, but it is possible that moving the file into a different crate changed how rustc optimizes the code. |
I looked at the issue you mentioned, and I think the difference is due to the second harness in The interesting thing is that the time is pretty bad even if you run You can see a similar effect with the |
@celinval Thanks for that investigation. I've removed the nondeterministic test for now to make CI (hopefully) pass. I've also converted a |
Hm, seems like CI still runs out of memory. I'm not sure what to do about that. Any ideas? |
Can you run it locally and measure the memory consumption so we have an idea on how bad the problem is? |
@celinval I renamed the function If you don't have any other concerns, this should be ready to be merged. |
Hi @fzaiser, I think this is good to go, except that I think we should add a mechanism to guard this code under a |
Hi @fzaiser, I just wanted to let you know that we have merged the unstable API code, so you should be good to go. Please tag all public functions in this PR as unstable. |
Kani compiler used to generate one `goto-program` for all harnesses in one crate. In some cases, this actually had a negative impact on the harness verification time. This was first reported in #1659 The main changes were done in the compiler's module `compiler_interface` and the module `project` from the driver. The compiler will now gather all the harnesses beforehand and it will perform reachability + codegen steps for each harness. All files related to a harness `goto-program` will follow the naming convention bellow: ``` <BASE_NAME>_<MANGLED_NAME>.<EXTENSION> ``` This applies to symtab / goto / type_map / restriction files. The metadata file is still generated once per target crate, and its name is still the same (`<BASE_NAME>.kani-metadata.json`). On the driver side, the way we process the artifacts have changed. The driver will now read the metadata for each crate, and collect all artifacts based on the symtab goto file that is recorded in the metadata of each harness. These changes do not apply for `--function`. We still keep all artifacts based on the crate's `<BASE_NAME>` and we have a separate logic to handle that. Fixing this is captured by #2129.
@celinval This should be good to go :) Could you please merge this if you're happy with it? |
I'm not sure what the perf-benchcomp failure is about. Could it be spurious? Any ideas? |
Yes, this is most likely spurious due to variance in performance. The |
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.
Thanks! Can you please add a reason to the unstable attribute? It could be something "recently added" or something like "experimental API". @adpaco-aws any suggestion?
I'd suggest "experimental async support/library" or something along those lines. Also, thanks @fzaiser for persistence on this one! |
@celinval Thanks for reviewing and making the final changes for the merge! 🎉 |
…unctions (#1661) Instead of having to manually wrap the code in `kani::spawnable_block_on` as in #1659, this PR allows `#[kani::proof]` to be applied to harnesses that use `spawn` as well. For this to happen, the user has to specify a scheduling strategy. Co-authored-by: Celina G. Val <[email protected]>
Description of changes:
This adds an executor (scheduler for async futures) to the Kani library, thus supporting
kani::spawn
as a replacement fortokio::spawn
.It also includes
kani::yield_now
which is similar totokio::yield_now
.Resolved issues:
Resolves #1504
Call-outs:
Testing:
How is this change tested? Additional regression tests.
Is this a refactor change? No.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.