CMSC 838Y Paper Reviews

Skip down to paper 0: Michael Hicks, Jonathan T. Moore, and Scott Nettles. Dynamic software updating. In Proceedings of the ACM SIGPLAN Conference on Programming Language Design and Implementation, pages 13-23. ACM, June 2001. [ .ps ]


Reviews for paper 0

Review from Michael Hicks <mwh@cs.umd.edu> at Sat Feb 22 08:49:50 EST 2003:

Yeah, baby---what a great paper! :)

Review from Yuan Yuan<yuanyuan@cs> at Mon Feb 24 21:07:13 EST 2003:

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.  
 

Review from Prashant Lamba<plamba@wam.umd.edu> at Wed Feb 26 14:34:05 EST 2003:

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. 

Review from Bryan Payne <bdpayne@cs> at Wed Feb 26 20:58:34 EST 2003:

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.

Review from Yuan Yuan <yuanyuan@cs> at Wed Feb 26 22:38:03 EST 2003:

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.

Review from Brian Krznarich bjkrz@cs at Thu Feb 27 08:36:25 EST 2003:

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.  




Review from Piyush Bhagat<piyushb@glue.umd.edu> at Thu Feb 27 10:30:00 EST 2003:

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.    

Review from Polyvios Pratikakis <polyvios@cs> at Thu Feb 27 10:40:06 EST 2003:

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.

Review from Nathaniel Waisbrot <waisbrot@cs> at Thu Feb 27 11:43:16 EST 2003:

	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.

Review from Jeff Odom <jodom@cs.umd.edu> at Thu Feb 27 11:52:16 EST 2003:

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.

Review from James Rose <rosejr@cs> at Thu Feb 27 12:26:28 EST 2003:

	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.  

Review from Mujtaba Ali <mujtaba@bitsmart.com> at Thu Feb 27 12:33:42 EST 2003:

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


mwh@cs.umd.edu