You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A major difference between SymCC and CO3, besides the decoupling is that, CO3 reads many files (i.e., the SVFGs) from the file system whenever it starts; whereas SymCC has a relatively minimal initialization task.
To be more specific, from the SVFGs files (in dot format) to the CO3 SymGraphs, there are multiple steps as depicted as below:
Currently, there are two constructors for the final SymGraphs as depicted in the figure: file construct and copy construct
This will not really matter if you just run CO3 just one time, however, CO3 can be executed endlessly (by feeding the generated alternative inputs back) or combined with a fuzzer.
Under those circumstances, the initialization task can be repetitive and heavy.
To eliminate these efforts, a natural choice is to keep some parts in memory, so that, we do not have to start from reading files everytime CO3 launches.
However, there are multiple design decisions we can make and they might have varying impact:
1. Do we want serialization?
The short answer is no, since we are not communicating these SymGraphs with another application potentially running on another machine. Serialization just poses extra unnecessary parsing efforts, and its benefits seems unimportant and not related to the initial goal.
2. Which in-memory store mechanism do we want to use?
1. shared memory object:
1. might be the fastest
2. is exclusive to Linux (although porting to other OS seems unnecessary at this point).
2. hiredis
1. cross platform
2. nice APIs
3. Which part do we want to keep in the memory:
1. dot files:
1. very easy to implement.
2. the performance gain might not be as much (as it has go through the render and parse as depicted above)
2. SymGraphs:
1. Harder to implement
2. Should be faster than 1. (however, since it also has to go through some kind of parsing, it will not be super fast as well)
4. How do we want to identify each SymGraph, Val, BBTask, when we store them in the memory?
The text was updated successfully, but these errors were encountered:
On second thought, I can just preserve the in-memory SVFG as what they are. And keep getting inputs (basically make the sym_backend do what the Python script has been doing).
A major difference between SymCC and CO3, besides the decoupling is that, CO3 reads many files (i.e., the SVFGs) from the file system whenever it starts; whereas SymCC has a relatively minimal initialization task.
To be more specific, from the SVFGs files (in dot format) to the CO3 SymGraphs, there are multiple steps as depicted as below:

Currently, there are two constructors for the final SymGraphs as depicted in the figure: file construct and copy construct
This will not really matter if you just run CO3 just one time, however, CO3 can be executed endlessly (by feeding the generated alternative inputs back) or combined with a fuzzer.
Under those circumstances, the initialization task can be repetitive and heavy.
To eliminate these efforts, a natural choice is to keep some parts in memory, so that, we do not have to start from reading files everytime CO3 launches.
However, there are multiple design decisions we can make and they might have varying impact:
1. Do we want serialization?
The short answer is no, since we are not communicating these SymGraphs with another application potentially running on another machine. Serialization just poses extra unnecessary parsing efforts, and its benefits seems unimportant and not related to the initial goal.
2. Which in-memory store mechanism do we want to use?
3. Which part do we want to keep in the memory:
4. How do we want to identify each SymGraph, Val, BBTask, when we store them in the memory?
The text was updated successfully, but these errors were encountered: