As mentioned by others earlier in this blog, CloudWave is about "allowing both the applications running on the Cloud and the underlying Cloud infrastructure to mutually change their behavior to improve efficiency and lower the costs". On the application adaptation side of things, the idea is primarily to "expose interfaces for developers to register the "buttons and knobs" for application adaptation". However, application adaptation is not limited to what developers choose (or are able) to expose. While high-level, algorithmic, application-specific, and/or functional adaptations would indeed rely on developers exposing them, other kinds of adaptations, those that are lower-level, generic, and non-functional, could be carried out by an agent external to the application and independent of (and transparent to) the developer. In CloudWave this agent is a dynamic code optimizer, that can be available on some Virtual Machines (VMs), and has the ability to analyze and transform program code while the program is running.
There are many situations in which such dynamic code adaptation (recompilation) could be useful. One example is upon migration: some applications are sensitive to the exact features of the underlying physical host they are running on. A dynamic code optimizer can specialize / tune the program code according to the exact model of physical host they are deployed on, or migrated to. Alternatively, dynamic code adaptation could be used in place of migration, as a light weight adaptation mechanism in such cases where migration to a different host might take too long or is not possible. For example, the Cloud may detect situations in which several applications are using the same shared physical resources and are interrupting one another: maybe a group of very large programs are competing for the same code cache, or maybe a group of very computationally intensive applications are competing for the same functional unit. One possible adaptation could be at the Cloud infrastructure level: assign more memory/computing resources to these applications, or alternatively migrate some of these applications to other hosts. However, such changes in resource allocation or application placement are not always readily available. Instead, the Cloud could change the application itself, e.g., to consume less code cache space, or to use different functional units, by invoking the dynamic optimizer and instructing it to recompile the program with a certain optimization goal (namely reduced code size, instead of the default strategy of compiling for maximum performance).
Another aspect in CloudWave's coordinated-adaptation vision mentioned in the previous posts, is that the infrastructure and the application can negotiate on how to obtain various improvements. Here again the dynamic code analysis agent can act on behalf of the application in providing information about the application to the Cloud. Considering the above scenario, the dynamic code analyzer could provide an estimation on how much code reduction it could provide, and possibly also evaluate at what performance cost. This would in turn allow the Cloud's coordinated-adaptation engine to make more informed decisions in choosing which adaptation mechanism to apply. With such a technology in its toolbox, that complements the application-adaptation mechanisms supplied by the developer, the Cloud has much more flexibility in responding to various situations and changing requirements.