Reducing register pressure in SMT processors through L2-miss-driven early register release The register file is one of the most critical datapath components limiting the number of threads that can be supported on a simultaneous multithreading (SMT) processor. To allow the use of smaller register files without degrading performance, techniques that maximize the efficiency of using registers through aggressive register allocation/deallocation can be considered. In this article, we propose a novel technique to early deallocate physical registers allocated to threads which experience L2 cache misses. This is accomplished by speculatively committing the loadindependent instructions and deallocating the registers corresponding to the previous mappings of their destinations, without waiting for the cache miss request to be serviced. The early deallocated registers are then made immediately available for allocation to instructions within the same thread as well as within other threads, thus improving the overall processor throughput. On the average across the simulated mixes of multiprogrammed SPEC 2000 workloads, our technique results in 33% improvement in throughput and 25% improvement in terms of harmonic mean of weighted IPCs over the baseline SMT with the state-of-the-art DCRA policy. This is achieved without creating checkpoints, maintaining per-register counters of pending consumers, performing tag rebroadcasts, register remappings, and/or additional associative searches. Simultaneous multithreading (SMT) is an important architectural paradigm for increasing microprocessor throughput in an area-efficient manner by sharing the key datapath resources among the instructions from multiple threads of control [Marr et al. 2002; Tullsen et al. 1996] . One such shared resource in an SMT datapath is the physical register file (RF), which needs to be sized very generously to support the full architectural register state of each thread as well as to provide a sufficient number of additional registers for renaming, typically all within a common RAM structure. For example, for an ISA with 32 architectural registers, 128 registers are needed to maintain the precise state for a four-threaded SMT, in both integer and floating point RFs. When renaming registers are taken into account, the total number of entries within each RF can reach several hundred. The large access delays, high power consumption, and significant design complexity associated with such RFs are major factors limiting the number of simultaneous threads that can be supported by an SMT machine, especially at high-frequency implementations. Pipelining the access to large RFs over several cycles requires multiple levels of bypass and also lengthens the branch resolution and the load-hit speculation loops [Borch et al. 2002] .. An alternative to building large RFs is to use a smaller number of registers in a more efficient fashion. The higher efficiency of using physical registers in an SMT processor can be achieved by addressing two related issues: (1) how to distribute the available registers among the threads, and (2) how to manage these registers to provide a larger supply of them for distribution. We generically refer to these two key aspects as register distribution and register management.. Register Distribution. This issue is addressed in the recent literature through a series of proposals, such as I-Count [Tullsen et al. 1996] , STALL [Tullsen et al. 2001] , FLUSH [Tullsen et al. 2001] , DCRA [Cazorla et al. 2004] , and Hill-Climbing [Choi and Yeung 2006] techniques. I-Count gives fetching (and thus register allocation) priority to threads with fewer not-yet-executed instructions. The FLUSH mechanism completely squashes a thread that experienced a long-latency L2 cache miss, releasing all physical registers allocated to this thread and assigning them to other threads while the cache miss is being serviced. The STALL mechanism simply blocks further resource allocations to such threads, without squashing the in-flight instructions. FLUSH generally provides higher performance than STALL [Tullsen et al. 2001 ], but it also incurs nontrivial overheads, because the squashed instructions have to always be refetched, rescheduled, reexecuted, and all shared resources have to be reallocated to these instructions again. Consequently, the first allocations, performed prior to the discovery of a cache miss, just waste the resources, even for the load-independent instructions that executed without problems. The DCRA policy takes a different approach and instead allocates more resources to memory-bound threads, attempting to help their performance. The Hill-Climbing mechanism further improves on DCRA by observing the impact of resource distribution decisions at run time and feeding this information back to the front end of the pipeline to guide future allocations.. Register Management. All of the above approaches still work within the traditional register management framework. Traditional register allocation and deallocation mechanisms, both on superscalar and SMT processors, are very conservative-a physical register allocated to the destination of an instruction is released only when the next instruction (from the same thread) writing to the same destination architectural register commits. Several techniques have been proposed in the literature (all in the domain of superscalar processors) to relax these conditions and achieve higher efficiency of register usage. These techniques can be broadly classified into three groups: late allocation mechanisms [Gonzáles et al. 1998; Monreal et al. 2004] , early deallocation mechanisms [Lipasti et al. 2004; Martinez et al. 2002; Monreal et al. 2002; and register-sharing mechanisms [Balakrishan and Sohi 2003] . While it is possible to trivially extend at least some of these approaches to an SMT machine, the complexity of the resulting solution (which is already high in superscalars) could further escalate on SMT if the modifications to the thread-specific resources are required. In particular, these techniques often require wake-up tag rebroadcasts, register remappings, additional associative searches within the issue queue and the rename table, deadlock avoidance techniques and/or periodic creation of full register file checkpoints. In this article, we seek solutions for improving the register-management mechanisms, but without incurring the complications of the aforementioned designs. Moreover, the scheme that we propose can be used in conjunction with all of these techniques, as it exploits different opportunities for optimizing register usage.. Our solution is motivated by the observation that the primary reason for having a large number of physical registers in the RF, especially on SMT processors, is the capability to buffer a sizable number of in-flight instructions following a load that misses into the L2 cache. Figure 1 compares the performance of a four-threaded SMT machine with perfect L2 cache and one with the realistic L2 cache of 2MB for various RF sizes. As shown in the graph, the performance saturates at 200 registers in the former case, and at around 300 registers in the latter case (details of our simulation framework are provided in Section 3). Consequently, if the registers assigned to the instructions waiting for the resolution of the L2 cache miss were not tied up, a much smaller RF would be sufficient to maintain the same performance level. Alternatively, a considerably higher performance would be realized using the similarly sized RFs. As the L2 cache misses are relatively more frequent on SMT (because the caches are shared among multiple threads) and physical registers are relatively scarcer compared to a superscalar, it is important to consider techniques for optimizing the RF usage under the L2 cache misses. A technique to perform such lazy deallocation of registers in the shadow of L2 cache misses is the main contribution of this article. As detailed in Section 2, the timing and the conditions for this deallocation are disjoint from those used by the previous schemes; therefore, our technique can be used either by itself or even in conjunction with previous proposals.. The key statistics that provided an inspiration for this work is that the majority of the instructions in the shadow of the long-latency loads are, in fact, load-independent [Karkhanis and Smith 2002; Sarangi et al. 2005] . These loadindependent instructions release their issue queue entries fairly fast, but then pile up in the reorder buffer, waiting for the cache miss to be serviced. Therefore, the only shared resources within the SMT datapath that remain allocated to these instructions are the physical registers-those are not released until the cache miss is serviced and the process of instruction commitment resumes. We note that neither STALL nor FLUSH is designed to specifically exploit this behavior. While STALL does not release the already allocated resources, FLUSH does so aggressively, but incurs inefficiencies of having to refetch and reexecute all flushed instructions, even those that are independent of the long-latency load.. We propose a mechanism to release physical registers allocated to threads which experience L2 cache misses by speculatively committing the loadindependent instructions and early deallocating the previous mappings of their destination registers. The instructions committed speculatively in this fashion remain in the ROB until the load miss is serviced and the actual commitment occurs. The early released registers can be made available to the instructions within the same thread to support higher memory-level parallelism (MLP) by overlapping multiple cache misses), as well as to the instructions from other threads, thus directly exploiting the thread-level parallelism (TLP) and improving the overall throughput. The specific nature of the register assignments to threads is still dictated by the best-performing underlying resource distribution policies, such as DCRA or Hill-Climbing-our mechanism just provides more registers for the distribution.. The key novel features behind our design include the following:. r The physical registers are reclaimed lazily, only in the shadow of long lastlevel cache misses. (Although the technique can in principle be generalized to deallocate registers under any long-latency event, in this article we only focus on the L2 cache misses). Barring interrupts and exceptions, load-independent instructions executed in the shadow of the missing load are properly committed (and the physical registers are released) after the cache miss is serviced.. Recognizing that exceptions and interrupts are rare, we propose to pseudocommit such load-independent instructions and perform respective register deallocation activities earlier, as soon as the cache miss is detected. r The register reclamation process is only performed along the correctly resolved control flow paths (i.e., we never early deallocate a register if the corresponding instruction may be subject to a branch misprediction). In particular, if an unresolved (unexecuted) conditional branch instruction is encountered in the course of examining the instructions in program order for possible register deallocation, the entire process stops. Such approach allows us to decouple the mechanism for branch misprediction and exception handling and allow for a much higher overhead in restoring the values of the deallocated registers (as the restoration occurs only on exceptions or interrupts). r In order to correctly execute the load-dependent instructions, neither the previous instances of their destinations nor the previous instances of their sources are early released.. To maintain the precise state on interrupts and exceptions, the values of the early released registers can either be saved and restored through periodic register file checkpointing or they can be saved directly within the ROB entries of the instructions that triggered corresponding early deallocations-this mechanism avoids the need for checkpointing and we used it for quantifying our results.. The key characteristics and performance implications of the proposed mechanism are as follows:. r It does not incur tag rebroadcasts, register remappings, associative searches and rename table modifications, does not require per register consumer counters. Instead, it relies on a simple off-the-critical-path logic at the back end of the pipeline to identify the early deallocation opportunities and save the values of the early deallocated registers for precise state reconstruction. r Although it provides some performance benefits even in a single-threaded execution environment (5% IPC gains for 64-entry RFs), the real advantages come in SMT processors with multiple threads due to the more-frequent L2 cache misses and higher pressure on the register file. For a 4-way SMT machine with 256 integer and 256 floating point registers, the proposed mechanism results in 25% improvements in fairness compared to the baseline processor with DCRA resource distribution policy. r It is complementary to all existing late register allocation and early register deallocation schemes and can be used in conjunction with those mechanisms, as it exploits previously unexplored early register deallocation opportunity. However, even by itself, it outperforms some previously proposed early deallocation schemes (e.g., physical register inlining) on SMT, although results in slightly lower gains during single-threaded execution.. r It works synergistically with recently proposed resource allocation policies for SMT, such as DCRA [Burger and Austin 1997] and Hill-Climbing [Cazorla et al. 2003 ]. Although those policies control the distribution of available resources among threads, our technique effectively provides more resources (physical registers) to be used by these policies. As a result, we achieve additional 25% gains on top of DCRA, and 26% gains on top of Hill-Climbing for 256-entry RFs in terms of the fairness metric.. The early register deallocation mechanism described here was first proposed in the conference version of Sharkey and Ponomarev [2007] . In this article, we extend the work of Sharkey and Ponomarev [2007] The rest of the article is organized as follows. Section 2 reviews the related work. Our simulation methodology is presented in Section 3. We motivate the proposed technique and present its details in Section 4. Section 5 presents the results and we conclude in Section 6. Although most of the related work was briefly described in Section 1, this section provides a more-detailed analysis of some prior efforts in the areas of SMT resource distribution, aggressive register management, and checkpointed processor architectures, all of which provided an inspiration for this work.. SMT Resource Distribution. The use of shared as well as partitioned resources in an SMT processor can be indirectly controlled by instruction fetching mechanisms. Several such mechanisms (I-Count [Tullsen et al. 1996 ], FLUSH and STALL [Tullsen, et al. 2001] ) were discussed in Section 1. FLUSH++ [Cazorla et al. 2003 ] combines the benefits of STALL and FLUSH and uses the cache behavior of threads to dynamically switch between these two mechanisms. The data gating technique of El-Moursy and Albonesi [2003] avoids fetching from threads that experience an L1 data miss. In Cazorla et al. [2004] , a resource distribution policy (called DCRA) exercising a more fine grained dynamic control over the shared SMT resources (such as physical registers) was proposed. DCRA first classifies the threads according to their demands for the resources and, based on this classification, determines how the resources should be distributed among the threads. The Hill-Climbing approach [Choi and Yeung 2006] observes the impact of resource distribution decisions on the performance and uses this information to improve future decisions. We apply the proposed mechanism on top of both DCRA and Hill-Climbing and show that serious additional performance gains can be realized in either case. In fact, our mechanism works synergistically with the best-performing resource distribution techniques: it does not take away their advantages, but instead supplies more physical registers to enable more effective register distribution.. Register File Optimizations. Researchers have exploited the inefficiencies in register usage to reduce the number of registers in three major ways. One set of solutions delays the actual allocation of physical registers until the time that the result is written back [Gonzáles et al. 1998; Monreal et al. 2004] . These schemes avoid tying up destination physical registers between the time of instruction dispatch and instruction writeback by allocating a physical register only at the time of writeback and using separate tags to satisfy the data dependencies. The major drawback of the late allocation schemes is in the form of nontrivial increases in the datapath complexity due to the need to: (1) support several levels of register mapping tables, (1) perform various associative searches on the rename table and issue queue after the reassignment of mappings and (3) avoid potential deadlocks. The second set of techniques aim at reducing the register file pressure by using the early deallocation of physical registers [Lipasti et al. 2004; Martinez et al. 2002; Monreal et al. 2002 Monreal et al. , 2004 Ergin et al. 2004] . Although these mechanisms differ in the timing and manner of register deallocation, the additional logic needed to support precise state reconstruction and guarantee correctness of the execution is fairly complex, sometimes requiring additional accesses to the rename table [Lipasti et al. 2004] or register state checkpointing support [Ergin et al. 2004; Martinez et al. 2002] . Furthermore, these schemes need to maintain accurate counters of pending consumers to ensure that deallocation occurs only after all such consumers are issued. The technique of Monreal et al. [2004] deallocates a register after commitment of its last consumer, Ergin et al. [2004] deallocates a register right after commitment of the instruction itself, and Lipasti et al. [2004] and Martinez et al. [2002] attempt to deallocate registers after the result is produced. None of these mechanisms directly exploit the L2 cache misses to optimize register file. Although it is possible to implement some of these techniques on SMT to reduce the number of registers, the complexity of the resulting solution will be at least as high as on a superscalar and in some cases (when modifications to the thread-specific resources are involved) even higher. The solution to register file optimization proposed in this article takes advantage of a previously unexploited opportunity for early register deallocation. Because of this, our technique works synergistically with the previous schemes for register optimization (including those that deallocate registers early) and can be used in conjunction with those mechanisms to provide additional performance advantages, especially in SMT machines. A detailed performance analysis of such synergies is presented in Section 5. Finally, the third set of solutions reduces the number of registers through the use of register sharing [Balakrishan and Sohi 2003 ].. To the best of our knowledge, only one prior effort specifically addressed the issue of RF scalability in a multicontext environment [Oehmkr, et al. 2005] . In that work, a technique to virtualize logical register contexts by automatically saving the values of unused registers to memory and restoring them back on demand was proposed. The scheme of Oehmkr et al. [2005] requires modifications to the rename stage of the pipeline and also results in the insertion of additional load and store instructions into the pipeline to implement fills and spills and has a few other implications on the complexity of the datapath design. The work of Lo et al. [1999] investigated compiler support for efficient register management in SMT.. Checkpointed Processor Architectures. Although the proposed mechanism does not necessarily rely on creating checkpoints, we draw some inspiration from several recent proposals that use register file checkpointing and exploit load-independence to accelerate the execution of single-threaded applications [Kirman et al. 2005; Mutlu et al. 2003; Sarangi et al. 2005] . There are some principal differences between our proposal and those prior works and it is important to highlight them. For example, runahead execution [Mutlu et al. 2003 ] unblocks the ROB when the missing load reaches the ROB head, creates a full register file checkpoint and then allows the following instructions to pseudocommit. After the load is serviced, the execution resumes from the checkpoint. The net effect is that some subsequent cache misses are generated earlier, effectively resulting in cache prefetching and improved performance. The technique of Kirman et al. [2005] introduced load value prediction on top of the runahead execution and augmented the benefits of runahead execution with direct performance advantages on the correct predictions. Unless the value prediction is used and it is correct, all instructions executed in the runahead mode still need to be reexecuted when the cache miss is serviced. In addition, the complexities and overheads of maintaining the register state checkpoints, buffering the results of the speculative store instructions, and possibly supporting value prediction/verification logic are considerable, especially in SMT processors.. In contrast, the registers that are early deallocated by our scheme are always used by the instructions from the same thread as well as from other threads for the actual execution. Instructions are never reexecuted and no resource wastages occur. Most importantly, all pseudocommitted instructions still remain in the ROB (in contrast to the above mentioned schemes); thus, no speculative updates of the memory state by the store instructions ever occur and need to be addressed, avoiding the associated complexities (like the need to maintain and manage the runahead cache as in Mutlu et al. [2003] and Kirman et al. [2005] ). Although our scheme has a somewhat limited utility if applied to a single-threaded superscalar machine as the ROB is likely to quickly fill up and block the forward progress (although we show in the results section that performance gains can be realized even in that case), the presence of explicit TLP within a multithreaded processor allows for the progress of other threads to be sustained and fueled by the early deallocated registers even if the ROB of the thread that experienced the L2 cache miss becomes full. Recent studies by Karkhanis and Smith [2002] and Sarangi et al. [2005] showed that most of the instructions fitting into the instruction window following an L2 miss are load-independent. This result was corroborated by our experiments and we exploit these statistics directly. Other proposals [Akkary et al. 2003; Srinivasan et al. 2004 ] completely eliminate the ROB and instead use periodic checkpoints, effectively allowing out-of-order commit and more aggressive use of registers. In contrast, our technique builds on top of traditional ROB-based architectures, keeping the datapath changes to the minimum. In addition, efficiently implementing checkpointing on SMT processors requires additional considerations, as per-thread checkpointing is needed to avoid the simultaneous rollback of all threads if a global register and memory state checkpoint is used.

