The first talk, by Michael Franz from University of California at Irvine, was about having a run time code generator as an integral part of the OS that would constantly strive to improve the quality of already executing code.

In the second talk, Mark Day of Lotus Development Corporation argues about the need for using notification services for easy deployment and maintenance of different synchronous groupware applications.

Extended Discussion

The first speaker was Michael Franz (picture to the right) from University of California at Irvine. The title of his talk was "Run-Time Code Generation as a Central System Service". The code generator has two modes. One, which does a quick and dirty translation so that the program can start running as soon as possible. In the other mode which runs in background, the already executing code is continually re-optimized.

The main thrust of Michael's doctoral thesis was to show that if the I/O overhead of loading is reduced by making the object code more compact, it could almost compensate for the time spent in regenerating the code at load time. With CPU performance increasing much more than I/O performance, and with wireless computing becoming more popular, these results become more interesting.

But all these code fragments, generated separately at load time, are not as good as the code generated by an optimizing compiler. Addressing this issue, the paper suggests that we have an OS function that recompiles parts of the already running system in the background, guided by the run-time profiling data, and that is able to substitute already executing code in situ. This recompilation would combine an application program with most of its dynamically loaded extentions and libraries into a single, fully cross-optimized, quasi-monolithic image. Giving some examples, Michael said that inlining can now be done across arbitrary boundaries between distribution units. Also, global register allocation, and global cache co-ordination would now be possible.

Michael concluded by saying that since hardware is becoming cheaper, we could just add another processor that only keeps generating code for the remaining processors in the system.

Discussion:

• Dave Presotto (Bell Labs) said that given that slim binaries are basically decorated parse trees, we shouldn't need the function of the Java byte code verifier. Michael agreed, saying that their compression scheme making use of scoping information, so it is impossible to construct an illegal program that does an illegal reference.

• To a question by Jochen Liedtke (IBM), Michael replied that as processors become faster, the effort to generate optimized code for them also grows, so it is not clear if it ultimately takes lesser time.

• Jochen also pointed out that today, memory is the bottleneck, and adding a another processor (dedicated to run-time code generation) with memory access would make things worse.

• John Chapin (MIT) asked if it was really worthwhile re-optimizing the code, and if so, whether that needs to be a core OS service as opposed to some run-time technique over an existing OS. Michael said that having it in the OS would enable the OS itself to be included into the optimizations.

• Alan Nemeth (DEC) pointed out that we would have multiple instances of the same executable in memory as a result. Brad Chen (Harvard) asked how this system could be changed to support dynamically shared libraries.

• Peter Druschel (Rice) said that the system would not run well under heavy load. Michael agreed, saying that he was targetting an interactive system, actually a desktop.

• Margo Seltzer (Harvard) pointed out that different applications use the OS differently. Since the profiler is going to do the optimizations based on what was running last, and the next thing that runs is going to use the OS differently, the optimizations that were done could be exactly the wrong ones.

• Brian Noble (CMU) raised the issue of handling function pointers. Michael replied that the function pointers could point to the original code image.

The next speaker was Mark Day from Lotus Development Corporation. The title of his talk was "What Synchronous Groupware Needs: Notification Services".

Mark started out by talking about the problem domain of synchronous groupware. Giving an analogy, he said that synchronous groupware is to meetings (where everything happens at the same time), as asynchronous groupware is to documents (where people create, read and modify them at different times.) Where there is a lot of asynchronous groupware available, like filesystems, databases etc., Mark said that synchronous groupware has been largely a research topic. Chat and network games are some examples of synchronous groupware applications.

Mark argued that the synchronous groupware apps have common co-ordination problems, and that a notification server is what is needed to provide that common service. A notification server basically provides a place to hold a small amount of shared data. It also provides a relatively simple service where the clients can get the shared data from the server, and any time a client updates the shared data, all the clients get informed about it.

Mark said that this service was very different from callbacks in AFS in terms of granularity and frequency of callbacks. He also said that this was different from Zephyr because Zephry did not include any notion of state and it was just pure multicast.

Finally, Mark talked about the particular design choices they made to build a protocol for notification services, namely, protocol NSTP. NSTP has a centralized state, but a decentrelized semantics. The servers maintain the shared state, but only the clients understand it. This offloads the server, and also makes the servers relatively easy to build. Also, the clients can use any encryption scheme, or any compression scheme, etc., and the server doesnot have to know about it.

Discussion:

• Margo Saltzer (Harvard) asked how this problem and solution were different from that in the network games talk by Tzi-cker Chiueh. Mark replied that the non-time critical and non-space dependent pieces of the network games could be implemented over NSTP, but it might turn out to be a naive implementation. Also, Mark pointed out that in the network games, distance metrics were embedded in the lower system.

• John Chapin (MIT) asked if they had looked into the issue of scale where the notification server is a logical entity geographically distributed across many machines. Mark said that though they had defined the client to server protocol, they haven't looked into the server to server protocol yet.

• Robert Grimm (Seattle) raised the issue of authentication. Mark said they have authentication at the entry level, and also a rudimentary from of access control.

• Dave Presotto (Bell Labs) asked about name spaces. Mark said that the server implements the name space. Regarding inter-server name space, Mark said that some URL scheme could be used.

• Brett Fleisch (UC-Riverside) commented that as the complexity of the notification server grows, it would be more like a database.

• Dejan Milojicic (Open group) enquired if the notion of users was missing in the abstraction where they had only places and things. Mark said that having users as manipulative objects was a wierd case to handle, and they decided it was not necessary to have that.