Blockchain is an important supporting technology for various sustainable systems. It relies on a number of distributed nodes running blockchain client software, which is responsible for some critical tasks, such as communicating with other nodes and generating new blocks. However, the quick evolution of blockchain technology brings crucial challenges to blockchain client design. After carefully examining existing blockchain client software, we have identified a critical weakness: Blockchain clients are weak in supporting live upgrades, resulting in a blockchain fork that incurs security concerns and risks. In this article, we propose Phoenix, a novel blockchain client design that is live upgradable. Phoenix uses blockchain service encapsulation to decouple blockchain services. Based on service encapsulation, we propose a live upgrade scheme that packs upgrade codes into blockchain transactions and uses a Just-In-Time engine to avoid service interruption. A parallel execution engine is developed to increase service efficiency. We evaluated Phoenix on a 51-node blockchain, and experimental results show that Phoenix outperforms existing solutions in overhead and upgrade latency.

Configuration problems are not only prevalent, but also severely impair the reliability of today's system software. One fundamental reason is the ever-increasing complexity of configuration, reflected by the large number of configuration parameters ("knobs"). With hundreds of knobs, configuring system software to ensure high reliability and performance becomes a daunting, error-prone task. This paper makes a first step in understanding a fundamental question of configuration design: "do users really need so many knobs?" To provide the quantitatively answer, we study the configuration settings of real-world users, including thousands of customers of a commercial storage system (Storage-A), and hundreds of users of two widely-used open-source system software projects. Our study reveals a series of interesting findings to motivate software architects and developers to be more cautious and disciplined in configuration design. Motivated by these findings, we provide a few concrete, practical guidelines which can significantly reduce the configuration space. Take Storage-A as an example, the guidelines can remove 51.9% of its parameters and simplify 19.7% of the remaining ones with little impact on existing users. Also, we study the existing configuration navigation methods in the context of "too many knobs" to understand their effectiveness in dealing with the over-designed configuration, and to provide practices for building navigation support in system software.

To minimize the amount of data-shuffling I/O that occurs between the pipeline stages of a distributed data-parallel program, its procedural code must be optimized with full awareness of the pipeline that it executes in. Unfortunately, neither pipeline optimizers nor traditional compilers examine both the pipeline and procedural code of a data-parallel program so programmers must either hand-optimize their program across pipeline stages or live with poor performance. To resolve this tension between performance and programmability, this paper describes PeriSCOPE, which automatically optimizes a data-parallel program's procedural code in the context of data flow that is reconstructed from the program's pipeline topology. Such optimizations eliminate unnecessary code and data, perform early data filtering, and calculate small derived values (e.g., predicates) earlier in the pipeline, so that less data - sometimes much less data - is transferred between pipeline stages. PeriSCOPE further leverages symbolic execution to enlarge the scope of such optimizations by eliminating dead code. We describe how PeriSCOPE is implemented and evaluate its effectiveness on real production jobs.

Transactional memory (TM) is a parallel programming concept which reduces challenges in parallel programming. Existing distributed transactional memory system consumes too much bandwidth and brings high latency. In this work, we present Transactional Memory System for Cluster (Clustm), a generalized and scalable distributed transactional memory system. Our system addresses several open issues posed by this domain, including transactional memory consistency protocol, cache consistency protocol, and the distribution strategy of the metadata of shared data across the cluster. Then, we evaluate our design with several workloads, and the results demonstrate outstanding performance.

The largest difference between a distributed and a non-distributed system is that the former introduces network messages to the system. Network messages bring the scalability to a distributed system as well as complexity to it. Testing large-scale distributed systems is a great challenge, because some errors happen after a distributed sequence of events that involves machine and network failures. Meld is a checker that allows developers to specify expected message logic on a deployed distributed system, and that verifies these logics while the system is running. When Meld finds a problem it starts collecting more information that led to the problem, allowing developers to quickly find the root cause. Developers write message logics on Meld and Meld verifies them through analyzing the collected abstract of messages. By using binary instrumentation, Meld works almost transparently with debugged systems and can change logics to be checked at runtime. An evaluation with a deployed system shows that Meld can detect non-trivial correctness at runtime.