O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Mask-Based

Second-Generation

Connectivity

and

Attribute

Filters

Abstract-Connected

filters

are

edge-preserving

morphological

operators,

which

rely

on

a

notion

of

connectivity.

This

is

usually

the

standard

and

which

is

often

too

rigid

since

it

cannot

model

generalized

groupings

such

as

object

clusters

or

partitions.

In

the

set-theoretical

framework

of

connectivity,

these

groupings

are

modeled

by

the

more

general

second-generation

connectivity.

In

this

paper,

we

present

both

an

extension

of

this

theory,

and

provide

an

efficient

algorithm

based

on

the

Max-Tree

to

compute

attribute

filters

based

on

these

connectivities.

We

first

look

into

the

drawbacks

of

the

existing

framework

that

separates

clustering

and

partitioning

and

is

directly

dependent

on

the

properties

of

a

preselected

operator.

We

then

propose

a

new

type

of

second-generation

connectivity

termed

mask-based

connectivity

which

eliminates

all

previous

dependencies

and

extends

the

ways

the

image

domain

can

be

connected.

A

previously

developed

Dual-Input

Max-Tree

algorithm

for

area

openings

is

adapted

for

the

wider

class

of

attribute

filters

on

images

characterized

by

second-generation

connectivity.

CPU-times

