-
Notifications
You must be signed in to change notification settings - Fork 6
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
Generate types instead of generic packages for sessions #768
Comments
The transition from generic packages to tagged types led to unprovable code in some cases. The reason seems to be an extremely increased proof time. That is not only the case for the DHCP client example, but also for some simpler test cases like |
@kanigsson Proving the feature test mentioned above fails with the following message using the default configuration:
|
I noticed that for many VCs, Z3 is needed, but Z3 invariably takes close to 40s to prove the goal. Looking closer, I found that even if I introduce a typing error into the SMT file, Z3 still takes 40s to report the typing error, which makes me suspect a bug/inefficiency in the preprocessing of the VC, not the actual proving. The version of Z3 in SPARK 22.x is 4.8.12. Subsequent versions of Z3 such as 4.8.14 don't have that bug and prove most of those VCs immediately (I tried the VCs in Independently, I found SPARK wavefront (23.x) to be slightly better than 22.x, in that CVC4 proves slightly more goals. But it still contain the same faulty z3 version 4.8.12, so when Z3 is needed, we take the 40s penalty (per VC). If we update the Z3 version in SPARK wavefront, could you upgrade the Recordflux CI to SPARK wavefront? Alternatively, we could "side-load" the newer Z3, but every user of Recordflux would have to do the same. |
As discussed separately, it is fine to only support a SPARK wavefront as a temporary solution, but we count on supporting a SPARK Community with a fixed Z3 version for the next RecordFlux release (probably in Q2). In cases where a wavefront is not acceptable, we could still use the side-loading of a newer Z3 as an alternative. |
OK, I am preparing the update to Z3 4.8.14 in SPARK wavefronts. It might take several days. In the meantime the easiest is probably to replace the z3 in the SPARK install by a newer version by hand, so you can continue your work. |
Tagged types seem to require elaboration code. I get an |
I wouldn't think they generally do. @jklmnn Do you know this? |
So I just took a look and creating a tagged type seems to create a lot of code (not too surprising, as we need dynamic dispatching). I have the following unit: package Tag2
is
type R is null record;
end Tag2; This generates the following output:
With
This also includes elaboration code (probably to build the vtable?). Note that this has been compiled without optimizations, so the optimized code might be a lot smaller. |
Can you please check (with the experts) whether tagged types always require elaboration code? My point was: we just got rid of it for a reason and having to introduce elaboration code again would be somewhat annoying... |
|
The SPARK wavefront leads to a few unproven VCs that are unrelated to the introduced tagged types. For example:
There is also a bug box in multiple tests:
A full list of issues can be found here: https://github.com/Componolit/RecordFlux/actions/runs/1773673788. @kanigsson Could you please take care of that? That is the highest priority at the moment. |
For the bugbox, I think it's related to memory consumption. I put a simple fix in review which should fix at least the |
For the failed proof in the bit manipulation code, I pushed a change on issue #921 (branch issue_921). |
As I said, the bug boxes are likely due to running out of memory (I saw processes consuming up to 15GB ...). I traced this back to a change we made in november, where SPARK inlines predicates more aggressively. This doesn't work at all with the large predicates that RecordFlux generates. I will discuss this with the SPARK team. |
Context and Problem Statement
Currently, for each session, a generic package is generated. The parameters of a session (channels and functions) are mapped to formal parameters of the generic package. This may not be the optimal solution.
Considered Options
O1 Use types instead of generic packages
A type could be used to hold the state of the session state machine. The type needs to be passed to each subprogram which interacts with the state machine (e.g.,
Run
for executing the state machine). The session parameters (channels and functions) could probably be represented by abstract methods of a tagged type.See https://github.com/senier/spark_mixins_experiment for a SPARK example.
+ No need for global variables
+ Lower binary size for parallel state machines
O2 Keep generic packages
+ No changes necessary
− Multiple instances of generic package increase binary size
Decision Outcome
O1
The text was updated successfully, but these errors were encountered: