Yeah, baby---what a great paper! :)
From the same token of Knit, authors designed Jiazzi as a component definition and linking language without extending Java language. Jiazzi supports separate compilation, external linking, hierarchical structure, cyclic component dependencies, and class inheritance across component boundaries by using an explicit language to define components. Here is summary for Jiazzi. Jiazzi enhances Java with support for large-scale software components. Jiazzi components are constructed as units. A unit is a container of compiled Java classes with support for ¡°typed¡± connections. Jiazzi includes a component language that provides a convenient way for programmers to build and reason about units. Using this language, the structure of classes in a unit¡¯s imported and exported packages can be described using package signatures. Because package signature can be used in multiple unit definitions, they enhance the component language¡¯s scaling properties. Jiazzi supports the composition of class-extending components; e.g., mixins. Mixins and cyclic component linking can be combined into an open class pattern. With the open class pattern, we can replace the use of many design patterns used to implement modular feature addition, such as abstract factories and bridges, with a combination of external linking and Java¡¯s in-language constructs for subclassing and instantiation. Separate type checking is an essential part of separate compilation. I more like posted a ad for Jiazzi. Here the idea of Jiazzi and Knit is almost the same, the difference just is that they act on different languages. Using explicit language to depict components enabled developing large-scale software components. But extra linking specification need to be written if we want have all the advantages. Sure a graphic tool guiding though classes, object files, and automatic code generator will help.
This paper is about the Dynamic updating of the softwares.Authors expains the concept and need of the dynamic updating pretty well in the paper.Dyaanmic updating means updating the software version without stoping the application.The convensional methods of the software updates needs the application to shut down.But it is not adviceable for many applications .In the bigning of the paper authors presents some of the evaluation criteria for system to be dyanamic like Flexibility,Robustness,Ease of Use and Low Overhead. Accoding to the aurthor the core approach for their framework if Dymanic dispatches.Paper also very well explains the Enabling of the dynamic patches ie how a patch is dynamically linked into the running program.Code and Data Updates and Type Definations are well in the paper.The author is able to give a convincing reason for using Code relinking rather than reference indirection in the paper.In the Sec 3.3 there is a description about building dynamic patches.But paper fails to give suffcient explaintion on when the Dynamic patches are to be applied to the system though there is a brief intorduction to this topic.In the later part of the paper author gives the details of the implementation of the Dynamic Updating of Software and explains the Implemetation of the Flashed Webserver.In the end of the paper the authors gives the performanace analysis of the system. In short the authors are able to explain the concept of the Dyamanic Updating convincingly.But according to me the concept of when to apply patches are not clear in the paper ,it needs more explaination with example.
This paper started out with a nice justification for why dynamic updating is "a good thing". I fel that this was useful as it addressed some of the questions that I had after reading the Gupta et al paper. In general, I found this to be an interesting paper. Seeing that the idea has been tested on a "real" system had a particularly strong impact for this paper because the idea of dynamic updating seems like it would be prone to obscure problems that would only arrise in the implementation stages of an idea. Further, it was nice to see the performance number for FlashEd in order to gain a tangible understanding of the performance for this system. One thing that I found particularly interesting in this paper was the system's ability to automatically create the interface code. It would be interesting to see some examples of the code that's generated and the type of code that must be implemented by hand in order to better understand the level of effort required by the developer to complete this task as this seems to be the main overhead (in the sense of time spent by the developer) to the system.
To support computer programs running without interrupt when updating them, this paper proposed an approach to do type-safe dynamic updating of native code. The key part of this approach is introducing the idea of dynamic patches that are composed of new code and state transformer functions. Then these dynamic patches are built on top of dynamic linking, which is implemented as a type-safe dynamic linker. Also Code re-linking is used to do code and data update and reference indirection to update type definitions. To generate patches files automatically, software development can be separated from patch development and minimize human error. Having these patches, authors suggest to code up an updateable structure to reinforce that patches update system at suitable spot. By illustrating the implementation and a hand-on example, authors give more details and experiences they learn from the dynamic patch model. The performance analysis convinces the model has low cost. The central ideas in this paper are novel, such as automatically identifying changes (including type checking) and generating state transform will increase the robustness of system. Also I think the example listed here help to understand the model further more.
The paper discusses a framework for an actual implementation of a dynamic software updating system. The key contribution seemed to be to be the semi automated patching system developed. An original code base can continue to be updated, then when a patch is required the automated system will diff the original and updated code and produce a large part of the required patch code, eliminating excessive work by the programmer and the potential for a lot of human error. Whatever can't be determined by the system is left for the programmer to fill in. Avoiding issues mentioned in Gupta's paper, the author choses to force the programmer to build in specific points where the program can be safely updated. I agree that this planning is not much to ask of an enterprise which in advance intends to have a dynamically updatable program. Most patching is done using a GOT framework which allows functions to be replaced universally by replacing a single entry. Overhead in their sample system due to the GOT is minimal- which they attribute partially to the IO intensive nature of their application. All work is done with TAL and popcorn, and so considerable overhead is introduced during updates for validation. The offer some solutions, including doing validation offline- though offline validation seems to contradict the original goal of not requiring redundant hardware. The system has a nice facility for rollback in the event of an error during update, and they modify the server to do exception handling and restart on the fly rather than crashing in the event of anerror (which I guess is a pretty standard method now for always on systems). Because the system supports changes in data types and function signatures, intermediate stub functions can be added for translation from the old to new functions. I also think there was some facility for allowing old functions be be 'phased out' through some renaming. Any new linking would be done to the new function version, while the old function would persist until there were no further references to it. I don't know if this was tested in flashos, however. In the example given, a web server, the authors chose to initiate updating by talking to the server through it's public online interface. While this system is only an example and not for deployment, this seems like a pretty hefty security risk to integrate into a server.
The paper is about dynamic software updating which means updating the software functionality or debugging it without shutting down the server or the workstation on which the software is running. The paper emphasizes the need for such systems in mission critical applications. The paper says that the current trend to update software used in mission critical application is to keep hot backup. But this turns out to be expensive and is not affordable by all service providers. The paper lays down guidelines for a dynamic software updating system. It says that the system should be flexible, robust, easy to use and must have low overhead. The paper claims that the dynamic update mechanism suggested by it meets all the above criteria. It is robust as it contains verifiable native code mostly TAL (typed assembly language) which removes the possibility of a system crash and has got low overhead also. The central parts of the dynamic update mechanism suggested by the paper are the dynamic patches. These dynamic patches are dynamically linked to the running program and the running program is changed to new code from old code. This change includes updates in code, data and type definitions. The paper then goes into detail of its framework of dynamic updating dealing with topics like automatic patch generation. Finally the paper applies this to a web server and analyses it for issues like performance, flexibility robustness etc. I feel that the mechanism meets more or less all the criteria set by the paper.
An effort to create a safe dynamic code patching system is presented in this paper. Initially, the need for dynamic upgrade of running programs is presented, and the need for safety underlined. The goals for a well-designed such system are mentioned, and the framework developed is presented, in terms of how it satisfies those goals. The handling of changes in types and data is presented, and the tools constructed to help in creating the patches. A description of the implementation follows. Finally, an example is presented, which helps the reader understand better how the framework works. Performance measurements for that example are discussed, concluding with presenting how previous work did not satisfy all the goals for such a system. I think this paper is well written, helps the reader understand the problem, and presents the solution in a very clear and understandable way. The drawback of the system is that it demands the use of a type safe C-like language, which is not very widely used, therefore restraining the applications of this framework.
The framework described in this paper is similar to the formal framework described in today's other paper. The major difference is that Hicks et al. address the issue of types being altered by the transition. Changing types is significant when the modified program has a function whose parameters or return types have changed from the original. In this case, the update needs to make changes up and down the calling chain, and also needs to transform the current variables into the new types. After the framework has been defined, the paper describes a semi-automated system for creating a patch out of the modified code. The patch generator is able to write code to transform compatible types and types inside data structures safely, and it flags the transformations that need to be coded by a human. The whole thing is written in TAL, so they can ensure type safety in the update. Finally, the paper included some analysis of the FlashEd webserver, a web-server which was rewritten in their framework, and how they were able to perform dynamic updates on it. Overall, this paper demonstrated both an actual implementation of a dynamic update framework and an extension of Gupta et al.'s formal framework by discussing types. This could probably have been two or three separate papers, going into more depth on the various aspects of this project. I was interested in the discussion of garbage collection on the superseded parts of the program, and I would have liked for the mechanics of the update to be discussed in a little more depth.
Unlike the Gupta paper, this paper focuses on an implementation of a dynamic updating system. The authors introduce the concept of Dynamic Patches, which relinks the current program to run the new code upon subsequent invocations (i.e. next function call). Types of functions/data may change, but doing so may (and in general should) require changes of code which reference the old types, so as to satisfy the type checker. Of particular interest was that the system required that a new version of the program be tested offline, and then automatic patches (up to a point) are generated, resulting in less human interaction and therefore fewer possibilities for error. Also of note was that currently executing functions could be replaced, so long as doing so would not put the system in an indeterminate state. This was achieved by having the programmers note "safe points" where state transitions could be achieved.
This paper is not the one I thought it was at 11:00, so this may be rushed. Unlike the Gupta paper, this paper speaks in specifics and provides an actual updateable application. It also provides a mechanism for preserving type-safety. It addresses the issue of update timing by requiring that locations for potential updates must be specified statically; this makes the problem much more tractable for both human and machine analyses.
This paper was different from the other one in that it also included type safety as a primary concern. The mention of how "normal" users could benefit from dynamic updates was also interesting. The ease of use issue is often glossed over and with a patch tool, I can see more and more people adopting this approach. Additionally, it was nice to see terms such as alpha-conversion and know what they mean. Also, the first time the GOT scheme was introduced, I instantly thought "bad performance", but the benchmarks later allayed my fears.
Generated: Thu Mar 6 15:39:24 EST 2003 by mwh