Two-Level Adaptation for Budget-Constrained Continuous Dynamic Dependence Analysis
| Original artifact | https://figshare.com/s/424c699ba40f3eb9827a |
| Imported from | the publications page |
| Tool | pubs2github |
The artifact contains 575 file(s) including Java, Shell scripts, Config files, and Documentation.
├── code
│ ├── shell
│ │ ├── Multichat
│ │ ├── Netty
│ │ ├── NIOEcho
│ │ ├── OpenChord
│ │ ├── Thrift
│ │ ├── Voldemort
│ │ ├── xSocket
│ │ └── Zookeeper
│ └── src
│ ├── EAS
│ ├── edu
│ ├── GDist
│ ├── logging
│ ├── MciaUtil
│ ├── ODD
│ ├── profile
│ └── QL
├── data
│ ├── MultiChat
│ │ └── Maze.txt
│ ├── Netty
│ │ ├── java
│ │ └── Maze.txt
│ ├── NIOEcho
│ │ └── Maze.txt
│ ├── OpenChord
│ │ └── Maze.txt
│ ├── Thrift
│ │ ├── java
│ │ └── Maze.txt
│ ├── Voldemort
│ │ └── Maze.txt
│ ├── xSocket
│ │ ├── java
│ │ └── Maze.txt
│ └── Zookeeper
│ └── Maze.txt
├── experimentalData
│ ├── Configuration.xls
│ ├── ControlCost.xls
│ ├── Costs.xls
│ ├── Improvement.xls
│ ├── P-valueEffectSize.xls
│ ├── Parameters.xls
│ ├── PreAnalysisCosts.xls
│ ├── SignConfiguration.xls
│ ├── Subjects_MOCs.xls
│ └── TACConfiguration.xls
├── tool
│ ├── commons-cli-1.3.1.jar
│ ├── commons-io-2.6.jar
│ ├── commons-lang-2.1.jar
│ ├── commons-logging-1.2.jar
│ ├── commons-pool-1.2.jar
│ ├── DUA1.jar
│ ├── GDist.jar
│ ├── jibx-run-1.1.3.jar
│ ├── log4j.jar
│ … (12 more items)
… (647 more items)
Dynamic dependence analysis underlies various software testing and validation techniques, yet traditional approaches have limited utilities for real-world distributed systems due to challenges in scalability and balancing precision and cost, especially under user budget constraints. To overcome these challenges, we present GDist, a novel, self-adaptive dynamic dependence analysis for continuously running distributed systems. In GDist, we have developed a control-theoretical method to predict optimal analysis configurations on demand. Exploiting the prior human knowledge on the precision of different configurations, GDist learns subject-specific model parameters from subject execution characteristics. We evaluated GDist against eight continuously running distributed systems in the real world and compared it with a state-of-the-art baseline, to demonstrate its superiority.
The complete artifact package of GDist has been made available at https://figshare.com/s/328930f0c7d50dfff228, including the code, experimental scripts, and datasets. The operations and test inputs of our subjects are documented in the file "Inputs.txt".
-
Download GDist_Meterial zip file from https://figshare.com/s/328930f0c7d50dfff228
-
Unzip the file.
-
Copy all library files from the directory ”tool” of GDist to a directory (e.g., "lib") defined by the user.
-
MultiChat https://code.google.com/p/multithread-chat-server/
-
NIOEcho http://rox-xmlrpc.sourceforge.net/niotut/index.html#The code
-
OpenChord https://sourceforge.net/projects/open-chord/files/Open%20Chord%201.0/
-
xSocket https://mvnrepository.com/artifact/org.xsocket/xSocket
-
NioEcho is a simple system whose server echoes all messages from the clients.
-
MultiChat is a chat program whose clients broadcast their messages to all other clients through the server.
-
OpenChord provides peer-to-peer network services using distributed hash tables.
-
Thrift is an application development framework with a code generation engine for developing scalable cross-language services.
-
xSocket is a framework based on non-blocking IO (NIO), for constructing high-performance, scalable software systems.
-
Voldemort is a distributed key-value storage system used by LinkedIn.
-
ZooKeeper is a coordination system providing distributed synchronization and group services.
-
Netty is an asynchronous NIO framework used to rapidly develop server/client network applications.
-
2.1 Step 1 (Phase 1): Instrumentation:
We execute code/shell/#subject#/GDistInstr.sh (e.g., code/shell/xSocket/GDistInstr.sh).
-
2.2 Step 2 (Phase 2): Pre-training:
We use the existing testing data of the subject. For example, we copy the testing data files from the directory ”data/#subject#” (data/xSocket) of the package to the subject directory (e.g., xSocket) defined by the user.
In particular, for library subjects(Thrift, xSocket, and Netty), we also compile corresponding applications developed by us. For example, we compile all java files in the directory ”data/#subject#/java” (data/xSocket/java).
-
2.3 Step 3 (Phases 3 and 4): Arbitration and Adjustment:
First, we set milliseconds (e.g., 40000 for xSocket) for a user budget constraint in the file "budget.txt".
Second, we start server and client instances of the instrumented program. For example, for a xSocket integration test, we separately execute "./serverGDist.sh", "./clientGDist.sh", and "./client2GDist.sh" to start a server and two clients of the instrumented program. These two clients automatically send text messages to the server. For continuously executing the xSocket integration test, we execute "./clientGDistTimes.sh" and "./client2GDistTimes.sh" with parameters "(client execution) times" (e.g., 999).
Finally, analysis configurations vary according to our control-based strategy.
-
2.4 Step 4 (Phase 5): User Interaction:
First, we execute code/shell/#subject#/GDistQueryClient.sh (e.g., code/shell/xSocket/GDistQueryClient.sh) to start a querying client.
Then, we input a dependence query (i.e., method name) such as <org.xsocket.connection.IoSocketDispatcher: void run()>.
Eventually, we get corresponding dependencies as the outputs of GDist.