for

the

new

algorithm

are

comparable

to

the

original

algorithm,

typically

deviating

less

than

percent

either

way.

I

N

discrete

image

analysis

the

set-theoretic

concept

of

connectivity

describes

the

way

pixels

are

grouped

to

form

connected

components

or

flat-zones

in

gray

scale

Connected

components

are

image

regions

of

constant

intensity

in

which

pixels

are

characterized

by

a

path-wise

connectedness

relation.

Typically,

on

the

two-dimensional

discrete

space

Z

Z

sets

of

pixels

are

either

or

Based

on

the

notion

of

connectivity,

a

family

of

morphological

operators

known

as

connected

filters

has

been

developed

which

interact

with

the

connected

components

rather

than

individual

pixels.

This

prevents

edge

distortion,

a

property

highly

desirable

in

many

applications.

Connected

components

can

either

be

removed

or

remain

intact

but

new

ones

cannot

emerge.

Early

members

of

this

family

were

openings

by

reconstruction,

for

which

efficient

algorithms

have

been

developed

Furthermore,

the

concept

of

attribute

filters

was

introduced,

which

allows

filtering

based

on

the

connected

component

attributes.

Examples

of

this

are

attribute

openings,

closings,

thinnings,

and

thickenings

In

recent

years,

several

theoretical

developments

concerning

generalizations

of

the

notion

of

connectivity

have

been

presented

aiming

to

improve

the

robustness

and

increase

the

versatility

of

these

filters.

These

generalizations

aim

at

modeling

object

clusters

and

partitions

in

an

edge

preserving

manner.

A

well-established

approach

known

as

second-generation

connectivity

handles

both

cases

independently

by

creating

a

"child"

connectivity

class,

by

using

some

operator.

Second-generation

connectivity

can

be

classified

as

either

clustering

or

contraction-based

depending

on

whether

the

operator

expands,

or

contracts

the

original

image.

An

example

of

filtering

based

on

clustering

connectivity

is

given

in

Fig.

illustrating

an

Anabaena

complex.

Assuming

we

target

the

largest

complex,

using

standard

and

we

can

only

retrieve

the

bigger

fragment

of

the

two,

which

are

separated

by

the

heterocyst-

Fig.

Instead,

if

the

connected

filter

is

defined

on

the

more

general

clustering-based

connectivity,

the

two

fragments

merge

as

illustrated

in

Fig.

and

the

filter

considers

them

as

one

object-

Fig.

The

original

image

has

been

obtained

from

Second-generation

connectivity

is

realized

by

means

of

a

connectivity

opening

which

is

associated

with

a

structural

operator.

The

dependency

on

this

operator

imposes

constraints

as

to

how

the

image

domain

can

be

connected,

and

apart

from

clustering

and

partitioning,

no

further

cases

such

as

combinations

of

the

two

are

supported.

In

our

work,

we

counter

this

limitation

by

introducing

a

composite

connectivity

opening

in

which

all

dependencies

to

the

structural

operator

are

eliminated.

Instead,

we

propose

an

association

with

a

connectivity

mask

which

is

an

image

containing

some

arbitrary

transformation

of

the

original.

This

yields

a

single

framework

termed

mask-based

connectivity

that

accounts

