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

Orchestrator's Persistent mode, to avoid the file IO and parsing them to SVFG. #3

Open
Tracked by #1
Lawliar opened this issue Apr 21, 2024 · 1 comment
Open
Tracked by #1

Comments

@Lawliar
Copy link
Owner

Lawliar commented Apr 21, 2024

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:
persistent_mode
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?

@Lawliar Lawliar mentioned this issue Apr 21, 2024
12 tasks
@Lawliar
Copy link
Owner Author

Lawliar commented May 22, 2024

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).

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

No branches or pull requests

1 participant