Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595193
M. Day
Synchronous groupware is the class of applications in which two or more people collaborate in what they perceive to be real time. Most previous efforts to deploy synchronous groupware have failed. The author argues that: synchronous groupware can often be deployed independently of system support for audio, video, or persistent storage; deployment and maintenance of different synchronous groupware applications becomes more reasonable if those applications can share and reuse a common coordination infrastructure, called a notification service; and the most likely way to achieve such sharing and reuse is by the definition of a common notification service protocol. At Lotus, we have designed and implemented such a protocol, called the Notification Service Transfer Protocol (NSTP). Our implementation, called PlaceHolder, has been available from our Web site since November 1996.
同步群件是一类应用程序,其中两个或更多的人以他们认为是实时的方式进行协作。以前部署同步群件的大多数努力都失败了。作者认为:同步群件通常可以独立于系统对音频、视频或持久存储的支持进行部署;如果不同的同步群件应用程序能够共享和重用一个称为通知服务的公共协调基础设施,那么这些应用程序的部署和维护将变得更加合理;实现这种共享和重用的最有可能的方法是通过定义公共通知服务协议。在Lotus,我们设计并实现了这样一个协议,称为通知服务传输协议(Notification Service Transfer protocol, NSTP)。我们的实现称为PlaceHolder,从1996年11月起就可以从我们的Web站点获得。
{"title":"What synchronous groupware needs: notification services","authors":"M. Day","doi":"10.1109/HOTOS.1997.595193","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595193","url":null,"abstract":"Synchronous groupware is the class of applications in which two or more people collaborate in what they perceive to be real time. Most previous efforts to deploy synchronous groupware have failed. The author argues that: synchronous groupware can often be deployed independently of system support for audio, video, or persistent storage; deployment and maintenance of different synchronous groupware applications becomes more reasonable if those applications can share and reuse a common coordination infrastructure, called a notification service; and the most likely way to achieve such sharing and reuse is by the definition of a common notification service protocol. At Lotus, we have designed and implemented such a protocol, called the Notification Service Transfer Protocol (NSTP). Our implementation, called PlaceHolder, has been available from our Web site since November 1996.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"23 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128412788","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595195
John Chapin
The memory systems of modern computers are much more complicated than the ones for which the operating system memory management algorithms in current widespread use were developed. Additionally, the way in which computer systems are used has changed substantially. This paper argues that these changes are sufficient to require reevaluating some of the fundamental assumptions made in operating system memory management. One obvious problem motivating this reevaluation is that current systems do a terrible job of maintaining performance for high-priority processes when the system comes under memory pressure due to the behavior of low-priority processes. This paper discusses potential operating system modifications and proposes a new metric, the system memory cycles per instruction (system MCPI) of a process, which can be used to evaluate these modifications.
{"title":"A fresh look at memory hierarchy management","authors":"John Chapin","doi":"10.1109/HOTOS.1997.595195","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595195","url":null,"abstract":"The memory systems of modern computers are much more complicated than the ones for which the operating system memory management algorithms in current widespread use were developed. Additionally, the way in which computer systems are used has changed substantially. This paper argues that these changes are sufficient to require reevaluating some of the fundamental assumptions made in operating system memory management. One obvious problem motivating this reevaluation is that current systems do a terrible job of maintaining performance for high-priority processes when the system comes under memory pressure due to the behavior of low-priority processes. This paper discusses potential operating system modifications and proposes a new metric, the system memory cycles per instruction (system MCPI) of a process, which can be used to evaluate these modifications.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130934336","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595194
M. Seltzer, Christopher Small
Extensible operating systems allow applications to modify kernel behavior by providing mechanisms for application code to run in the kernel address space. Extensibility enables a system to efficiently support a broader class of applications than is currently supported. This paper discusses the key challenge in making extensible systems practical: determining which parts of the system need to be extended and how. The determination of which parts of the system need to be extended requires self-monitoring, capturing a significant quantity of data about the performance of the system. Determining how to extend the system requires self-adaptation. In this paper, we describe how an extensible operating system (VINO) can use in situ simulation to explore the efficacy of policy changes. This automatic exploration is applicable to other extensible operating systems and can make these systems self-adapting to workload demands.
{"title":"Self-monitoring and self-adapting operating systems","authors":"M. Seltzer, Christopher Small","doi":"10.1109/HOTOS.1997.595194","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595194","url":null,"abstract":"Extensible operating systems allow applications to modify kernel behavior by providing mechanisms for application code to run in the kernel address space. Extensibility enables a system to efficiently support a broader class of applications than is currently supported. This paper discusses the key challenge in making extensible systems practical: determining which parts of the system need to be extended and how. The determination of which parts of the system need to be extended requires self-monitoring, capturing a significant quantity of data about the performance of the system. Determining how to extend the system requires self-adaptation. In this paper, we describe how an extensible operating system (VINO) can use in situ simulation to explore the efficacy of policy changes. This automatic exploration is applicable to other extensible operating systems and can make these systems self-adapting to workload demands.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"64 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121796771","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595175
B. Ford, Kevin Van Maren, Jay Lepreau, S. Clawson, Bart Robinson, J. Turner
To an unappreciated degree, research both in operating systems (OSs) and their programming languages has been severely hampered by the lack of cleanly reusable code providing mundane low-level OS infrastructure such as bootstrap code and device drivers. The Flux OS Toolkit solves this problem by providing a set of clean, well-documented components. These components can be used as basic building blocks both for operating systems and for booting language run-time systems directly on the hardware. The toolkit's implementation itself embodies reuse techniques by incorporating components such as device drivers, file systems and networking code, unchanged, from other sources. We believe the kit also makes feasible the production of highly assured embedded and operating systems: by enabling reuse of low-level code, the high cost of detailed verification of that code can be amortized over many systems for critical environments. The OS toolkit is already heavily used in several different OS and programming language projects, and has already catalyzed research and development that would otherwise never have been attempted.
在某种程度上,操作系统(OS)及其编程语言的研究由于缺乏提供普通底层操作系统基础设施(如引导代码和设备驱动程序)的干净可重用代码而受到严重阻碍。Flux OS Toolkit通过提供一组清晰、文档完备的组件解决了这个问题。这些组件既可以用作操作系统的基本构建块,也可以用作直接在硬件上启动语言运行时系统的基本构建块。该工具包的实现本身通过合并来自其他来源的组件(如设备驱动程序、文件系统和网络代码)来体现重用技术。我们相信该工具包还使高度可靠的嵌入式和操作系统的生产成为可能:通过支持低级代码的重用,对代码进行详细验证的高成本可以分摊到关键环境的许多系统上。操作系统工具包已经在几个不同的操作系统和编程语言项目中大量使用,并且已经催化了原本从未尝试过的研究和开发。
{"title":"The Flux OS Toolkit: reusable components for OS implementation","authors":"B. Ford, Kevin Van Maren, Jay Lepreau, S. Clawson, Bart Robinson, J. Turner","doi":"10.1109/HOTOS.1997.595175","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595175","url":null,"abstract":"To an unappreciated degree, research both in operating systems (OSs) and their programming languages has been severely hampered by the lack of cleanly reusable code providing mundane low-level OS infrastructure such as bootstrap code and device drivers. The Flux OS Toolkit solves this problem by providing a set of clean, well-documented components. These components can be used as basic building blocks both for operating systems and for booting language run-time systems directly on the hardware. The toolkit's implementation itself embodies reuse techniques by incorporating components such as device drivers, file systems and networking code, unchanged, from other sources. We believe the kit also makes feasible the production of highly assured embedded and operating systems: by enabling reuse of low-level code, the high cost of detailed verification of that code can be amortized over many systems for critical environments. The OS toolkit is already heavily used in several different OS and programming language projects, and has already catalyzed research and development that would otherwise never have been attempted.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"47 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127468716","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595183
David Mazières, M. Kaashoek
As information exchange over wide area networks becomes an increasingly essential component of new applications, firewalls will no longer provide an adequate defense against malicious attackers. Individual workstations will need to provide strong enough security to contain malicious processes and prevent the domino effect of a pierced firewall. Some of the most commonly found security holes today result from the fact that simple operations can be surprisingly difficult to implement correctly on top of a traditional POSIX-like interface. We claim that by combining hierarchically-named capabilities, a novel generalization of the Unix user and group ID concept, with the low-level system calls of an exokernel operating system, we can achieve a system-call interface which is flexible enough to avoid much of the complexity that often leads to security holes in discretionary access control operating systems like Unix.
{"title":"Secure applications need flexible operating systems","authors":"David Mazières, M. Kaashoek","doi":"10.1109/HOTOS.1997.595183","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595183","url":null,"abstract":"As information exchange over wide area networks becomes an increasingly essential component of new applications, firewalls will no longer provide an adequate defense against malicious attackers. Individual workstations will need to provide strong enough security to contain malicious processes and prevent the domino effect of a pierced firewall. Some of the most commonly found security holes today result from the fact that simple operations can be surprisingly difficult to implement correctly on top of a traditional POSIX-like interface. We claim that by combining hierarchically-named capabilities, a novel generalization of the Unix user and group ID concept, with the low-level system calls of an exokernel operating system, we can achieve a system-call interface which is flexible enough to avoid much of the complexity that often leads to security holes in discretionary access control operating systems like Unix.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"122 6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116311063","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595192
Michael Franz
We are building an operating system in which an integral run time code generator constantly strives to improve the quality of already executing code. Our system is based on a platform independent software distribution format twice as dense as Java byte codes that is translated into native code only at the time of loading. This initial translation happens in a single burst and puts compilation speed ahead of code quality, so that program execution can commence immediately. However, the native code generated during loading will usually not be executed for long. Immediately after a program has started running, its code image becomes a candidate for reoptimization. A background process that executes only during otherwise idle processor cycles continuously recompiles parts of the already running system, guided by run time profiling data, and is able to substitute already executing code in situ. This reoptimization encompasses not only user programs, but also many of the system libraries, eventually combining an application program and most of its dynamically loaded extensions and libraries into a single, fully cross optimized, quasi monolithic code image. Our system is thereby able to provide the efficiency of statically optimized software in spite of being extensible at run time.
{"title":"Run-time code generation as a central system service","authors":"Michael Franz","doi":"10.1109/HOTOS.1997.595192","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595192","url":null,"abstract":"We are building an operating system in which an integral run time code generator constantly strives to improve the quality of already executing code. Our system is based on a platform independent software distribution format twice as dense as Java byte codes that is translated into native code only at the time of loading. This initial translation happens in a single burst and puts compilation speed ahead of code quality, so that program execution can commence immediately. However, the native code generated during loading will usually not be executed for long. Immediately after a program has started running, its code image becomes a candidate for reoptimization. A background process that executes only during otherwise idle processor cycles continuously recompiles parts of the already running system, guided by run time profiling data, and is able to substitute already executing code in situ. This reoptimization encompasses not only user programs, but also many of the system libraries, eventually combining an application program and most of its dynamically loaded extensions and libraries into a single, fully cross optimized, quasi monolithic code image. Our system is thereby able to provide the efficiency of statically optimized software in spite of being extensible at run time.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"69 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126773436","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595178
Francisco J. Ballesteros, Luis López-Fernández
To build a distributed operating system (OS), the microkernel approach is the most popular. To build an adaptable OS, a minimal microkernel is preferred, but for an adaptable and flexible distributed OS, the previous approaches are not enough because they create an artificial barrier to OS distribution and harm system transparency and adaptability. This paper express how adaptable distributed systems could be built and describes an example implementation named Off where the microkernel itself and its abstractions are both distributed and adaptable. It is shown why the system interface should be close to the hardware but not restricted to a local node. The whole network is considered to be the exported and multiplexed hardware, in contrast to what is done by today microkernel in "distributed" OSs, eliminating the artificial view of nodes as isolated entities.
{"title":"The network hardware is the operating system","authors":"Francisco J. Ballesteros, Luis López-Fernández","doi":"10.1109/HOTOS.1997.595178","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595178","url":null,"abstract":"To build a distributed operating system (OS), the microkernel approach is the most popular. To build an adaptable OS, a minimal microkernel is preferred, but for an adaptable and flexible distributed OS, the previous approaches are not enough because they create an artificial barrier to OS distribution and harm system transparency and adaptability. This paper express how adaptable distributed systems could be built and describes an example implementation named Off where the microkernel itself and its abstractions are both distributed and adaptable. It is shown why the system interface should be close to the hardware but not restricted to a local node. The whole network is considered to be the exported and multiplexed hardware, in contrast to what is done by today microkernel in \"distributed\" OSs, eliminating the artificial view of nodes as isolated entities.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"98 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122806590","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595182
N. Mendelsohn
Although component software has emerged as one of the most significant and commercially successful technologies of the past few years, few operating systems (OSs) are designed to host and manage component software effectively. Components impact OS architectures in the areas of security, process isolation, code sharing, installation management and user interface design. A more radical question is: can effective OSs be built of modular, interchangeable component parts? The thesis of this paper is that effective support of components is a key requirement for OSs of the future.
{"title":"Operating systems for component software environments","authors":"N. Mendelsohn","doi":"10.1109/HOTOS.1997.595182","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595182","url":null,"abstract":"Although component software has emerged as one of the most significant and commercially successful technologies of the past few years, few operating systems (OSs) are designed to host and manage component software effectively. Components impact OS architectures in the areas of security, process isolation, code sharing, installation management and user interface design. A more radical question is: can effective OSs be built of modular, interchangeable component parts? The thesis of this paper is that effective support of components is a key requirement for OSs of the future.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"283 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133924808","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595189
S. Gadde, M. Rabinovich, J. Chase
New demands brought by the continuing growth of the Internet will be met in part by more effective use of caching in the Web and other services. We have developed CRISP, a distributed Internet object cache targeted to the needs of the organizations that aggregate the end users of Internet services, particularly the commercial Internet Service Providers (ISPs) where much of the new growth occurs. A CRISP cache consists of a group of cooperating caching servers sharing a central directory of cached objects. This simple and obvious strategy is easily overlooked due to the well known drawbacks of a centralized structure. However, we show that these drawbacks are easily overcome for well configured CRISP caches. We outline the rationale behind the CRISP design, and report on early studies of CRISP caches in actual use and under synthetic load. While our experience with CRISP to date is at the scale of hundreds or thousands of clients, CRISP caches could be deployed to maximize capacity at any level of a regional or global cache hierarchy.
{"title":"Reduce, reuse, recycle: an approach to building large Internet caches","authors":"S. Gadde, M. Rabinovich, J. Chase","doi":"10.1109/HOTOS.1997.595189","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595189","url":null,"abstract":"New demands brought by the continuing growth of the Internet will be met in part by more effective use of caching in the Web and other services. We have developed CRISP, a distributed Internet object cache targeted to the needs of the organizations that aggregate the end users of Internet services, particularly the commercial Internet Service Providers (ISPs) where much of the new growth occurs. A CRISP cache consists of a group of cooperating caching servers sharing a central directory of cached objects. This simple and obvious strategy is easily overlooked due to the well known drawbacks of a centralized structure. However, we show that these drawbacks are easily overcome for well configured CRISP caches. We outline the rationale behind the CRISP design, and report on early studies of CRISP caches in actual use and under synthetic load. While our experience with CRISP to date is at the scale of hundreds or thousands of clients, CRISP caches could be deployed to maximize capacity at any level of a regional or global cache hierarchy.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"487 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122171251","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 1997-05-05DOI: 10.1109/HOTOS.1997.595173
F. Rawson
During the first half of the 1990s, IBM developed a set of operating system products called Workplace OS that was based on the Mach 3.0 microkernel and Taligent's object-oriented TalOS. These products were intended to be scalable, portable and capable of concurrently running multiple operating system personalities while sharing as much code as possible. The operating system personalities were constructed out of a set of user-level personality and personality-neutral servers and libraries. While we made a number of important changes to Mach 3.0, we maintained its fundamentals and the multi-server design throughout our project. In evaluating the resulting system, a number of problems are apparent. There is no good way to factor multiple existing systems into a set of functional servers without making them excessively large and complex. In addition, the message-passing nature of the microkernel turns out to be a poor match for the characteristics of modern processors, causing performance problems. Finally, the use of fine-grained objects complicated the design and further reduced the performance of the system. Based on this experience, I believe that more modest, more targeted operating systems consume fewer resources, offer better performance and can provide the desired semantics with fewer compromises.
{"title":"Experience with the development of a microkernel-based, multiserver operating system","authors":"F. Rawson","doi":"10.1109/HOTOS.1997.595173","DOIUrl":"https://doi.org/10.1109/HOTOS.1997.595173","url":null,"abstract":"During the first half of the 1990s, IBM developed a set of operating system products called Workplace OS that was based on the Mach 3.0 microkernel and Taligent's object-oriented TalOS. These products were intended to be scalable, portable and capable of concurrently running multiple operating system personalities while sharing as much code as possible. The operating system personalities were constructed out of a set of user-level personality and personality-neutral servers and libraries. While we made a number of important changes to Mach 3.0, we maintained its fundamentals and the multi-server design throughout our project. In evaluating the resulting system, a number of problems are apparent. There is no good way to factor multiple existing systems into a set of functional servers without making them excessively large and complex. In addition, the message-passing nature of the microkernel turns out to be a poor match for the characteristics of modern processors, causing performance problems. Finally, the use of fine-grained objects complicated the design and further reduced the performance of the system. Based on this experience, I believe that more modest, more targeted operating systems consume fewer resources, offer better performance and can provide the desired semantics with fewer compromises.","PeriodicalId":176246,"journal":{"name":"Proceedings. The Sixth Workshop on Hot Topics in Operating Systems (Cat. No.97TB100133)","volume":"65 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1997-05-05","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126276941","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}