Keeping bugs in check: The mucus layer as a critical component in maintaining intestinal homeostasis

In the mammalian gastrointestinal tract the close vicinity of abundant immune effector cells and trillions of commensal microbes requires sophisticated barrier and regulatory mechanisms to maintain vital host-microbial interactions and tissue homeostasis. During co-evolution of the host and its intestinal microbiota a protective multilayered barrier system was established to segregate the luminal microbes from the intestinal mucosa with its potent immune effector cells, limit bacterial translocation into host tissues to prevent tissue damage, while ensuring the vital functions of the intestinal mucosa and the luminal gut microbiota. In the present review we will focus on the different layers of protection in the intestinal tract that allow the successful mutualism between the microbiota and the potent effector cells of the intestinal innate and adaptive immune system. In particular, we will review some of the recent findings on the vital functions of the mucus layer and its site-specific adaptations to the changing quantities and complexities of the microbiota along the (gastro-) intestinal tract. Understanding the regulatory pathways that control the establishment of the mucus layer, but also its degradation during intestinal inflammation may be critical for designing novel strategies aimed at maintaining local tissue homeostasis and supporting remission from relapsing intestinal inflammation in patients with inflammatory bowel diseases.

Species Richness-Environment Relationships of European Arthropods at Two Spatial Grains: Habitats and Countries

We study how species richness of arthropods relates to theories concerning net primary productivity, ambient energy, water-energy dynamics and spatial environmental heterogeneity. We use two datasets of arthropod richness with similar spatial extents (Scandinavia to Mediterranean), but contrasting spatial grain (local habitat and country). Samples of ground-dwelling spiders, beetles, bugs and ants were collected from 32 paired habitats at 16 locations across Europe. Species richness of these taxonomic groups was also determined for 25 European countries based on the Fauna Europaea database. We tested effects of net primary productivity (NPP), annual mean temperature (T), annual rainfall (R) and potential evapotranspiration of the coldest month (PETmin) on species richness and turnover. Spatial environmental heterogeneity within countries was considered by including the ranges of NPP, T, R and PETmin. At the local habitat grain, relationships between species richness and environmental variables differed strongly between taxa and trophic groups. However, species turnover across locations was strongly correlated with differences in T. At the country grain, species richness was significantly correlated with environmental variables from all four theories. In particular, species richness within countries increased strongly with spatial heterogeneity in T. The importance of spatial heterogeneity in T for both species turnover across locations and for species richness within countries suggests that the temperature niche is an important determinant of arthropod diversity. We suggest that, unless climatic heterogeneity is constant across sampling units, coarse-grained studies should always account for environmental heterogeneity as a predictor of arthropod species richness, just as studies with variable area of sampling units routinely consider area.

Practical Object-Oriented Back-in-Time Debugging

Back-in-time debuggers are extremely useful tools for identifying the causes of bugs, as they allow us to inspect the past states of objects no longer present in the current execution stack. Unfortunately the "omniscient" approaches that try to remember all previous states are impractical because they either consume too much space or they are far too slow. Several approaches rely on heuristics to limit these penalties, but they ultimately end up throwing out too much relevant information. In this paper we propose a practical approach to back-in-time debugging that attempts to keep track of only the relevant past data. In contrast to other approaches, we keep object history information together with the regular objects in the application memory. Although seemingly counter-intuitive, this approach has the effect that past data that is not reachable from current application objects (and hence, no longer relevant) is automatically garbage collected. In this paper we describe the technical details of our approach, and we present benchmarks that demonstrate that memory consumption stays within practical bounds. Furthermore since our approach works at the virtual machine level, the performance penalty is significantly better than with other approaches.

Flow-Centric, Back-In-Time Debugging

Conventional debugging tools present developers with means to explore the run-time context in which an error has occurred. In many cases this is enough to help the developer discover the faulty source code and correct it. However, rather often errors occur due to code that has executed in the past, leaving certain objects in an inconsistent state. The actual run-time error only occurs when these inconsistent objects are used later in the program. So-called back-in-time debuggers help developers step back through earlier states of the program and explore execution contexts not available to conventional debuggers. Nevertheless, even back-in-time debuggers do not help answer the question, ``Where did this object come from?'' The Object-Flow Virtual Machine, which we have proposed in previous work, tracks the flow of objects to answer precisely such questions, but this VM does not provide dedicated debugging support to explore faulty programs. In this paper we present a novel debugger, called Compass, to navigate between conventional run-time stack-oriented control flow views and object flows. Compass enables a developer to effectively navigate from an object contributing to an error back-in-time through all the code that has touched the object. We present the design and implementation of Compass, and we demonstrate how flow-centric, back-in-time debugging can be used to effectively locate the source of hard-to-find bugs.

Transactional Memory in a Dynamic Language

Concurrency control is mostly based on locks and is therefore notoriously difficult to use. Even though some programming languages provide high-level constructs, these add complexity and potentially hard-to-detect bugs to the application. Transactional memory is an attractive mechanism that does not have the drawbacks of locks, however the underlying implementation is often difficult to integrate into an existing language. In this paper we show how we have introduced transactional semantics into Smalltalk by using the reflective facilities of the language. Our approach is based on method annotations, incremental parse tree transformations and an optimistic commit protocol. The implementation does not depend on modifications to the virtual machine and therefore can be changed at the language level. We report on a practical case study, benchmarks and further and on-going work.

Mining frequent bug-fix code changes

Detecting bugs as early as possible plays an important role in ensuring software quality before shipping. We argue that mining previous bug fixes can produce good knowledge about why bugs happen and how they are fixed. In this paper, we mine the change history of 717 open source projects to extract bug-fix patterns. We also manually inspect many of the bugs we found to get insights into the contexts and reasons behind those bugs. For instance, we found out that missing null checks and missing initializations are very recurrent and we believe that they can be automatically detected and fixed.

Null Check Analysis

Null dereferencing is one of the most frequent bugs in Java systems causing programs to crash due to the uncaught NullPointerException. Developers often fix this bug by introducing a guard (i.e., null check) on the potentially-null objects before using them. In this paper we investigate the null checks in 717 open-source Java systems to understand when and why developers introduce null checks. We find that 35 of the if-statements are null checks. A deeper investigation shows that 71 of the checked-for-null objects are returned from method calls. This indicates that null checks have a serious impact on performance and that developers introduce null checks when they use methods that return null.