for

all

possible

ways

the

image

domain

can

be

connected.

This

includes

the

two

known

cases

of

clustering

and

partitioning

through

the

design

of

filters

which

yield

results

identical

to

the

previous

approach,

even

though

formally

based

on

different

connectivity

classes.

The

difference

between

these

classes

lies

in

the

fact

that,

for

a

given

operator,

we

generate

a

different

connectivity

class

for

each

target

image,

rather

than

one,

generally

applicable

connectivity

class..

Algorithmic

realizations

of

second-generation

connectivity

originally

suggested

the

use

of

binary

and

gray-scale

reconstruction

operators

for

recovering

the

object

clusters

or

partitions

This

introduced

a

family

of

filters

based

on

width

as

the

attribute

criterion.

An

efficient

algorithm

for

gray-scale

area

filters

using

second-generation

connectivity

has

also

been

presented

This

method

builds

a

hierarchical

image

representation

based

on

gray-scale

image

pairs

comprising

the

original

image

and

its

modified

replica.

In

regions

where

the

two

images

differ

the

algorithm

evaluates

the

connectivity

based

on

the

properties

of

the

structural

operator

and

assigns

pixels

to

the

appropriate

connected

components.

The

algorithm

which

is

inspired

by

Salembier

et

al.

is

referred

to

as

the

Dual-Input

Max-Tree

algorithm

and

supports

both

clustering

and

partitioning.

In

this

work,

we

employ

the

Dual-Input

Max-Tree

modified

for

the

more

general

family

of

gray-scale

attribute

filters

on

and

data

sets

characterized

by

mask-based

second-generation

connectivity.

We

demonstrate

its

capacity

on

biomedical

images

and

data

sets

using

nonincreasing

shape

filters

based

on

moment

invariants

and

provide

the

functionality

to

extend

to

other

filter

types..

The

structure

of

this

paper

is

organized

as

follows:

In

Section

a

number

of

preliminaries

is

presented.

These

are

the

fundamental

concepts

of

connectivity

classes

and

connectivity

openings,

the

notion

of

second-generation

connectivity,

and

attribute

filters.

In

Section

we

investigate

the

drawbacks

of

the

existing

second-generation

connectivity

framework.

Section

introduces

the

mask-based

connectivity

scheme

and

formalizes

an

expression

of

attribute

openings

associated

to

it.

Following

this,

Section

gives

a

short

introduction

on

the

Max-Tree

structure

complemented

by

the

description

of

the

Dual-Input

Max-Tree

algorithm

adopted

for

mask-based

connectivity

representation.

Section

gives

a

number

of

examples

on

attribute

filtering

and

a

brief

discussion

on

the

results

while

conclusions

are

summarized

in

Section

O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O B I O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A calculus for uniform feature composition The goal of feature-oriented programming (FOP) is to modularize software systems in terms of features. A feature refines the content of a base program. Both base programs and features may contain various kinds of software artifacts, for example, source code in different languages, models, build scripts, and documentation. We and others have noticed that when composing features, different kinds of software artifacts can be refined in a uniform way, regardless of what they represent. We present gDEEP, a core calculus for feature composition, which captures the language independence of FOP; it can be used to compose features containing many different kinds of artifact in a type-safe way. The calculus allows us to gain insight into the principles of FOP and to define general algorithms for feature composition and validation. We provide the formal syntax, operational semantics, and type system of gDEEP and outline how languages like Java, Haskell, Bali, and XML can be plugged in. The goal of feature-oriented programming (FOP) is to modularize software systems in terms of features [Prehofer 1997] . A feature is a unit of functionality of a software system that satisfies a requirement, represents a design decision, and provides a potential configuration option . AHEAD (Algebraic Hierarchical Equations for Application Design) is an architectural model for large-scale FOP [Batory et al. 2004] .. The idea behind AHEAD is to unify approaches of FOP and scale them to programming in the large. First, AHEAD generalizes the operations that are performed when a feature is composed with a base program. A base program is modeled as a collection of named program elements, which are organized in a hierarchical namespace. A feature encapsulates a program refinement, which is a set of changes to a base program. Such changes include the introduction of new program elements and the modification of existing program elements. The hierarchical namespace allows a refinement to target any element at any depth of the hierarchy.. Second, AHEAD scales program refinement to arbitrary kinds of software artifacts. A feature typically includes changes not only to the source code, but also to other supporting documents, for example, HTML documentation, ANT scripts, and UML diagrams. The principle of uniformity that underlies AHEAD can be stated as follows: features are implemented by a diverse selection of software artifacts, and any kind of software artifact can be the subject of subsequent refinement [Batory et al. 2004] .. Whereas the idea of uniform feature composition captures the philosophy behind the AHEAD model and guides us when reasoning about feature-based program synthesis [Batory 2007] , it is rather abstract. Although our previous work on FOP [Hutchins 2006 [Hutchins , 2009 Apel et al. 2005 Apel et al. , 2008b Apel et al. , 2009c Apel et al. , 2009a Apel et al. , 2009b Apel and Lengaver 2008] had established that program refinement is similar for all artifact types, we had no way to express and reason about this similarity. We wanted a formal model of feature composition that was independent of the particular kind of software artifact that was being refined. Such a model answers several important questions: What is the essence of featurebased program refinement? What properties are mandatory for software artifacts to be refined? What is common to all artifact languages and what are the differences? A theory of features and feature composition will help us answer these questions.. We propose gDEEP, a core calculus for uniform feature composition, as the backbone of such a theory. gDEEP has several benefits.. (1) It enables us to reason about the properties and procedures of program refinement and feature composition in a formal way. (2) Software artifacts of different types can be plugged into the calculus and treated equally by the algorithms for feature composition and validation. The algorithms can be expressed in a uniform and language-independent way.. (3) gDEEP's type system factors out the portion of typing that is concerned with feature composition. Rather than designing separate and incompatible type systems to handle features in each artifact language, we can use a single type system. The type system for features integrates with the type system of each artifact language in a uniform way. (4) Tools can operate directly on a concrete representation of gDEEP. This way, tools for composition, validation, and analysis of features can be reused for various types of artifacts.. gDEEP builds on the seminal work on mixin composition [Bracha and Cook 1990; Findler and Flatt 1998; Flatt et al. 1998; Bono et al. 1999; Smaragdakis and Batory 2002; Ancona et al. 2003 ] and generalizes and scales previous work on a formal foundation for FOP [Hutchins 2006] . It is an alternative to approaches that rely on algebra [Lopez-Herrejon et al. 2006; Apel et al. 2008c Apel et al. , 2010b and complements work on tools and case studies [Apel and Lengauer 2008; Apel et al. 2009c] , which is discussed in Section 8. We present the syntax, operational semantics, and type system of gDEEP and explain how different artifact languages such as Java, Haskell, Bali, and XML can be plugged into it. We focus here on the key design decisions and the generality of gDEEP and not on the underlying type theory. Although this article is self-contained, in some paragraphs, we refer to an accompanying technical report that provides more details [Apel and Hutchins 2007] . We have developed gDEEP as a core calculus for feature-oriented programming (FOP) that encapsulates the essence of feature composition and validation. It abstracts from artifact-specific details and treats many different kinds of software artifact in a uniform way. gDEEP provides three basic concepts for constructing features which are largely orthogonal: (1) a module allows a mutually recursive set of named definitions; (2) refinement statements allow a module to be extended; (3) monotone functions allow separate extensions to be composed.. We have presented the formal syntax, operational semantics, and type system of gDEEP and illustrated what a language needs to provide when it is plugged into gDEEP. We have demonstrated that a wide variety of very different artifact languages can be used with gDEEP in order to enhance them with feature composition capabilities. In an accompanying technical report, we explain how we adapted and developed formalizations of Java, Bali, and XML and plugged them into gDEEP [Apel and Hutchins 2007] .. Our calculus serves also as an intermediate language for feature representation and manipulation, which is a foundation for large-scale featureoriented program synthesis [Batory 2007 ]. Our tool FEATUREHOUSE implements feature composition following the principles of gDEEP. At the time of writing, FEATUREHOUSE is able to compose feature written in Java, C, C#, Haskell, Bali, JavaCC, XML, and Alloy. Several case studies demonstrate the practicality and scalability of our approach [Apel and Lengauer 2008; Apel et al. 2009c Apel et al. , 2009a Apel et al. , 2009b .. Beside composition, further algorithms and tools can be developed on top of the calculus to provide a seamless infrastructure for developing, analyzing, composing, and validating features in different representations. gDEEP is inspired by DEEP [Hutchins 2006 ], which is a formal object calculus that implements virtual classes [Madsen and Moller-Pedersen 1989] in a typesafe manner. Several other calculi have been developed for virtual classes, for example, by Ernst et al. [2006] , Clarke et al. [2007] , and Odersky et al. [2003] , which could have been alternative starting points for our work.. Modules in gDEEP are similar in some respects to formal models of objects, for example, by Abadi and Cardelli [1996] and Boudol [2004] . Boudol in particular shows how extensible objects, classes, and even mixins can be implemented by using generating functions-functions that take "self " as their first argument. Modules in gDEEP are essentially generating functions, which are applied using delegation: M@(N).L. The gDEEP type system, however, is completely different from that used by Boudol, because gDEEP relies exclusively on subtyping, whereas Boudol uses record types with row-variables.. A significant body of work has explored the concept of mixin composition, for example, Bracha and Cook [1990] , Findler and Flatt [1998] , Flatt et al. [1998] , Bono et al. [1999] , Ancona et al. [2003] , and Kamina and Tamai [2004] . gDEEP builds on this work and implements deep mixin composition [Zenger and Odersky 2005 ] in a language-independent manner. McDirmid et al. [2006] have presented a formal system for modular linking in the presence of mixins. They aim similarly at language independence but with focus on object orientation.. It is an interesting issue how to generalize their formal system to noncode languages.. A concept related to mixins is the concept of a trait. A trait is a reusable unit of behavior that, in its original proposal, has no state [Ducasse et al. 2006] . Experiences from practical FOP show that features often have state, or to phrase it differently, add fields to existing classes. Although there is a recent proposal for stateful traits [Bergel et al. 2008] , we favored the mixin concept because of it is widely used in FOP tools. Another difference between traits and mixins lies in the treatment of name clashes. Traits explicitly require the composer to handle conflicts. Anyway, this paper does not focus on these issues but on the principle of uniformity, which is also applicable to the work on traits.. Multimethods have been proposed to problems of single method dispatch [Millstein and Chambers 2002] , for example, the binary method problem. Multiple method dispatch allows a programmer to extend a given object subsequently without changing existing code or introducing type errors, which is also possible with gDEEP. Additionally, gDEEP structures the name space hierarchically in order to encapsulate and scale the extensions a feature can apply, which has been shown useful in FOP [Smaragdakis and Batory 2002; Batory et al. 2004] .. Several approaches aim at ensuring the correctness of feature composition. Apel et al. [2008a] extend Featherweight Java with constructs for feature composition, in particular, with constructs for the refinement of classes, constructors, and methods. It is not obvious how to generalize these results to arbitrary languages. Thaker et al. [2007] , Delaware et al. [2009] , Kästner and Apel [2008] , and Apel et al. [2010a] use a combination of a SAT solver and an ordinary type system to check whether all program variants that can be composed from a set of features are type safe. Again, all of these approaches focus on Java only. Li et al. [2002 Li et al. [ , 2005 proposed a technique to verify feature-oriented systems in two steps: (1) features are verified modularly and (2) their composition is verified without the need of re-verifying the involved features again. Their approach relies on three-valued model checking to take the "openness" of feature into account. The state machine models they use are quite spartan and do not consider noncode artifacts explicitly.. Features and feature composition can also be expressed in terms of algebra [Lopez Herrejon et al. 2006; Apel et al. 2008c Apel et al. , 2010b . The advantage of an algebra-based approach is that reasoning about feature composition is simpler than in gDEEP. The disadvantage is that algebraic approaches operate at a higher level of abstraction. Algebraic approaches do not provide an operational semantics and type system, so it is harder to prove certain properties, and they cannot be easily used as a basis for implementations. We believe that both abstraction levels are equally important and useful for exploring the principles of feature composition.. We have developed a tool, called FEATUREHOUSE, that composes features written in Java, C#, C, Haskell, Bali, JavaCC, XML, Alloy following the rules of gDEEP, but a discussion of the rationales and details of the implementation of FEATUREHOUSE is outside the scope of this article and reported elsewhere [Apel and Lengauer 2008; Apel et al. 2009c Apel et al. , 2009a Apel et al. , 2009b . We have used FEATUREHOUSE in seven case studies of different sizes (2-99 features with about 300-90,000 lines of code) involving different types of artifacts (Java, C#, C, Haskell, JavaCC, XML). The case studies demonstrate the practicality of language-independent feature composition and reveals some insights in the mandatory and optional properties of language to be represented in gDEEP. Details about the case studies are out of scope of this paper and are available on the Web. There are alternative composition models that relate to feature composition as modeled by gDEEP. Aspect-oriented programming (AOP) aims at improving modularity of crosscutting concerns [Kiczales et al. 1997] . It has been observed that features are frequently crosscutting in nature [Mezini and Ostermann 2004; Apel et al. 2008b] , and so it is not surprising that the techniques used in FOP are also associated with AOP [McDirmid and Hsieh 2003; Mezini and Ostermann 2004] . In this sense, gDEEP models a subset of AOP [Apel et al. 2008b] . Multidimensional separation of concerns (MDSC) [Tarr et al. 1999 ] is very related to FOP [Apel et al. 2008b] . It favors the hierarchical nesting and composition of software artifacts much like FOP but allows programmers to define explicit composition rules for merging to pieces of software. Hence, gDEEP is possibly a proper means for modeling MDSC and exploring the relationship between AHEAD and MDSC.

O O O O B I O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O B I O O O O O O O O O O O O O O B I O O O O O O B O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


On the use of second-order derivatives and metamodel-based Monte-Carlo for uncertainty estimation in aerodynamics This article adresses the delicate issue of estimating physical uncertainties in aerodynamics. Usually, flow simulations are performed in a fully deterministic approach, although in real life operational uncertainty arises due to unpredictable factors that alter the flow conditions. In this article, we present and compare two methods to account for uncertainty in aerodynamic simu- Thanks to the high sophistication reached by Computational Fluid Dynamics (CFD) codes combined with the growth of computational facilities, research in the field of aerodynamic analysis and design has experienced a large development in the last years, allowing to deal with more and more complex problems. However, high fidelity models are usually used in deterministic approaches, which assume a perfect knowledge of the environmental and operational parameters. In real life, uncertainty can arise in many aspects of the entire design-production-operation process: from the assumptions done in the mathematical model describing the underlying physical phenomena, to the manufacturing tolerances, and to the operational parameters and conditions that could be affected by unpredictable factors (see [14] for a systematic treatment).. In particular, in aerodynamics there could be some operational uncertainties due to unpredictable factors that alter the flow conditions:. • the angle of attack may vary during the flight due to atmospheric conditions;. • instrumentation errors, or changes in flight profile compared to the scenario, or atmospheric conditions could result in uncertainty on Mach and Reynolds numbers.. It should be noted that geometric uncertainty, in addition to manifacturing tolerances, can arise during the working cycle also:. • temporary geometric variations, due to factors as icing or deformation under the weightloads;. • transient or permanent geometric variations due to the motion regime (e.g. blades in compressors);. • permanent geometric variations due to degradation (erosion, etc).. These uncertainties modify the aerodynamic coefficients and in some cases significantly degrade the performance of a system that has been optimized for some precise operational conditions. Therefore it would be beneficial to identify the most important uncertainties, quantify them and compute their impact on the performance. Then, statistical information, such as expectation and variance of an objective function, can be used in the design phase:. this kind of approach is commonly known as robust design (see for instance [1] for a survey).. The practical difficulty with uncertainty quantification is related to the fact that the expected value µ j and the variance σ 2 j of the considered objective functional j result from an integration in the multi-dimensional space of the uncertain variables α ∈ R n , i.e.. where f (α) is the Probability Density Function (PDF) for the uncertain variables.. Since the nonlinear equations governing the flow model are computationally expensive to solve (and thus the evaluation of the objective function j), the use of a brute-force numerical integration method or Monte-Carlo analysis would become prohibitively expensive. Therefore, we need to introduce some new techniques that allow to obtain an approximate expectation value and variance of the functional. These techniques can be grouped in three main categories:. • Monte-Carlo estimates using surrogates ;. • Method of Moments (or Taylor series approximations);. • Polynomial Chaos Expansion.. The first approach consists in replacing the expensive simulation procedure by a cheap approximation to carry out the Monte-Carlo analysis.. Usually, surrogate models are employed, such as response surface techniques or meta-models [7] . For the second approach, the objective functional is replaced by its Taylor series expansion from nominal conditions, yielding an analytical integration of statistical quantities [26, 16] . The latter approach is essentially different since it relies on a stochastic simulation framework. For. Polynomial Chaos decomposition methods, the dimension of the problem is increased to account for uncertainty. More precisely, flow variables are expansed using a set of orthogonal basis functions, whose coefficients are used to characterize and quantify the uncertainty. By applying a Galerkin procedure, governing equations for each individual mode are derived. This approach has been applied for uncertainty quantification in several engineering fields. It is well suited to problems governed by PDEs and yields an accurate estimate of uncertainty. In particular, applications to fluid dynamics can be found in [27, 9] (incompressible Navier-Stokes eq.) or [10] (compressible Euler eq.).. Nevertheless, this approach requires the development of a new simulation code accounting for the new dimensions. A non-intrusive formulation can be used, yielding however a much more expensive procedure.. Therefore, this work includes the comparison of the two former approaches:. Monte-Carlo integration using metamodels and Method of Moments, for the evaluation of first and second-order statistical moments (i.e. mean and variance) for the drag coefficient of a transonic wing in a steady 3D Eulerian flow, where the Mach number and the angle of attack are subject to uncertainty. In this study, we have presented and compared two methods to estimate aerodynamic uncertainty for practical testcases: automatic differentiation • the tangent mode allows to compute, from an arbitrary directionu ∈ R n , the derivative in the directionu:. • the reverse mode allows to compute, from an arbitrary directionφ ∈ R m , the following product:. Note that if φ(u) ∈ R (i.e. a functional), reverse mode differentiation gives the gradient of φ w.r.t. u (multiplied by the input scalarφ).. These two modes can be employed to easily compute the terms that are required for derivatives estimation.. Consider that the evaluation of functional j = J(α, W ) is implemented by a Fortran subroutine func, whose input variables are alpha and w and output variable is j:. If we perform a reverse mode differentiation with respect to the input variables alpha and w, we obtain a new subroutine:. where jb is a new input variable and alphab and wb are new output variables defined as:ᾱ. If we evaluate the above subroutine with the inputJ = 1, the quantities in (23) are the first term in the right hand side (r.h.s.) of (11) and the r.h.s. of the adjoint equation (10) .. To compute the terms required to estimate the second-order derivatives, we need to perform two successive tangent-mode differentiations. For example, considering the tangent-mode differentiation of the subroutine func with respect to alpha and w we obtain:. where alphad and wd are new input variables and jd a new output variable.. These input variables are provided by the user, whereas the output variable is the directional derivative:J. Then, the differentiation of the output variable jd in the subroutine func d. with respect to input variables alpha and w gives:. where jdd is the new output variable, that represents:J. where we have used the commutativity of the order of differentiation.. If one calls this subroutine with the following input parameters:. one obtains as output variable˙J = D 2 i,k J as defined in (13) .

O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O B O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A prolog-based framework for search, integration and empirical analysis on software evolution data Software projects use different repositories for storing project and evolution information such as source code, bugs and patches. An integrated system that combines these multiple repositories and can answer a broad range of queries regarding the project's evolution history would be beneficial to both software developers and researchers. For example, the list of source code changes or the list of developers associated with a bug fix are frequent queries for both developers and researchers. Integrating and gathering this information is a tedious, cumbersome, error-prone process when done manually, especially for large projects. Previous approaches to this problem use frameworks that limit the user to a set of pre-defined query templates, or use query languages with limited power. In this paper, we argue the need for a framework built with recursively enumerable languages, that can answer temporal queries, and supports negation and recursion. As a first step toward such a framework, we present a Prolog-based system that we built, along with an evaluation of real-world integrated data from the Firefox project. Our system allows for elegant and concise, yet powerful queries, and can be used by developers and researchers for frequent development and empirical analysis tasks. Software projects are larger than ever and their histories run for longer than ever, so developers are overwhelmed whenever they are faced with tasks such as program understanding or searching through the evolution data for a project. Examples of such frequent development tasks include understanding the control flow, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. finding dependencies among functions, finding modules that will be affected when a module is changed, etc. Similarly, during software maintenance, frequent tasks include keeping track of files that are being changed due to a bug-fix, finding which developer is suitable for fixing a bug (e.g., given that she has fixed similar bugs in the past or she has worked on the modules that the bug occurs in). In addition, a framework that allows querying on integrated evolution data for large projects would be beneficial for research in empirical software engineering, where data from these repositories is frequently used for hypothesis testing. All these tasks require expressive and efficient search over large data sets across repositories; therefore a framework that can integrate these data from multiple sources and answer a broad range of queries would be beneficial for both software development and empirical analysis.. While prior frameworks allow efficient search and analysis on software evolution data, they have two main inconveniences: (1) they are not flexible enough, e.g., they permit a limited range of queries, or have fixed search templates; (2) they are not powerful enough, e.g., they do not allow recursive queries, or do not support negation; however, these features are essential for a wide range of search and analysis tasks. In this paper, we show how we can address these shortcomings by using a Prolog-based integration and query framework. We chose Prolog because it is declarative yet powerful, which allows elegant, concise expression of queries for data collection and hypothesis testing. Our framework captures a wealth of historical software evolution data (information on bugs, developers, source code), and allows concise yet broad-range queries on this data. The three main novelties of our framework are: (1) it is temporally aware; all the tuples in our database have time information that allows comparison of evolution data (e.g., how has the cyclomatic complexity of a file changed over time?); (2) it supports powerful language features such as negation, recursion, and quantification; (3) it supports efficient integration of data from multiple repositories in the presence of incomplete or missing data using several heuristics. We are currently using DES, an open-source Prolog-based implementation of deductive databases [10] as our framework's engine. In the future, we plan to use the bdddbddb framework to speed up queries [12] , as bdddbddb has been shown to be able to handle Datalog-based static analyses for large, real-world programs. We plan to use other software traits/trails, e.g., mailing list information, to improve our data set for more accurate information modeling and retrieval. In our preliminary experiments as shown in Section 5, we did not use the sourcebasic database or any queries related to it. In future, we would like to extend our library to answer queries related to the sourcebasic like: "which file exhibited the maximum increase in complexity or defect density during a given time interval." Additionally, we plan to track bug-introducing changes using our framework-changes in the source code that led to bugs. Finally, we plan include code-ownership information to indicate which developer owns which artifact of a software system in our database using heuristics similar to Girba et al. [4] . Finally, we plan to add a visualization layer [5] on top of our current frame- We randomly selected 2128 C files and 58 C++ files from the Firefox source code repository and extracted their complete change log histories to populate our source change database. We extracted the 932 bugs associated with these source files. We also added to our source dependency table the 50 function call edges induced by the static call graph between functions in these files. In total, our database contained 63,142 tuples. In Table 3 we present the queries we used to test the query definitions showed in Table 2 . The first column shows the query invocation, the second column shows the number of resulting tuples, 4 and the third column shows the query execution time, in milliseconds. We found that the time taken to answer a query using DES increases with the increase in number of resulting tuples, hence it can be quite high for queries with large results, e.g., Q10; we plan to address scalability in future work. Herraiz et al. [7] identified the need for organized software repositories that can improve data retrieval techniques in software engineering and ensure repeatability, traceability and third-party independent verification and validation. They proposed a research agenda by identifying the research challenges in this area.. Hindle and German [8] proposed SCQL, a first-order and temporal logic-based query language for source code repositories. Their data model is a directed graph that captures relationships between source code revisions, files and modification requests. SCQL supports universal and existential queries, as we do, but does not support negation and recursion, which we do. While we do not proPermission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. pose a new language, the significant difference is that we consider multiple software repositories to integrate data and answer queries. Instead of source code changes only, our framework captures relationships between three artifacts: developers, bugs and source code. Fischer et al. [2] proposed an approach for populating a release history database that combines source code information with bug tracking data and is therefore capable of pinpointing missing data not covered by version control systems such as merge points. Similar to Fischer et al., we build our database initially by extracting information from source code and bug repositories.. German [3] proposed recovering software evolution history using software trails-information left behind by the contributors such as mailing lists, version control logs, software releases, documentation, and the source code. The method was used to recover software evolution traits for the Ximian project. Our data collection and database population is similar, though our framework is meant to answer queries aggregating data from multiple repositories.. Begel et al. [1] developed Codebook, a framework capable of combining multiple software repositories within one platform. Our work is similar but the main challenge in building a framework for open source projects lies in collecting and accurately integrating related data in absence of organized repositories and missing data [2] . Their query language is restricted to regular expressions, but has support for a fixed set of pre-computed transitive closure results; we use Prolog, a Turing-complete language, hence our framework can express unrestricted queries (including temporal ones).. Nussbaum et al. [9] presented the Ultimate Debian Database that integrates information about the Debian project from various sources to answer user queries related to bugs and source code using a SQL-based framework. However, their framework does not have support for queries that require negation or transitive closure.. Starke et al. [11] conducted an empirical study on programmers' search activities to identify the shortcomings of existing search tools. They found that SQL-based state-of-the-art source code search tools are not effective enough for expressing the information developer is seeking. We believe that declarative query support will improve developers' code-search experience.. Hajiyev et al. [6] proposed CodeQuest, a Datalog-based code search tool for Java programs. They used four open source Java applications: Jakarta Regexp, JFreeChart, Polyglot and Eclipse to demonstrate their tool. Our work significantly differs from this work in two ways: (1) we do not build any language specific tool, thus forming a broader framework, and (2) we integrate multiple repositories, which allows the user to search information about bugs and developers in addition to source code.

O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Enriched MU-Calculi Module Checking Abstract. The model checking problem for open systems has been widely studied in the literature, for both finite-state (module checking) and infinite-state (pushdown module checking) systems, with respect to CTL and CTL * . In this paper, we further investigate this problem with respect to the µ-calculus enriched with nominals and graded modalities (hybrid graded µ-calculus), in both the finite-state and infinite-state settings. Using an automata-theoretic approach, we show that hybrid graded µ-calculus module checking is solvable in exponential time, while hybrid graded µ-calculus pushdown module checking is solvable in double-exponential time. These results are also tight since they match the known lower bounds for CTL. We also investigate the module checking problem with respect to the hybrid graded µ-calculus enriched with inverse programs (Fully enriched µ-calculus): by showing a reduction from the tiling problem, we show its undecidability. We conclude with a short overview of the model checking problem for the Fully enriched µ-calculus and the fragments obtained by dropping at least one of the additional constructs. Model-checking is a formal method, applied in system design, to automatically verify the ongoing behavior of reactive systems ( [CE81, QS81] ). In this verification technique the behavior of a system, formally described by a mathematical model, is checked against a behavioral constraint, usually specified by a formula in an appropriate temporal logic (for a survey, see [CGP99] ).. In the process of modeling a system, we distinguish between closed and open systems [HP85] . While the behavior of a closed system is completely determined by the state of the system, the behavior of an open system depends on the ongoing interaction with its environment [Hoa85] . In model checking open systems, introduced and called modulechecking in [KVW01] , one should check the system with respect to arbitrary environments and should take into account uncertainty regarding the environment. In such a framework, the open finite-state system is described by a labeled state-transition graph, called in fact environment by checking whether the L(A M ) ∩ L(A |=ϕ ) is empty. The results follow from the fact that an NBT is a particular case of GAPT , which are closed under intersection and have the emptiness problem solvable in Exptime [BLMV06] . We also show a lower bound matching the obtained upper bound by using a reduction from the module checking for CTL, known to be Exptime-hard.. By exploiting again an automata-theoretic approach, we show that hybrid graded µ-calculus pushdown module checking is decidable and solvable in 2Exptime in the size of the formula and Exptime in the size of the system. Thus, as in general, with respect to the finite-state model checking case we pay an exponential-time blowup in the size of both the system and the formula for the use of pushdown systems, and an another exponential-time blowup in the size of the formula for the module checking investigation. Our approach allow us do not take the trivial 2Exptime result on both the size of the system and the formula, which can be easily obtained by combining the algorithms existing in the literature along with that one we introduce in this paper for the finite-state case. We solve the hybrid graded µ-calculus pushdown module checking by using a reduction to the emptiness problem for nondeterministic pushdown parity tree automata (PD-NPT ). The algorithm we propose extends that given for the finite-state case. In particular, given an OPD S, a module M induced by the configurations of S, and an hybrid graded µ-calculus formula ϕ, we first construct in polynomial time a pushdown Büchi tree automaton (PD-NBT ) A M , accepting exec(M). From the formula side, accordingly to [BLMV06] , we can construct in a polynomial time a GAPT A |=ϕ accepting all models that do not satisfy ϕ. Thus, we can check that M models ϕ for every possible choice of the environment by checking whether L(A M ) ∩ L(A |=ϕ ) is empty. By showing a non-trivial exponential reduction of 2GAPT into NPT , we show a 2Exptime upper bound for the addressed problem. Since the pushdown module checking problem for CTL is 2Exptime-hard, we get that the addressed problem is then 2Exptime-complete.. As regarding the Fully enriched µ-calculus, we also investigate the module checking problem in a "rewind" framework in the following sense. As far as backward modalities concern, everytime the system goes back to an environment's node, he is always able to redefine a new pruning choice. Given a module M and a Fully enriched µ-calculus formula ϕ, we solve the rewind module checking problem by checking that all trees in exec(M), always taking the same choice in duplicate environment nodes, satisfy ϕ. By showing a reduction from the tiling problem [Ber66] , we show that the addressed problem is undecidable.. We conclude the paper with short considerations on the model checking on all of the fragments of the Fully enriched µ-calculus. In particular we show the problem to be Exptime-complete for a pushdown system which is allowed to push one symbol per time onto the stack, with respect to any fragment not including the graded modality: for the fragments with the graded modality, we show a 2Exptime upper bound.. The rest of the paper is organized as follows. In Section 2, we give all the necessary preliminaries, Section 3 contains the definition of module checking w.r.t. hybrid graded µ-calculus, and Section 4 contains definitions and known results about 2GAPT and PD-NPT . In Sections 5 and 6, we give our main results on module checking for the hybrid graded µ-calculus. In Section 7, we show the undecidability result for the Fully enriched module checking and conclude in Section 8 with some complexity considerations on model checking with all the fragments of the Fully enriched µ-calculus.

O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O


Universal bufferless packet switching A packet-switching algorithm specifies the actions of the nodes in order to deliver packets in the network. A packet-switching algorithm is universal if it applies to any network topology and for any batch communication problem on the network. A long standing open problem has concerned the existence of a universal packet-switching algorithm with near optimal performance guarantees for the class of bufferless networks where the buffer size for packets in transit is zero. We give a positive answer to this question. In particular, we give a universal bufferless algorithm which is within a poly-logarithmic factor from optimal for arbitrary batch problems:where T is the packet delivery time of our algorithm, T * is the optimal delivery time, n is the size of the network, and N is the number of packets. At the heart of our result is a new deterministic technique for constructing a universal bufferless algorithm by emulating a store-and-forward algorithm on a transformation of the network. The main idea is to replace packet buffering in the transformed network with packet circulation in regions of the original network. The cost of the emulation on the packet delivery time is proportional to the buffer sizes used by the store-and-forward algorithm. We obtain the advertised result by using a store-andforward algorithm with logarithmic sized buffers. The resulting bufferless algorithm is constructive and it can be implemented in a distributed way. the packets from the incoming and injection buffers and either forwards them along incident links or places them in the outgoing buffers. If the outgoing buffer is full, then packets are dropped.. In bufferless networks, there are no outgoing edge-buffers; in other words, all outgoing edge-buffers have size zero. Further, packets may not be dropped. Thus, after the packet is injected into the network, it must traverse some edge at every time step (until it is absorbed). Preferably, the traversed edge brings the packet closer to the destination. However, due to collisions, this is not always possible and the packet may be sent on an alternate edge taking it further from the destination; this event is called deflection.. In our model, bufferless networks still have the injection and incoming buffers. The incoming buffers help to process the incoming packets. The injection buffer is needed when a node has to inject packets and there are no available edges. So, the distinction between store-and-forward and bufferless networks is in the outgoing buffers which hold packets in transit. Our main goal has been to establish the existence of universal, near optimal (to within poly-log factors) bufferless communication algorithms. Our proof of this fact has been constructive, using a bufferless emulation technique to emulate a store-and-forward algorithm on a batch scheduling problem related to the original batch packet problem. The heart of the emulation is to replace buffering with packet circulation. The algorithm we have given is distributed modulo the need for nodes to know C and N . Note that in Theorem 5.1, it is crucial to allow the paths to deviate from the pre-selected paths, otherwise it is possible to construct problems for which the optimal bufferless routing time is at least a √ N factor from optimal [22] . We continue by discussing an alternative partitioning algorithm, and then we finish with open problems. There are no previously known results for universal bufferless packet switching algorithms with near-optimal delivery time guarantees. However, there are efficient algorithms for specific bufferless models and architectures, which we summarize below.. In hot-potato algorithms, packets are deflected in a collision to available links [8] . Our model of bufferless algorithms is based on the hot-potato model, with the significant exception that in collisions, packets are deflected on particular available edges specified by the emulation, and not on any available edge as is typically done in hot-potato algo-rithms. This enables us to control the positions of the packets and implicitly obtain the aforementioned paths P and a collision-free schedule on them. Hot-potato algorithms have been extensively studied for a variety of architectures such as the mesh and torus [7, 9, 10, 14, 16, 18, 19, 20, 26, 25, 29, 30, 38, 47] , hypercubes [13, 15, 26, 28, 41] , trees [23, 45] , vertex-symmetric networks [35] , and leveled networks [12, 17, 21] . Typically, by allowing packets to deviate slightly from their pre-selected paths, one obtains delivery times that are within poly-logarithmic factors of optimal.. In direct packet scheduling (collision-free packet scheduling), packets follow their paths without buffering and without any collisions, [4, 49, 22] . Busch et al. [22] give a comprehensive study of direct scheduling where they give a universal O(C · D) centralized algorithm, and near-optimal algorithms for the tree, mesh, butterfly and hypercube.. Wormhole algorithms are similar to direct algorithms, although here, packets occupy more than one edge [24, 27] . Cypher et al. [24] give a randomized, universal distributed wormhole algorithm with delivery time. , where L is the length of the packet; this bound can be improved if the edges have higher bandwidths. A dual to direct scheduling is time-constrained scheduling, where the task is to schedule as many packets as possible within a given time frame [1, 2] . In the related class of matching routing algorithms, packets are swapped at adjacent nodes. Under this model, permutation problems on trees have been studied in [3, 40, 50] .. There are two variants of store-and-forward algorithms. Those that use outgoing buffers on every edge (edge-buffers) and those that use a single outgoing buffer on every node (nodebuffers). For non-bounded degree networks, these variants may not be equivalent, since one model does not necessarily translate to the other. The existence of universal store-andforward scheduling algorithms with optimal delivery time O(C+D) (plus additive logarithmic terms) and constant size edge-buffers was first established in the seminal work of Leighton, Maggs and Rao [33] . Scheideler [46] showed that edge-buffers of size 2 are sufficient. These results are non-constructive. Thereafter, the main focus has been on constructive algorithms with optimal delivery time O(C + D) [11, 34, 36, 39, 42] . These algorithms use large buffers (proportional to the congestion C). Leighton et al. [33] give a universal distributed algorithm that uses edge-buffers of size O(log N D) and has delivery time O(C + D log N D). Cypher et al. [24] give an algorithm with edge-buffers of size O(log CD) and slightly better delivery time. There are no better constructive results known for arbitrary networks that achieve smaller buffer sizes.. Our bufferless algorithm is based on emulating the universal distributed distributed storeand-forward algorithm in Leighton et al. [33] . Here, we analyze the delivery time of this algorithm in terms of the node congestion C and bound the node-buffer requirements, which is necessary for determining the performance of the bufferless emulation.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O