Soma-notes - User contributions [en]

COMP 3000 Essay 2 2010 Question 7

2010-12-02T09:30:55Z

Mkugler: /* How it works */

==Paper==
===[http://homeostasis.scs.carleton.ca/wiki/index.php/COMP_3000_Essay_2_2010_Question_7 Ad Hoc Synchronization Considered Harmful]===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel

==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

The paper we are discussing addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==

===Concurrent Programming===
Concurrent programming is a style of programming where multiple threads of execution run concurrently to perform a single task. The thread of execution share a number of resources. Particularly in multi-core processor system and in distributed environment this style of programming can result in significant performance gains. One significant challenge of concurrent programming is coordinating the different threads of execution, this is usually done using synchronization primitives.

===Synchronization Primitives===
Synchronization primitives represent some of the basic tools offered by the system containing the concurrent program to facilitate coordination between of threads of execution. They are generally used to synchronize between threads, and to protect shared resource[[#Foot8|8]].
Some type of synchronization primitives common to many are locks, mutexes, semaphores, and monitors.
Locks are really a superset of synchronization primitives since mutexes, semaphores, and monitors are all locks. Additionally there are read/write locks that only lock when a reader obtains the lock. Latches a type of lock that unlocks when a specified number of threads have obtained it which is very useful in facilitate threads all getting to known state, there are a myriad of other locks.
Mutexes are mutually exclusive locks that threads employ to lock a resource that they need preventing other. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Monitors are a type of mutex that contain a condition variables which is a variable that if not true, releases the lock and blocks the thread until the certain condition is met, by another thread changing value of the variable. This allows the original thread to only continue execute when it is safe to perform its operation.
Synchronization primitives can be misused and lead to a host of other problems generally referred to collectively as race conditions.
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronization is required to ensure that the executing tasks do not interfere with each other avoiding potential race conditions. However, many programmers do not use proper synchronization primitives to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. The paper we are discussing shows that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this programming construct and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* Often, exit conditions depend on sync variables, variables that are shared with other tasks
* In some cases, the synchronization does not wait idly and rather performs other computations while checking the sync variable periodically

Despite the dangers of using ad hoc synchronization, programmers continue to use this method. It is found that, in comments, programmers have stated that possibly their implementations are unsafe but proceed to use ad hoc synchronization techniques. The reasoning behind these decisions have already been outlined in point 1. A better practice of synchronization would be to replace ad hoc synchronizations with synchronization primitives, primitives already present in standard POSIX thread libraries. However, it is often difficult to replace ad hoc synchronizations with synchronization primitives and doing this may not fulfill the concerns presented in point 1.

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization.

====How it works====
There are two possibilities to consider when searching for ad hoc synchronizations. You can either analyze runtime traces via a dynamic method, or analyze the source code in a static method. Both methods carry with them a number of pros and cons. While a dynamic process is generally more accurate than a static method, it tends to accrue a very large runtime overhead. In addition to this, the dynamic method is somewhat limited in which ad hoc synchronizations it can find by the code coverage of the test cases. Taking these factors into consideration, the authors of the paper opted to pursue a static solution for achieving the goals set out for SyncFinder. SyncFinder uses the LLVM compiler infrastructure.

1. Find Loops

An important commonality between all ad hoc synchronizations is that they are all caused by loops, be they “for”, “while” or “go to” loops. These are generally referred to as "sync loops". The first step in identifying sync loops is The LLVM infrastructure is used to obtain the loop info from the source including a representation of the exit conditions.

2. Identify Sync Loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

After the initial set of loops found is culled through the above process, the remaining loops are determined to be sync loops, and are suitably annotated. Marking the source code with LLVM’s static instrumentation framework, it allows for other tools to take advantage of SyncFinder’s findings in their own analysis.

====Uses====
SyncFinder is a robust tool that can be utilized in a variety of applications such as bug detection, performance profiling and concurrency testing. Using its auto-annotation feature, it is capable of identifying sections of code that demonstrate bad programming practices, which could in turn cause issues such as deadlocks. In addition to this, the authors of the paper were able to expand upon the existing data race detector “Valgrind” in order to take advantage of the annotation system introduced by SyncFinder. Through this, they were able to reduce the number of false positives flagged by the former, while being able to make use of the information it provides.

====Accuracy====
SyncFinder was tested against 25 concurrent programs that are used across a broad cross-section of application. In testing SyncFinder was able to positively identify 96% of ad hoc synchronizations within the tested programs. False positives were at a rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases
Dynamic would potentially make it language agnostic.

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

This paper successfully identifies a new type programming construct ad hoc synchronization. The paper then refers to a body of data that the authors have created that both provides proof of the criteria to identify the construct and illustrates it's frequency and likelihood to introduce bugs. Previous to SyncFinder, debugging tools have for the most part failed to detect ad hoc synchronizations effectively. Because of this, SyncFinder has been shown to be an important tool for future development of software.

As far as shortcomings go, it has a 96% success rate, with 6% false positives. The 6% false positive rate is more or less unavoidable, so it is hard to fault the tool for that, especially with such a high success rate. Even with a 6% false positive rate, the developer still only needs to look through a select few loops to determine which are actually ad hoc synchronizations as opposed to a whole code base.

Finally the tool that the authors have created has been used on ubiquitous applications[[#Foot10|10]] like Apache and exposed previously unreported bugs. This stands as a testament to both it's effectiveness and validity.

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Park, Lu and Zhou, 2009. CTrigger: Exposing Atomicity Violation Bugs from Their Hiding Places. [online] University of Illinois at Urbana Champaign, Urbana, Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Z Li, L Tan, X Wang, S Lu, Y Zhou, 2006. Have things changed now?: an empirical study of bug characteristics in modern open source software. Proc. of 1st Workshop on Architectural and System Support for Improving Software Dependability p.25-33 Available through CiteSeerX: <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.6982> [Accessed 23 November 2010].

7 Lu, Park, Seo and Zhou, 2010. Learning from Mistakes A Comprehensive Study on Real
World Concurrency Bug Characteristics. [online] University of Illinois at Urbana Champaign, Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

8 John H. Baldwin , 2002. Locking in the Multithreaded FreeBSD Kernel. [online] FreeBSD Available at: <http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html> [Accessed 23 November 2010].

9 Soma-notes, 2010. Basic Synchronization Principles. [online] Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

10 BuiltWith, 2010. Apache Usage Statistics. [online] Available at: <http://trends.builtwith.com/Web-Server/Apache> [Accessed 30 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-12-01T08:14:15Z

Mkugler: /* Uses */

==Paper==
===[http://homeostasis.scs.carleton.ca/wiki/index.php/COMP_3000_Essay_2_2010_Question_7 Ad Hoc Synchronization Considered Harmful]===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel

==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

The paper we are discussing addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==

===Concurrent Programming===
Concurrent programming is a style of programming where multiple threads of execution run concurrently to perform a single task. The thread of execution share a number of resources. Particularly in multi-core processor system and in distributed environment this style of programming can result in significant performance gains. One significant challenge of concurrent programming is coordinating the different threads of execution, this is usually done using synchronization primitives.

===Synchronization Primitives===
Synchronization primitives represent some of the basic tools offered by the system containing the concurrent program to facilitate coordination between of threads of execution. They are generally used to synchronize between threads, and to protect shared resource[[#Foot8|8]].
Some type of synchronization primitives common to many are locks, mutexes, semaphores, and monitors.
Locks are really a superset of synchronization primitives since mutexes, semaphores, and monitors are all locks. Additionally there are read/write locks that only lock when a reader obtains the lock. Latches a type of lock that unlocks when a specified number of threads have obtained it which is very useful in facilitate threads all getting to known state, there are a myriad of other locks.
Mutexes are mutually exclusive locks that threads employ to lock a resource that they need preventing other. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Monitors are a type of mutex that contain a condition variables which is a variable that if not true, releases the lock and blocks the thread until the certain condition is met, by another thread changing value of the variable. This allows the original thread to only continue execute when it is safe to perform its operation.
Synchronization primitives can be misused and lead to a host of other problems generally referred to collectively as race conditions.
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronization is required to ensure that the executing tasks do not interfere with each other avoiding potential race conditions. However, many programmers do not use proper synchronization primitives to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. The paper we are discussing shows that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this programming construct and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* [working on it]

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization.

====How it works====
There are two possibilities to consider when searching for ad hoc synchronizations. You can either analyze runtime traces via a dynamic method, or analyze the source code in a static method. Both methods carry with them a number of pros and cons. While a dynamic process is generally more accurate than a static method, it tends to accrue a very large runtime overhead. In addition to this, the dynamic method is somewhat limited in which ad hoc synchronizations it can find by the code coverage of the test cases. Taking these factors into consideration, the authors of the paper opted to pursue a static solution for achieving the goals set out for SyncFinder. SyncFinder uses the LLVM compiler infrastructure.

1. Find Loops

An important commonality between all ad hoc synchronizations is that they are all caused by loops, be they “for”, “while” or “go to” loops. These are generally referred to as "sync loops". The first step in identifying sync loops is The LLVM infrastructure is used to obtain the loop info from the source including a representation of the exit conditions.

2. Identify Sync Loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

Finally, SyncFinder annotates these ad hoc synchronizations in a specific way so that other tools are able to find them.

====Uses====
SyncFinder is a robust tool that can be utilized in a variety of applications such as bug detection, performance profiling and concurrency testing. Using its auto-annotation feature, it is capable of identifying sections of code that demonstrate bad programming practices, which could in turn cause issues such as deadlocks. In addition to this, the authors of the paper were able to expand upon the existing data race detector “Valgrind” in order to take advantage of the annotation system introduced by SyncFinder. Through this, they were able to reduce the number of false positives flagged by the former, while being able to make use of the information it provides.

====Accuracy====
SyncFinder was tested against 25 concurrent programs that are used across a broad cross-section of application. In testing SyncFinder was able to positively identify 96% of ad hoc synchronizations within the tested programs. False positives were at a rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases
Dynamic would potentially make it language agnostic.

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

This paper successfully identifies a new type programming construct ad hoc synchronization. The paper then refers to a body of data that the authors have created that both provides proof of the criteria to identify the construct and illustrates it's frequency and likelihood to introduce bugs. Previous to SyncFinder, debugging tools have for the most part failed to detect ad hoc synchronizations effectively. Because of this, SyncFinder has been shown to be an important tool for future development of software.

As far as shortcomings go, it has a 96% success rate, with 6% false positives. The 6% false positive rate is more or less unavoidable, so it is hard to fault the tool for that, especially with such a high success rate. Even with a 6% false positive rate, the developer still only needs to look through a select few loops to determine which are actually ad hoc synchronizations as opposed to a whole code base.

Finally the tool that the authors have created has been used on ubiquitous applications[[#Foot10|10]] like Apache and exposed previously unreported bugs. This stands as a testament to both it's effectiveness and validity.

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

10 Author, 2010. Title. [online] Company(optional) Available at: <http://trends.builtwith.com/Web-Server/Apache> [Accessed 30 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-12-01T07:22:21Z

Mkugler: /* How it works */

==Paper==
===[http://homeostasis.scs.carleton.ca/wiki/index.php/COMP_3000_Essay_2_2010_Question_7 Ad Hoc Synchronization Considered Harmful]===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel

==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

The paper we are discussing addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==

===Concurrent Programming===
Concurrent programming is a style of programming where multiple threads of execution run concurrently to perform a single task. The thread of execution share a number of resources. Particularly in multi-core processor system and in distributed environment this style of programming can result in significant performance gains. One significant challenge of concurrent programming is coordinating the different threads of execution, this is usually done using synchronization primitives.

===Synchronization Primitives===
Synchronization primitives represent some of the basic tools offered by the system containing the concurrent program to facilitate coordination between of threads of execution. They are generally used to synchronize between threads, and to protect shared resource[[#Foot8|8]].
Some type of synchronization primitives common to many are locks, mutexes, semaphores, and monitors.
Locks are really a superset of synchronization primitives since mutexes, semaphores, and monitors are all locks. Additionally there are read/write locks that only lock when a reader obtains the lock. Latches a type of lock that unlocks when a specified number of threads have obtained it which is very useful in facilitate threads all getting to known state, there are a myriad of other locks.
Mutexes are mutually exclusive locks that threads employ to lock a resource that they need preventing other. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Monitors are a type of mutex that contain a condition variables which is a variable that if not true, releases the lock and blocks the thread until the certain condition is met, by another thread changing value of the variable. This allows the original thread to only continue execute when it is safe to perform its operation.
Synchronization primitives can be misused and lead to a host of other problems generally referred to collectively as race conditions.
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronization is required to ensure that the executing tasks do not interfere with each other avoiding potential race conditions. However, many programmers do not use proper synchronization primitives to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. The paper we are discussing shows that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this programming construct and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* [working on it]

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization.

====How it works====
There are two possibilities to consider when searching for ad hoc synchronizations. You can either analyze runtime traces via a dynamic method, or analyze the source code in a static method. Both methods carry with them a number of pros and cons. While a dynamic process is generally more accurate than a static method, it tends to accrue a very large runtime overhead. In addition to this, the dynamic method is somewhat limited in which ad hoc synchronizations it can find by the code coverage of the test cases. Taking these factors into consideration, the authors of the paper opted to pursue a static solution for achieving the goals set out for SyncFinder. SyncFinder uses the LLVM compiler infrastructure.

1. Find Loops

An important commonality between all ad hoc synchronizations is that they are all caused by loops, be they “for”, “while” or “go to” loops. These are generally referred to as "sync loops". The first step in identifying sync loops is The LLVM infrastructure is used to obtain the loop info from the source including a representation of the exit conditions.

2. Identify Sync Loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

Finally, SyncFinder annotates these ad hoc synchronizations in a specific way so that other tools are able to find them.

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====
SyncFinder was tested against 25 concurrent programs that are used across a broad cross-section of application. In testing SyncFinder was able to positively identify 96% of ad hoc synchronizations within the tested programs. False positives were at a rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases
Dynamic would potentially make it language agnostic.

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

This paper successfully identifies a new type programming construct ad hoc synchronization. The paper then refers to a body of data that the authors have created that both provides proof of the criteria to identify the construct and illustrates it's frequency and likelihood to introduce bugs. Previous to SyncFinder, debugging tools have for the most part failed to detect ad hoc synchronizations effectively. Because of this, SyncFinder has been shown to be an important tool for future development of software.

As far as shortcomings go, it has a 96% success rate, with 6% false positives. The 6% false positive rate is more or less unavoidable, so it is hard to fault the tool for that, especially with such a high success rate. Even with a 6% false positive rate, the developer still only needs to look through a select few loops to determine which are actually ad hoc synchronizations as opposed to a whole code base.

Finally the tool that the authors have created has been used on ubiquitous applications[[#Foot10|10]] like Apache and exposed previously unreported bugs. This stands as a testament to both it's effectiveness and validity.

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

10 Author, 2010. Title. [online] Company(optional) Available at: <http://trends.builtwith.com/Web-Server/Apache> [Accessed 30 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-30T13:33:43Z

Mkugler: /* How it works */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronizations are required to ensure that the executing tasks do not interfere with each other, which could be disastrous for the system. However, many programmers do not use proper synchronization techniques to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. In this study, it is shown that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this implementation and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* [working on it]

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization. It has been tested to be able to positively identify 96% of ad hoc synchronizations within 25 concurrent programs, with a false positive rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====How it works====
There are two possibilities to consider when searching for ad hoc synchronizations. You can either analyze runtime traces via a dynamic method, or analyze the source code in a static method. Both methods carry with them a number of pros and cons. While a dynamic process is generally more accurate than a static method, it tends to accrue a very large runtime overhead. In addition to this, the dynamic method is somewhat limited in which ad hoc synchronizations it can find by the code coverage of the test cases. Taking these factors into consideration, the authors of the paper opted to pursue a static solution for achieving the goals set out for SyncFinder.

1. Find Loops

All ad hoc synchronizations are done using either a "while", "for", or "goto" loop. Therefore, the first step in identifying ad hoc synchronizations is to identify each loop within the code and extract its exit conditions.

2. Identify Sync Loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

Finally, SyncFinder annotates these ad hoc synchronizations in a specific way so that other tools are able to find them.

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

This paper has shown that ad hoc synchronizations are commonplace in programs that run in concurrency. The bad part of this is that ad hoc synchronizations are error prone. Previous to SyncFinder, debugging tools have for the most part failed to detect ad hoc synchronizations effectively. Because of this, SyncFinder has been shown to be an important tool for future development of software.

As far as shortcomings go, it has a 96% success rate, with 6% false positives. The 6% false positive rate is more or less unavoidable, so it is hard to fault the tool for that, especially with such a high success rate. Even with a 6% false positive rate, the developer still only needs to look through a select few loops to determine which are actually ad hoc synchronizations as opposed to a whole code base.

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-30T10:17:54Z

Mkugler: /* How it works */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronizations are required to ensure that the executing tasks do not interfere with each other, which could be disastrous for the system. However, many programmers do not use proper synchronization techniques to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. In this study, it is shown that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this implementation and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* [working on it]

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization. It has been tested to be able to positively identify 96% of ad hoc synchronizations within 25 concurrent programs, with a false positive rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====How it works====
SyncFinder analyzes the source code statically as opposed to at runtime dynamically. While it would be more effective in identifying ad hoc synchronization at runtime, it would cause unnecessary overhead, and it wouldn't be guaranteed that the test cases would cover all code that could have sync loops. For this reason, SyncFinder is run statically.

1. Find Loops

All ad hoc synchronizations are done using either a "while", "for", or "goto" loop. Therefore, the first step in identifying ad hoc synchronizations is to identify each loop within the code and extract its exit conditions.

2. Identify Sync Loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

Finally, SyncFinder annotates these ad hoc synchronizations in a specific way so that other tools are able to find them.

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-30T09:06:00Z

Mkugler: /* How it works */

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronizations are required to ensure that the executing tasks do not interfere with each other, which could be disastrous for the system. However, many programmers do not use proper synchronization techniques to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. In this study, it is shown that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this implementation and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* [working on it]

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization. It has been tested to be able to positively identify 96% of ad hoc synchronizations within 25 concurrent programs, with a false positive rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====How it works====
SyncFinder analyzes the source code statically as opposed to at runtime dynamically. While it would be more effective in identifying ad hoc synchronization at runtime, it would cause unnecessary overhead, and it wouldn't be guaranteed that the test cases would cover all code that could have sync loops. For this reason, SyncFinder is run statically.

1. Find Loops

All ad hoc synchronizations are done using either a "while", "for", or "goto" loop. Therefore, the first step in identifying ad hoc synchronizations is to identify each loop within the code and extract its exit conditions.

2. Identify Sync Loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
#* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
#* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
#* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

Finally, SyncFinder annotates these ad hoc synchronizations in a specific way so that other tools are able to find them.

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

COMP 3000 Essay 2 2010 Question 7

2010-11-30T09:01:26Z

Mkugler: /* SyncFinder */ Expanded on introduction

==Paper==
===Ad Hoc Synchronization Considered Harmful===
Weiwei Xiong
University of California, San Diego

Soyeon Park, Jiaqi Zhang, Yuanyuan Zhou
University of Illinois at Urbana-Champaign

Zhiqiang Ma
Intel
==Research Problem==
As the computer industry continues to shift towards multicore processors, concurrent programming and the use of multithreaded designs has increased to keep up with this growing trend. Multithreaded applications can be found in a variety of popular applications today as they take advantage of the multithreaded approach. However, the concepts behind concurrent programming bring with them a host of potential dangers in the form of race conditions and deadlocks resulting from bad programming design and threads accessing shared memory. Fortunately, there are well known and standard methods for dealing with these problems, i.e synchronization primitives. But in real world situations, due to a variety of reasons, as we shall see, programmers often implement their own "ad hoc" synchronizations that eschew common design standards. Ad hoc synchronizations are not well documented and are not discovered by traditional tools for race conditions that look for standard synchronization primitives.

This paper addresses these concerns in two regards, first it details a thorough study of ad hoc synchronizations. It details their nature, dangers, impact on bug detection tools and prevalence in several major open-source applications. Secondly, it introduces SyncFinder, a program that detects all ad hoc synchronizations and automatically annotates the source code where ad hoc sychnronizations are found. This can see use in conjunction with other data race checkers to improve accuracy and to build custom tools for finding deadlocks and bad programming practices.

With detailed analysis of ad hoc synchronization and study of their occurrences in several applications, the research ultimately concludes that they are harmful and should be removed. At the same time, SyncFinder detects and documents ad hoc synchronizations in the source code enabling programmers for the first time to easily track and remove them.

==Background Concepts==
===Race conditions, deadlocks===
Race conditions are an unintended side-effects of programming in concurrent systems, they occur when two or more processes have access to a shared resource and at least one of them have write privilege. This leads to processes modifying the data that all processes share as other may be reading them and results in the reading of stale/incorrect data. They will occur during the execution of the program and often times very difficult to detect or manipulate data in subtle ways.

Deadlock is when two or more processes share a resource and each process is waiting on the other processes to unlock the resource. It becomes a circular chain and no process can continue.

Both these issues occur in concurrent programming and although there are no general solutions for deadlock[[#Foot9|9]], there are suitable methods for dealing with them, and in the case of race conditions, using mutual exclusion locks and synchronization primitives can prevent race conditions. But no programmer is infallible and so there is always the issue of race conditions and deadlocks present in production code.
===Ad Hoc Synchronization===
Ad hoc synchronizations are loops called sync loops that continue until certain conditions are met via outside variables called sync variables. They are designed to control the flow of thread execution much like locking and unlocking of resources. There can be multiple sync variables in a sync loop and they can have multiple exit conditions and dependencies. The diversity of the sync loops, their dependencies and execution paths leads to difficulty in finding them.
===Synchronization primitives===
Synchronization variables act as barriers to memory that prevent threads from accessing the same shared resource concurrently[[#Foot8|8]]. They come in many forms such as mutexes and condition variables.
Mutexes are mutual exclusive locks that threads employ to lock a resource that they need. No other threads can access them at that point. Once they are finished, they release the lock and the other threads can then lock and access the resource.
Condition variables are variables that will block the thread until a certain condition is met. This allows the thread to only execute when it is safe to perform its operation.

==Contribution==

With concurrent programming commonly used in modern applications, we face many issues that result from having simultaneous execution. In order to maintain a concurrent system, synchronizations are required to ensure that the executing tasks do not interfere with each other, which could be disastrous for the system. However, many programmers do not use proper synchronization techniques to deal with these issues. Rather, they implement synchronizations in an ad hoc fashion. In this study, it is shown that ad hoc synchronizations, though implemented as a solution to concurrency issues, are indeed undesirable in a system. This paper details the characteristics of ad hoc synchronizations and the issues associated with this implementation and introduces the program, SyncFinder, which is used to identify such synchronizations in code.

===Findings===

In order to identify the characteristics of ad hoc synchronizations, 12 mainstream programs were examined to find instances of ad hoc synchronizations. These programs were either of server, desktop or scientific type, including Apache, MySQL and Mozilla. Through manual inspection of the source code, these characteristics of ad hoc synchronizations were found.

1. In all programs studied, it was found that each had numerous ad hoc synchronizations implemented. The number of synchronizations found ranged from 6-83, with server type programs inhabiting the higher portion of the interval. It is likely that programmers use this type of synchronization for two reasons.
* In order to ensure a certain order of execution in the case of a concurrent system, programmers will use ad hoc synchronization to superimpose this order. With traditional synchronization techniques, this can vary between systems. As the order can vary, it is difficult to create a common interface.
* Some synchronization techniques introduce heavy-weight synchronization primitives. As such, programmers will use ad hoc synchronizations to avoid this and supposedly protect performance.

2. Often, it is very hard to identify an ad hoc loop as a synchronization method. They are hard to distinguish from other computational loops and as the implementations are diverse, it is hard to pinpoint them from the code. This makes the system hard to maintain, as other programmers will not be able to identify ad hoc loops implemented by another and debugging programs cannot recognize them as issues.

3. It was found that ad hoc synchronizations often introduce bugs into the system such as deadlocks or hangs. As these are different than those caused by locks and other synchronizations it is hard for detection tools to recognize them if they were not first identified either manually or automatically.

4. As they are not easily recognizable, it is hard for bug detection tools to fix issues presented by ad hoc synchronizations. In fact, it is often the case that these tools either do not find these issues or report them as false positives as the tool is unaware of the "work arounds" put into affect by using ad hoc synchronization. Since they cannot find these problems, it severely impacts the effectiveness of such tools.
This also impacts analysis of performance. Synchronization is quite costly and if a tool cannot recognize the formm of synchronization, a false report is generated and the programmer will not be aware. This may cause poor decisions on the part of the programmer just from the fact that ad hoc synchronizations are hard to identify.

5. The reason ad hoc synchronizations are hard to identify stems from the fact that there is no single way of implementing it. The ways in which ad hoc synchronizations are done are quite diverse and so it is hard to identify just on a few criteria. Some typical characteristics of an ad hoc synchronization follow.
* These loops can contain one or multiple exit conditions. Some or all of these exit conditions may be satisfied by remote threads while others may be satisfied locally.
* [working on it]

Reasons behind why people use ad hoc synchronization and possible improvements over them ie Synchronization primitives

===SyncFinder===
SyncFinder is a tool built and designed by the authors of the paper for the purpose of identifying and annotating instances of ad hoc synchronization in concurrent programs built in C or C++. The main goal of this was to aid programmers in better structuring their code, while simultaneously allowing for other tools to be utilized, recognizing them as synchronizations. It has demonstrated itself to be very effective in this area where other similar tools have failed, as it analyzes the code in a unique way that specifically tracks down sync loops that implement ad hoc synchronization. It has been tested to be able to positively identify 96% of ad hoc synchronizations within 25 concurrent programs, with a false positive rate of only 6%. In further tests, they were able to utilize SyncFinder’s auto-annotation systems to locate and mark 5 deadlocks and 16 potential issues within Apache, MySQL and Mozilla, that had previously been missed by other analysis tools.

====How it works====
SyncFinder analyzes the source code statically as opposed to at runtime dynamically. While it would be more effective in identifying ad hoc synchronization at runtime, it would cause unnecessary overhead, and it wouldn't be guaranteed that the test cases would cover all code that could have sync loops. For this reason, SyncFinder is run statically.

1. find loops

All ad hoc synchronizations are done using either a "while", "for", or "goto" loop. Therefore, the first step in identifying ad hoc synchronizations is to identify each loop within the code and extract its exit conditions.

2. identify sync loops

The next and most important step is to differentiate between sync loops used for ad hoc synchronization and regular computational loops. It does this by going through the following steps:
#* Exit Dependent Variable (EDV) Analysis: EDVs are variables that affect the exit conditions of a loop. A sync variable is a variable related to the synchronization of concurrent programs. Therefore, by identifying any EDVs as sync variables, it can be concluded that the loop is a sync loop.
#* Pruning Computational Loops: If a loop has at least one sync condition, it is considered a sync loop. Otherwise, it is pruned out as a computational loop.
#* Pruning Condvar Loops: condvar loops are not considered sync loops. SyncFinder will go through all loop candidates and prune out any that make a calls cond_wait inside the loop.

3. Synchronization Pairing

The next step is to find the remote update that would release the sync loop. SyncFinder first finds all write instructions that would modify the sync variables. It then decides if the value that the write assigns to the sync variable would satisfy the exit condition. All those that do not are pruned. SyncFinder also prunes pairings that do not execute concurrently. This is done conservatively due to the limitations of static analysis.

4. SyncFinder Annotation

Finally, SyncFinder annotates these ad hoc synchronizations in a specific way so that other tools are able to find them.

====Uses====
1. A tool to detect bad practices

2. Extensions to data race detection

====Accuracy====

====Related Work and similar tools====
There has been attempts to remove synchronization issues entirely from concurrent programming, such as transactional memory[[#Foot1|1]], a lock-free synchronization that does not require mutexes, and avoids having to use lock, unlock operations. Other attempts have been made to remove bugs that would otherwise be safe from data races but are are still at risk of unintended effects from thread interactions, such as Atomizer[[#Foot2|2]], a dynamic atomicity checker.

There are tools that detect data races such as CHESS[[#Foot3|3]], a dynamic data race checker that runs through all possible thread execution paths and CTrigger[[#Foot4|4]], a tool that checks for atomicity violations. The problem with these programs is that they only look for standard synchronization methods and structures, such as lock() and cond_wait(). They are not looking for ad hoc synchronizations.

A similar tool to SyncFinder exists that can detect simple spinning, also an ad hoc synchronization[[#Foot5|5]], but it only detects simple spinning and not the more complicated ad hoc variations.

Several studies on bug characteristics[[#Foot6|6]] and concurrency bugs[[#Foot7|7]] have been composed. This paper complements these studies to better understand the nature of ad hoc synchronizations and their occurrence in concurrent programs.

==Critique==
1. Uses static approach, dynamic would be better
* As stated in the paper, dynamic introduces run-time overhead and is not guaranteed to find if not executed in the test cases

2. not entirely accurate, some false positives.

3. In terms of style, lots of unnecessary repetition

==References==
1 M Herlihy and J.E.B. Moss, 2NA0. Transactional Memory:
Architectural Support for Lock-Free Data Structures. [online] Available at: <http://www.cs.brown.edu/~mph/HerlihyM93/herlihy93transactional.pdf> [Accessed 23 November 2010].

2 C Flanagan and S N Freund, 2NA0. Atomizer: A Dynamic Atomicity Checker For Multithreaded Programs (Summary). [online] Company(optional) Available at: <http://www.cs.williams.edu/~freund/papers/atomizer-padtad.pdf> [Accessed 23 November 2010].

3 T Ball,M Musuvathi and S Qadeer, 2NA0. CHESS: A Systematic Testing Tool for Concurrent. [online] Company(optional) Available at: <http://research.microsoft.com/pubs/70509/tr-2007-149.pdf> [Accessed 23 November 2010].

4 Author, 2NA0. Title. [online] Company(optional) Available at: <http://pages.cs.wisc.edu/~shanlu/paper/asplos092-zhou.pdf> [Accessed 23 November 2010].

5 LI, T., LEBECK, A. R., AND SORIN, D. J. Spin detection hardware for improved management of multithreaded systems. IEEE Transactions on Parallel and Distributed Systems PDS-17, 6 (June 2006), 508–521.

6 Author, 2NA0. Title. [online] Company(optional) Available at: <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf> [Accessed 23 November 2010].

7 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.1203&rep=rep1&type=pdf]> [Accessed 23 November 2010].

8 Author, 2NA0. Title. [online] Company(optional) Available at: <[http://www.usenix.org/events/bsdcon/full_papers/baldwin/baldwin_html/node5.html]> [Accessed 23 November 2010].

9 Author, 2010. Title. [online] Company(optional) Available at: <http://homeostasis.scs.carleton.ca/wiki/index.php/Basic_Synchronization_Principles> [Accessed 23 November 2010].

Talk:COMP 3000 Essay 2 2010 Question 7

2010-11-30T02:50:05Z

Mkugler:

'''Attendence. Please mark your name to say you're here'''

Stephany Lay --[[User:Slay|Slay]] 19:45, 15 November 2010 (UTC)

--[[User:Asoknack|Asoknack]] 16:00, 15 November 2010 (UTC)

--[[User:Smcilroy|Smcilroy]] 18:43, 15 November 2010 (UTC)

Lester Mundt
--[[User:Lmundt|Lmundt]] 18:58, 15 November 2010 (UTC)

Thomas McMahon
--[[User:cha0s|cha0s]]

Martin Kugler
--[[User:Mkugler|Mkugler]] 02:42, 18 November 2010 (UTC)

So only 2 days left before it's due! I'd like to hear what others are planning on contributing and when, since only myself and Slay have done any work on the actual essay. It would be nice to hear from you guys, even if its to say that your busy and are going to work on it on Thursday etc. etc.--[[User:Smcilroy|Smcilroy]] 22:05, 23 November 2010 (UTC)

So, what's the plan for this? How do we want to do this? Given the duedate looming in 4 days we should probably get talking about it. What are your thoughts?
--[[User:Mkugler|Mkugler]] 23:00, 21 November 2010 (UTC)
::Hey! So I added an intro and it covers the research problem to. I also added a bare bones skeleton of what we'll probably end up talking about. Personally, I think people should choose a couple of subsections and sections that they will work on and just put your name beside it. It seems to work best as people then have a sense of ownership and responsibility to that particular topic and aren't overwhelmed at editing the entire essay, at least for the beginning. That doesn't mean we can't all edit each others work though! I welcome any changes to the intro. Anyways, that's my 2 cents. --[[User:Smcilroy|Smcilroy]] 06:06, 22 November 2010 (UTC)
::As critique is our own opinion, we should discuss our thoughts. Having only one person writing that would not express everyone's opinions. --[[User:Slay|Slay]] 20:48, 22 November 2010 (UTC)

Hey, gonna be fleshing out the Contribution section, probably the stuff under the SyncFinder heading. Just wanted to give people a head's up so we don't waste time all doing the same thing.
--[[User:Mkugler|Mkugler]] 03:09, 24 November 2010 (UTC)

I will do the Findings section for now then. I'm unsure when I'll get to it though. I'll try for this weekend. --[[User:Slay|Slay]] 00:14, 26 November 2010 (UTC)

Not much activity going on. Please at least claim a section to work on so we know it will get covered. I'll continue to work on my part when I get the time. --[[User:Slay|Slay]] 00:28, 28 November 2010 (UTC)

I agree we should all voice our opinions on the critique section everyone could add there own opinion and someone could synthesize it later. --[[User:Lmundt|Lmundt]] 18:06, 28 November 2010 (UTC)

Yo, I'll be doing some contributions tomorrow, adding to the sync finder and critique section. If you guys want to meet up at any point during the week let me know, I'm good for whenever.
--[[User:cha0s|cha0s]] 1:12, 29 November 2010 (EDT)

I'm already working on the SyncFinder section. I'm gonna try to finish it up tonight.
--[[User:Mkugler|Mkugler]] 02:50, 30 November 2010 (UTC)

Talk:COMP 3000 Essay 2 2010 Question 7

2010-11-24T03:09:59Z

Mkugler:

Talk:COMP 3000 Essay 2 2010 Question 7

2010-11-21T23:00:07Z

Mkugler:

Talk:COMP 3000 Essay 2 2010 Question 7

2010-11-18T02:42:30Z

Mkugler:

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:56:44Z

Mkugler: /* Problems */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

It is difficult to accurately discern what if any problems arose within Oberon. It was successfully completed and implemented for use with the Ceres system. Due to the safe nature of the Oberon language which the operating system was built off of, run-time errors within Oberon were minimized. The language itself however did and still does suffer from some flaws in the form of certain safety features commonly implemented in other safe languages being omitted, which can potentially cause problems for developers who are unaware of the absence and are expecting them to be present.

====Current Status====

The original Oberon has ceased further development for a number of years now, but this is not the case for operating systems based around the Oberon language. ETH Zurich has since developed a number of additional systems with the knowledge gained from the first Oberon operating system.

The latest of these is the Bluebottle OS, also known as A2. It is an efficient environment, with multiprocessor support, while retaining the compact size and text-based interface of its predecessor. While the original Oberon was targeted for simply in-house hardware, both the operating system and the language has since been ported to a variety of platforms.

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Oberon:

Bluebottle OS. (n.d.). Retrieved February 3, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Bluebottle_OS

Ceres (workstation). (2010, August 24). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Ceres_(workstation)

Native Oberon. (n.d.). Retrieved March 5, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Native_Oberon

Niklaus Wirth. (2010, October 13). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Niklaus_Wirth

NS320xx. (2010, June 30). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/NS320xx

Oberon (operating system). (2010, September 1). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(operating_system)

Oberon (programming language). (2010, October 3). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(programming_language)

Oberon. (2008, July 10). Retrieved from ETH Zurich: http://www.oberon.ethz.ch/

Wirth, N., & Gutknecht, J. (2005). ETH Oberon. Retrieved from Project Oberon: The Design of an Operating System and Compiler: http://www.oberon.ethz.ch/archives/systemsarchive/sys_genealogy_new

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:56:36Z

Mkugler: /* Oberon */

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:44:00Z

Mkugler: /* Current Status */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

The original Oberon has ceased further development for a number of years now, but this is not the case for operating systems based around the Oberon language. ETH Zurich has since developed a number of additional systems with the knowledge gained from the first Oberon operating system.

The latest of these is the Bluebottle OS, also known as A2. It is an efficient environment, with multiprocessor support, while retaining the compact size and text-based interface of its predecessor. While the original Oberon was targeted for simply in-house hardware, both the operating system and the language has since been ported to a variety of platforms.

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Oberon:

Bluebottle OS. (n.d.). Retrieved February 3, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Bluebottle_OS

Ceres (workstation). (2010, August 24). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Ceres_(workstation)

Native Oberon. (n.d.). Retrieved March 5, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Native_Oberon

Niklaus Wirth. (2010, October 13). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Niklaus_Wirth

NS320xx. (2010, June 30). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/NS320xx

Oberon (operating system). (2010, September 1). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(operating_system)

Oberon (programming language). (2010, October 3). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(programming_language)

Oberon. (2008, July 10). Retrieved from ETH Zurich: http://www.oberon.ethz.ch/

Wirth, N., & Gutknecht, J. (2005). ETH Oberon. Retrieved from Project Oberon: The Design of an Operating System and Compiler: http://www.oberon.ethz.ch/archives/systemsarchive/sys_genealogy_new

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:39:22Z

Mkugler: /* References */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

The original Oberon has ceased further development for a number of years now, but this is not the case for operating systems based around the Oberon language. ETH Zurich has since developed a number of additional systems with the knowledge gained from the first Oberon operating system.

The latest of these is the Bluebottle OS, also known as A2. It is an efficient environment, with multiprocessor support, while retaining the compact size and text-based interface of its predecessor.

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Oberon:

Bluebottle OS. (n.d.). Retrieved February 3, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Bluebottle_OS

Ceres (workstation). (2010, August 24). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Ceres_(workstation)

Native Oberon. (n.d.). Retrieved March 5, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Native_Oberon

Niklaus Wirth. (2010, October 13). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Niklaus_Wirth

NS320xx. (2010, June 30). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/NS320xx

Oberon (operating system). (2010, September 1). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(operating_system)

Oberon (programming language). (2010, October 3). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Oberon_(programming_language)

Oberon. (2008, July 10). Retrieved from ETH Zurich: http://www.oberon.ethz.ch/

Wirth, N., & Gutknecht, J. (2005). ETH Oberon. Retrieved from Project Oberon: The Design of an Operating System and Compiler: http://www.oberon.ethz.ch/archives/systemsarchive/sys_genealogy_new

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:26:37Z

Mkugler: /* Achievements */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

The original Oberon has ceased further development for a number of years now, but this is not the case for operating systems based around the Oberon language. ETH Zurich has since developed a number of additional systems with the knowledge gained from the first Oberon operating system.

The latest of these is the Bluebottle OS, also known as A2. It is an efficient environment, with multiprocessor support, while retaining the compact size and text-based interface of its predecessor.

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:26:24Z

Mkugler: /* Current Status */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

The original Oberon has ceased further development for a number of years now, but this is not the case for operating systems based around the Oberon language. ETH Zurich has since developed a number of additional systems with the knowledge gained from the first Oberon operating system.

The latest of these is the Bluebottle OS, also known as A2. It is an efficient environment, with multiprocessor support, while retaining the compact size and text-based interface of its predecessor.

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:13:46Z

Mkugler: /* Current Status */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:13:38Z

Mkugler: /* Modula-3 Based */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:13:12Z

Mkugler: /* Modula-3 Based */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

----

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

COMP 3000 Essay 1 2010 Question 4

2010-10-15T09:12:48Z

Mkugler: /* Modula-3 Based */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

SPIN operating system came through with positive results, it actually works. Most of the goals set by the creators were accomplished. SPIN overcame the large overhead of microkernels by enforcing the extensions to be run in the kernel’s address space. The number of switches dropped which actually improved efficiency significantly.
By using Modula-3’s safe interfaces, there was no run-time checking of the code of the extensions. This was a huge advantage over languages like C/C++ due to the fact that a significant overhead was cleared from the execution time. SPIN addressed the latency issue by only allowing code with low latency, which is quite small, to access the system through extensions that access the kernel directly. This is another advantage of using a safe programming language.

===Problems===

Two general issues with extendible systems are adaptability and reliability. Using a safe programming language comes with a price. In SPIN, there is a loss of efficiency when the dynamic checks run for array index bounds. These checks also add a significant overhead to the execution time.
SPIN is written with very few Modula-3 code lines and are much easier to understand compared to other operating systems written in C or C++. However, the kernel of the system is almost entirely written in C and Assembly. These two languages are considered unsafe in contrast to Modula-3. The mix of safe and unsafe code is a huge complication which leads to many bugs, which compromises the safe extensions and interfaces used by applications.

===Current Status===

SPIN, and extendible operating systems in general, is becoming the playground for research. The authors of SPIN at the University of Washington are performing projects and continuing the on-going research of improving extendible operating systems. The solutions they might come up with could greatly influence the operating systems as we see them today.

===Oberon===
====Overview====

The notion of creating an operating system that takes advantage of the unique properties of the Modula-3 language was not only investigated by the SPIN team at Washington University. Niklaus Wirth, the creator of the Modula language, along with Jürg Gutknecht investigated the possibility of creating an operating using Modula-2. However, due to limitations in the language, they instead opted to utilize a new language based upon the older Modula-2 one, creating the Oberon language. It is with this that they developed the Oberon operating system, a very simple yet effective system utilizing an unconventional text-based user interface.

====Motivation====

First developed in 1985, Oberon was designed for use on ETH Zurich's NS32032-based Ceres system. It was, at the time, one of the first object-oriented operating systems, utilizing one of the first 32-bit processors on the market. While it was originally planed to be created with the Modula-2 language, it lacked desired safe type-extension facilities, and so the team instead utilized a purpose built language that drew heavily from Modula, which, like the operating system itself, was entitled Oberon.

In addition to being a safer language than its predecessor, Oberon also made use of a garbage collector, and was vastly more streamlined than Modula-2, with the Oberon report being a third of the size of that of its predecessor and a full compiler at only around 4000 lines of code. As a result of the safety facilities in place within the language, the Oberon operating system could be built with significantly lower risk of logical errors and bugs in runtime.

====Achievements====

Perhaps one of the most interesting features of the Oberon operating system can be seen in a particular version entitled Native Oberon. While most versions of Oberon were incredibly compact, to the point of the entire OS, along with an Oberon language compiler an assorted utilities, being able to fit on a single 3.5" floppy disk, Native Oberon was unique in that it could be run directly from the floppy on bare PC hardware.

In addition to this uncommon and convenient feature, Oberon also made use of an unconventional text-based user interface. This system allowed for the point-and-click convenience of a GUI, with the versatility of a command line.

====Problems====

====Current Status====

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set out. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

The Smalltalk world continues to have ripples around the world, though perhaps less than the incredible splash they made in the 1970s.

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

FOR SPIN

B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In the Proceedings of the 15th ACM Symposium on Operating System Principles (SOSP), Copper Mountain, CO, December 1995.

W. C. Hsieh, M. E. Fiuczynski, C. Garrett, S. Savage, D. Becker and B. N. Bershad. Language Support for Extensible Operating Systems. Workshop on Compiler Support for System Software, University of Washington, February 1996.

S. Savage, B. N. Bershad. Issues in the Design of an Extensible Operating System. Proceedings of the First USENIX Symposium on Operatings Systems Design and Implementation (OSDI), November 1994 (Unpublished).

University of Washington, Dept. of Computer Science. The SPIN Operating System. [http://www.cs.washington.edu.html]

For Smalltalk:

Alan Kay, The Early History of Smalltalk [http://www.smalltalk.org/downloads/papers/SmalltalkHistoryHOPL.pdf]

Talk:COMP 3000 Essay 1 2010 Question 4

2010-10-14T04:00:14Z

Mkugler:

== Discussion ==

Information on Oberon well on it's way. Just need to do a bit more to finish it up and will post it tomorrow.

--[[User:Mkugler|Mkugler]] 04:00, 14 October 2010 (UTC)

I believe I finished the SPIN OS section. Let me know how I did and if anything needs to be added or changed. I posted all the papers that I used in the reference section.

--[[User:Ymoussou|Youcef M.]] 02:24, 14 October 2010 (UTC)

We have an extra day! I thought it was due in the morning. The paper is actually written by 2 authors of the system, I wonder why its not published. Thanks for your help.

--[[User:Ymoussou|Youcef M.]] 22:52, 13 October 2010 (UTC)

9 am Friday, since it's due Thursday night. As for the papers, I seem to recall him saying that we should be using published papers, but if it's non-published and by someone who's clearly an expert (instead of some random blogger or something) that it'd be okay. If you're not sure, though, give him a shout; he's pretty quick at responding.

--[[User:ScottG|ScottG]] 22:37, 13 October 2010 (UTC)

Guys, are we allowed to use unpublished papers? there is this paper in the SPIN website that is really helpful. I'm not sure if I'm allowed to use it for our essay, anybody has an idea?

Anil said something about grading the essays around 9 AM (or was it PM?). Was he talking about thursday or friday?

--[[User:Ymoussou|Youcef M.]] 21:57, 13 October 2010 (UTC)

Okay, I've basically got the Lisp section done. Gonna probably go back and tweak it, but at least it's there. And I added in what I used as references in the References section as per MLA style.

I can take a look at writing up something for the C/C++ part as well, just not sure how much I'll be able to get in the time I've got to spare between other courses right now. But I'll certainly try.

--[[User:ScottG|ScottG]] 15:37, 13 October 2010 (UTC)

Could somebody add a bit in the introduction on what it means to be an operating system written in C/C++? One focus should probably be the notion of process as hinted by Anil. There are probably other distinctions that can be dredged up too.

--[[User:Jjpwilso|Jjpwilso]] 02:57, 13 October 2010 (UTC)

Got some stuff up, rough copy only. Meant to get more done, but family stuff came up. More to come tomorrow.

--[[User:ScottG|ScottG]] 02:26, 13 October 2010 (UTC)

Right then, I'm on it.

--[[User:Mkugler|Mkugler]] 01:19, 13 October 2010 (UTC)

Hi MK, and welcome to the group. Anil mentioned Oberon just today, which is apparently another OS based on a cousin of modula-3. If you could find a way to extend the Modula-3 section with Oberon, perhaps with your own subsection (Youcef has already started with a SPIN section) that should help us round things up nicely. Note the goal is to compare capabilities with C/C++, so feel free to take a global view for thematic consistency too. I'll be doing a bit more in this respect on the Smalltalk section. As Anil said in lecture today, it should hold together as an essay even without the wiki-ish headings.

--[[User:Jjpwilso|Jjpwilso]] 01:07, 13 October 2010 (UTC)

Hey guys. I'm a bit late to the punch on this as I've been preoccupied with a ton of other stuff. I've read through what you've all done thus far and frankly think it's phenomenal, which brings me to my quandry. I wasn't here when you all laid claim to the various components of the essay and am not entirely certain where my efforts should be directed. I noticed that LISP so far is empty, but that it was claimed by ScottG on the 8th.

Is there anywhere in particular where you would like me to work? I'm committed to spending the better part of the next 48 hours entirely on this, so I can put together anything remaining that's needed. If you guys can't get back to me, I'll just expand on whatever I can find more information on.

--[[User:Mkugler|Mkugler]] 23:16, 12 October 2010 (UTC)

The SPIN work is looking good Youcef. Note: please try to put links to your sources in the text so we can see where your ideas are coming from.

--[[User:Jjpwilso|Jjpwilso]] 20:45, 12 October 2010 (UTC)

Anil gave me another clue into how he was thinking of comparisons between these OSes and C/C++. For Smalltalk at least the central theme mentions nothing about processes. Smalltalk is about objects, methods, and messages rather than the traditional C notion of processes manipulating data. This distinction or something similar to it may be useful when looking at other operating systems we're exploring.

--[[User:Jjpwilso|Jjpwilso]] 20:42, 12 October 2010 (UTC)

I've got some small amount of comparison in mine (haven't posted it, since I'm still trying to compile info on MIT's Lisp Machine, but will likely have most of it up tonight), but I would think it would be easier to perhaps do some small comparisons in the individual sections -- I'll be pointing out some differences in Genera and C++ OS's in OO memory, for example -- and then make some more broad strokes in the conclusion encompassing two or more of our chosen OS's and C/C++.

--[[User:ScottG|ScottG]] 19:19, 12 October 2010 (UTC)

Hi all. I'm gradually posting the sections that I finished so far I'd love to hear your thoughts and comments.

Anil also mentioned an important note on our question, we have to compare these operating systems to the ones developed using C and C++. Are we going to do that in the conclusion section? because so far we are not answering the second half of the question.

As for the Oberon, I just did a quick read in Wiki and it says that its written in oberon programming language. But it says its based on a modified version of Modula-2 and they don't mention modula-3, can we still talk about this OS? I cant really start on that today I have a chemistery midterm tomorrow morning, and tomorrow I'm going to finish the rest of SPIN sections.

--[[User:Ymoussou|Youcef M.]] 19:00, 12 October 2010 (UTC)

Thanks for the link Anil! For the group: I asked Anil a couple of questions after class today, and another OS he had in mind was [http://en.wikipedia.org/wiki/Oberon_(operating_system) Oberon], invented by the creator of Modula-3. I don't know if there's more to find about this than there is about SPIN but I've got my hands full for now.

--[[User:Jjpwilso|Jjpwilso]] 18:29, 12 October 2010 (UTC)

Rather than Squeak I was thinking about Smalltalk-80. Here's a [http://portal.acm.org/citation.cfm?id=273&dl=GUIDE,ACM book on Smalltalk] that's available online in the ACM digital library. Just the preface should tell you everything you need to know. [[User:Soma|Anil]] 03:15, 12 October 2010 (UTC)

Great work on the Java section. I might toss in a bit on the problems section about cross-platform compatibility once I get done with my part.

--[[User:Jjpwilso|Jjpwilso]] 23:57, 10 October 2010 (UTC)

I've posted what I have written so far for the Java section, if anyone has any suggestion/corrections feel free to post them.
EDIT: I've added the other sections of the Java based operating system.

--[[User:Selliot3|Selliot3]] 16:50, 10 October 2010 (UTC)

Re: Motivation. I had Smalltalk in mind when I roughed out the headings and it's pretty much what you suggested. But the headings are only a guideline. If you prefer a different structure for your sections feel free to improvise. As for format I am assuming an essay style.

Re: SPIN. The ACM site has some stuff. You'll need your student card handy to get through the Carleton Library proxy.

Here are a couple of links (you can find a TON more if you search for SPIN at the top of the portal):

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380940&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Distributed LTL model-checking in SPIN]

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380935&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Using SPIN for feature interaction analysis—a case study]

--[[User:Jjpwilso|Jjpwilso]] 16:25, 10 October 2010 (UTC)

This is all I could find on SPIN

SPIN-An extensible microkernel for application-specific operating system devices [http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA293537]

Extensibility, Safety and Performance in the SPIN Operating System [http://cseweb.ucsd.edu/~savage/papers/Sosp95.pdf]

SPIN-Operating System [http://cs-pub.bu.edu/fac/richwest/cs591_w1/notes/spin.pdf]

Lecture 9: SPIN operating system [http://www.youtube.com/watch?v=YE9uztJ_CFg]

--[[User:Ymoussou|Youcef M.]] 16:06, 10 October 2010 (UTC)

What is meant by "Motivation"? Would that be motivation to use the language for an operating system? Also, what format should we be doing this in? I'm pretty much writing in an essay style for the overview to explain all of the operating systems in Java with an introduction and a paragraph for each of the systems. Then, I would fill out a paragraph or two for Motivation, Problems, etc. Does that seem fine?

--[[User:Selliot3|Selliot3]] 15:13, 10 October 2010 (UTC)

Here's a link to the main [http://www-spin.cs.washington.edu/ SPIN website].

--[[User:Jjpwilso|Jjpwilso]] 16:40, 9 October 2010 (UTC)

I'll start right away, but the reference link doesn't work...

--Youcef M. 15:06, 9 October 2010 (UTC)

Welcome, Youcef. It would probably be best if you focused on one operating system for now. Nobody has claimed SPIN yet, the OS in Modula-3. Do you think you could dig into that? There's a good reference below.

--[[User:Jjpwilso|Jjpwilso]] 15:02, 9 October 2010 (UTC)

Hey guys I'm in the group, sorry for not adding something yet. I've been working on a table which has all the operating systems in those languages and comparing them to each other. But it was harder than I thought, I was trying to find where the OS's are similar and where they are different. It got a little bit long and random; I can find a lot of info on one OS but almost none on the other. Do you guys think its worth the trouble to finish it or should just forget about and keep up with you guys?

--Youcef M. 14:41, 9 October 2010 (UTC)

Particular to Squeak: [http://portal.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=263754&type=pdf&coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 Back to the Future - The Story of Squeak, A Practical Smalltalk Written in Itself]

--[[User:Jjpwilso|Jjpwilso]] 13:29, 9 October 2010 (UTC)

From an interview with Alan Kay, founder of Smalltalk, I tracked down a very useful history:
[http://portal.acm.org.proxy.library.carleton.ca/results.cfm?coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 The Early History of Smalltalk]. There happen to be some important foundational points in here (with references) that relate to other systems as well. For instance he explains how LISP was a vital part of how he came to understand the power of languages. Warning: it's quite long and I don't understand half of it.

--[[User:Jjpwilso|Jjpwilso]] 13:02, 9 October 2010 (UTC)

I'd be fine doing LISP, among throwing out anything good for the other languages I happen to come across.

--[[User:ScottG|ScottG]] 21:27, 8 October 2010 (UTC)

Okay, lets all put down our preferences here and set a reasonable deadline of Saturday at 23:59 for a cutoff. Smalltalk would be my top choice. Of course any contributions to any language will be welcome.

--[[User:Jjpwilso|Jjpwilso]] 16:07, 8 October 2010 (UTC)

I would love to do the Java section. I`ve done quite a bit of development on Android and have also read a complete book on how the Android operating system works. Of course, there are other OS`s to look at but I`m a big fan of Android so I`m always happy to write about it haha.

--[[User:Selliot3|Selliot3]] 15:44, 8 October 2010 (UTC)

I recommend we use the habit of putting more recent comments at the top in case this gets to be a longish list. I've gone ahead and stubbed out a proposed structure. Please comment (thumbs up/down). If we all agree we can start dividing up the parts so we don't do the same work. We're lucky as a team to have such a nicely partitioned essay to write!

--[[User:Jjpwilso|Jjpwilso]] 13:23, 8 October 2010 (UTC)

Genera (LISP) - http://en.wikipedia.org/wiki/Genera_(operating_system) <-- only for a reference for now 
SPIN (Modula) - http://www-spin.cs.washington.edu%2Fexternal%2Foverview.html 
Squeak (SmallTalk) - http://en.wikipedia.org/wiki/Squeak <-- only a reference, says it's a programming language but can be used as an OS 
JavaOS (Java) - http://java.sun.com/developer/products/JavaOS/ 

--[[User:Selliot3|Selliot3]] 00:16, 6 October 2010 (UTC) or Charles

Not a great site, but gives a nice breakdown of the main points of Squeak - http://www.visoracle.com/squeak/overview.html 
And a much longer, more in-depth Squeak page - http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html 
A nice breakdown for JavaOS - http://www.operating-system.org/betriebssystem/_english/bs-javaos.htm 
And a very nice PDF for Genera - http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=183015&tag=1 
--[[User:ScottG|ScottG]] 13:08, 6 October 2010 (UTC)

For Java section: [http://developer.android.com/guide/basics/what-is-android.html What is Android] shows the limited role of DVM (Android's JVM). 
--[[User:Jjpwilso|Jjpwilso]] 14:31, 7 October 2010 (UTC)

COMP 3000 Essay 1 2010 Question 4

2010-10-13T23:51:05Z

Mkugler: /* Introduction */

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Team Note (to be removed by delivery date)=

Please use the [[Talk:COMP_3000_Essay_1_2010_Question_4|discussion page]] for any planning and comments.

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

The following is a short list of operating systems written partially or completely with the given language. We will go into more detail in the language-specific sections below.

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS, Oberon
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

* They pulled it off

===Problems===

* Design issues

===Current Status===

* Still under research

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Not only were they in California but they had also just survived the 1960s. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

* Continuing Research
* OLPC

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

COMP 3000 Essay 1 2010 Question 4

2010-10-13T23:50:47Z

Mkugler: /* Introduction */ Added Oberon to list of Modula-3 OSs

=Question=

What "operating systems" have been implemented in the following languages: LISP, Modula-3, Smalltalk, Java? To what extent do these systems match the capabilities of operating systems implemented in C and C++?

=Team Note (to be removed by delivery date)=

Please use the [[Talk:COMP_3000_Essay_1_2010_Question_4|discussion page]] for any planning and comments.

=Answer=

== Introduction ==

Not so long ago people believed the Earth was a flat world at the center of the universe. This essay addresses a more recent falsehood: that all operating systems are written in assembly language and C. It's not surprising that students of computing in this century would genuflect at the academic altars of Kernighan & Ritchie. After all we grew up with our computer worlds already pre-formed into the conceptual continents of Apple OS, UNIX, and Windows. The more historically curious among us are vaguely aware that other island cultures do exist but they represent civilizations defeated in the marketplace. Explorations into these ancient worlds resemble documentaries about archeologists decoding rediscovered languages etched in stone. But scratch the surface of any of our so-called modern operating systems and you'll find echoes of these ancient languages in our own familiar worlds. Ellen Ullman said it best when she wrote, <blockquote>''We build our computer systems like we build our cities: over time, without a plan, on top of ruins.''</blockquote>

In the sections below we present our explorations into a few truly foundational operating systems. We will also see some brand new ones that prove we stand, as one twelfth century scholar put it, [http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants on the shoulders of giants].

The following is a short list of operating systems written partially or completely with the given language. We will go into more detail in the language-specific sections below.

{| class="wikitable" style="text-align:center" border="1"
|+ '''Operating Systems By Language'''
|-
!width="15%"|Language
!width="85%"|OS List
|-
! Lisp
| MIT's Lisp Machines, Genera
|-
! Modula-3
| SPIN OS (Oberon)
|-
! Smalltalk
| Smalltalk-80 on Xerox Alto, Squeak
|-
! Java
| JavaOS, JNode, JX, Android
|}

==Lisp Based==
===Overview===
Lisp is the second oldest programming languages, established in the late 1960's as a list-processing language. It started out being perfect for math but when it came to programming with it, it left a lot to be desired. Since then there have been a number of different versions of it, from the first Lisp – called “pure Lisp” – to Scheme and Common Lisp. Unlike most object-oriented languages which are focused on classes and instances among other things, Lisp was initially focused more on functions, in which functions call other functions, though later versions of Lisp did eventually add in classes and other typical object-oriented features. It was after this that Genera was created, an operating system written entirely in Lisp, and developed from an earlier operating system on MIT's Lisp Machine.

The Lisp Machine project in began in 1974, where Richard Greenblatt and Thomas Knight, programmers at MIT, designed a computer for general use that was designed for a single user, in which the operating system was programmed entirely in Lisp. It was designed to be completely open to the user, so any changes the user wanted to make could be done during run-time. It was also one of the first systems to be programmed in a 32-bit architecture, making it far more versatile than a number of other operating systems at the time. Despite this, however, the first Lisp Machine was quite basic compared to later iterations, namely Genera.

===Motivation===
Genera is an evolution of the initial Lisp Machine operating system, and as such improved upon many of the basic features of the system. Genera was the first object-oriented operating system, making it stand out among the already well-known Lisp Machines, especially given the fact that it isn't a composition of languages like other operating systems – most using the primary language for the operating system and another language, such as assembly, to deal with hardware directly – but written entirely in Lisp – any of five different dialects of the language – including the lowest levels of the operating system that interact with hardware due to its effective lack of a kernel. Not having to deal with a kernel allows Genera to be very powerful and efficient in certain areas, most especially in the most complex applications such as those dealing with intelligent CAD and graphics, though when given very simple, very routine applications or processes it is much less efficient than other operating systems.

===Achievements===
Another primary difference from other operating systems is that Genera is a fully open system like the first Lisp Machines. Having an open system has its positive and negative aspects. Among the foremost positive aspects is that the user is in control and not left to the whims of the operating system as is common in non-open systems – if the user doesn't like how something is happening, they can simply go in and change it from happening that way again – and allows for very quick prototyping, not needing to wait to compile every little change. Also, due to utilizing very lightweight objects and the fact that everything is in a single address space rather than split across multiple spaces greatly increases efficiency, though again mainly in non-simple tasks.

Like operating systems written in C/C++, Genera has multiple inheritance and automatic garbage collection. Unlike C/C++, however, Genera uses object-oriented memory. This gives Genera a very useful feature that many other systems cannot do, which is that, given a memory address, the system is able to provide the start address, size, and the type of object in that memory location, which increases efficiency. Even the way files are accessed is very different from other operating systems, as it uses a generic file access system; in a generic file access system, rather than following a typical structure of keeping the commands needed for local and networked files different, the commands are the same, meaning that the system essentially acts like a file on a system on the other side of the world is a local file.

===Problems===
Not everything is great with an open system, however, as there are definite security concerns: with an open system, the user can change anything, and programs can interact with other programs and change anything, meaning that if a virus were unleashed on a Genera system it could be catastrophic. To counter this problem Genera systems are protected by a very simple method: keeping the physical system itself out of reach of all but authorized users and behind locked doors. To compare to other operating systems, such as those written in C/C++, it is generally less secure because of the open system, though they are both equally at risk when installing software, as both systems are completely open at that specific junction. Genera also has issues with modularity, as it allows for something to be called even when it is not supposed to be able to be called because, as it is an open system, there is nothing really stopping this from happening. Some versions of Genera and Genera applications are also very well-documented and run quite smoothly, but others are poorly documented and run quite slowly as they are built on top of older versions without any real plan beyond adding on an extra feature here or there over and over again.

===Current Status===
Genera and Lisp Machines, while still being used in a select few locations, are not currently being developed, as their time has passed. Their legacy still lives on, however, in the object-oriented operating systems still in use today.

==Modula-3 Based==
===Overview===

An idea came to mind. A question was proposed. Can an operating system have extensibility, safety, and good performance? A group of computer scientists from Washington University took on this question and tried to come up with an answer. That’s how SPIN operating system was created. SPIN is an operating system that blends the user-level with the kernel level. The main feature is that the kernel can be extended using modules that implement interfaces to meet the applications needs to optimise performance and safety. The programming language used is Modula-3, and the reason for using this language is for its type safe properties like interfaces, extension, and its automatic storage management. The operating system sits on the traditional monolithic kernel. This is because the authors of SPIN argue that microkernels are not extendible due to the massive overhead created from switching in and out of the kernel.

===Motivation===

A poorly matched implementation prevents an
application from working well, while a poorly
matched interface prevents it from working at all.

This is the sole purpose for creating SPIN. The team had to meet three important features to make this work, a Flexible kernel with safe extensions and a good overall performance. Operating systems based on C/C++ are too general that handle many applications. Therefore, some programs may fall through the cracks and suffer the lack of safety and performance. The goal for SPIN however, was to create a specialized operating system that can run a range of applications without sacrificing safety or performance. This system would allow the user programs and applications to manipulate and change the system’s interface to load and access the data or memory needed safely and with a good overall performance. This was possible through the type safe extensions of Modula-3. Unlike C/C++, Modula-3 is considered a safe language; it guarantees the protection of the kernel from dangerous extension by forcing them to interact with the kernel through specific interfaces. Furthermore, the extensions are executed in the virtual address space not the user space.

===Achievements===

* They pulled it off

===Problems===

* Design issues

===Current Status===

* Still under research

==Smalltalk Based==
===Overview===

<blockquote>The best way to predict the future is to invent it. -- Alan Kay</blockquote>

If you are reading this paper on a personal computer, and it has a GUI with overlapping windows, desktop icons, and a mouse pointer then you owe a debt to a group of researchers led by Alan Kay at Xerox's Palo Alto Research Center, or Xerox PARC. Many of those ideas had appeared elsewhere in one form or another, but the first time they came together in a demonstrable and portable form was in the early 1970s at Xerox on a machine called the Alto [http://en.wikipedia.org/wiki/Xerox_Alto]. Their example of a working personal computer was to be the inspiration that launched Apple into the history books.

===Motivation===

Searching for operating systems written in Smalltalk is an exercise in recursion. The Smalltalk OS was written in -- what else -- Smalltalk. But Alan Kay's Learning Research Group (LRG) didn't just set out to write a clever new language that could bootstrap its own environment. Not only were they in California but they had also just survived the 1960s. Their goal was to produce an entirely new learning environment to "amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_III.html]

===Achievements===

They did manage to invent new ways of think about computing. Alan Kay coined the term "object-oriented programming". His inspiration had come from notions of objects already well known in LISP but he wasn't shy about giving credit where it was due. Kay believed his knowledge of LISP helped him think more clearly about computer problems. He felt it contained "great thinking patterns" and "deep beauty" and he vowed to preserve these qualities in the language that would become Smalltalk.

But Kay wasn't just interested the symbolic language at the heart of a system. He incorporated recent studies on learning and cognition from such experts such as Maria Montessori, Jean Piaget, and Jerome Bruner in his goal to form a complete vision of the personal computer. For instance, Bruner's research implied that people learn new thoughts in a loose sequence of translations [http://en.wikipedia.org/wiki/Jerome_Bruner]. First there are actions, or ''enactive'' representations which transform into images or ''iconic'' representations, and finally into language or ''symbolic'' representations. We may take it for granted today, but it was human insights such as these that helped Kay form the basis of graphical user interfaces as channels through which we perceive ideas represented in a computer.

Still the language is no small point. The central idea in Smalltalk (and Smalltalk-80 as an example of a whole system) is that "everything is an object". This includes what we already might think of as objects, such as files, forms, and fields but it also includes transformational methods such as actions, behaviors, and calculations. This places it in distinct contrast with operating systems written in C, and even those written in C++. Gone are such notions as ''process'' and ''semaphore''. In their place are ''messages'' between objects and ''events'' to which interested objects may react.

Another difference in Smalltalk from C-based operating systems is the lack of security. The only means Smalltalk has of protecting anything is through the visibility (private or public) of an object's methods and properties. But if you know how to dig through the system you can modify -- and break -- just about everything. This may be offer a sense of freedom to some. In the networked world this seems more than a bit risky. Yes, Smalltalk has networking.

===Problems===

Performance in Smalltalk-80 wasn't what we expect from our machines today. A later version of the system called Squeak made some attempt to address this issue (and that of portability) by writing a C language generator to create its virtual machine. This was reasonably successful, and you can now run Squeak on a number of platforms including stand-alone inside of VirtualBox.

[[File:Squeak-Hello-Carleton.png]]

Most non-programmers don't know much about Smalltalk-80 or Squeak though it's tempting to speculate what might have happened if Xerox had chosen to keep its secrets from Apple and commercialize the Alto. The decision not to commercialize was one that hurt Alan Kay's team, one of whom in fact seized the moment and went to work for Apple. By the mid-seventies Kay wasn't sure they had completely solved the problems for which they had set. In his disillusionment he sought to burn everything and start over. He was concerned he would be fulfilling both claims of Marshall McLuhan, namely that "our tools reshape us" and "inadequate tools ''still'' reshape us", though presumably not always for the better.

===Current Status===

* Continuing Research
* OLPC

==Java Based==
===Overview===

Java is used on a plethora of devices and systems throughout the industry from cell phones to web applets. With Java being a language that creates a virtual machine for each application, one would think that it is already suited to be an operating system in itself but this is not the case. Java is built to run on top of other operating systems such as Microsoft Windows, Mac OS X and Ubuntu Linux rather than being a standalone system. This section will discuss various operating systems that are written in Java such as JavaOS, Android, JNode and JX.

[http://java.sun.com/developer/products/JavaOS/ JavaOS] is Sun Microsystems very own creation. This system runs on different layers to make a scalable and easily updateable operating system [http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. The first layer is the microkernel which handles the memory architecture, booting, interrupt handling, threading, traps and DMA handling. The Java Virtual Machine is also compiled into native code for the system and is run on top of the microkernel. The second layer consists of the JavaOS for Business software which extends the memory module to optimize for systems with limited memory[http://java.sun.com/developer/products/JavaOS/OverView/index.html ]. All device drivers for the system are written and run in Java and are what the third layer is consisted of. Finally, the fourth layer is a stand-alone JDK runtime environment used to run user applications.

[http://www.android.com/ Android] was created by a very ambitious team at Google for use with cell phones. It is basically an operating system running on top of another minimalistic operating system. At the very lowest end of Android, a Linux 2.6 kernel is what powers it. All device drivers are written and compiled for the native hardware or compiled using Google’s Native Development Kit and core system libraries such as libc, OpenGL | ES and SQLite are dynamically linked in per application [http://developer.android.com/guide/basics/what-is-android.html]. In the Android runtime, the Dalvik Virtual Machine (DVM) controls applications similar to the Java Virtual Machine. Dalvik is similar to the aforementioned JavaOS as it relies on the kernel to manage threading and low-level memory management. Running on top of the DVM are core libraries and application frameworks for the Android operating system. These frameworks include resource management, window management, notification manage just to name a few. Applications are then built on top of these frameworks and are the end result in which the user will actually interact with.

[http://www.jnode.org/ JNode] began as the Java Bootable System (JBS) in 1995. Ewout Prangsma, the creator, was unhappy with the amount of native C and assembly used for the system so he began a new project, JNode. JNode only uses a small amount of assembly code for booting the system now compared to the initial JBS [http://www.jnode.org/node/174]. The rest of the system is completely written in Java including its graphical user interface. Applications in JNode are referred to as plugins [http://www.jnode.org/node/175] including the device drivers, filesystems, networking and user applications.

[http://www4.informatik.uni-erlangen.de/Projects/JX/index.html JX] was created at the University of Erlangen. At it’s base is a microkernel that the basic Java Virtual Machine runs on which is similar to JavaOS. The system runs on the idea of domains where the microkernel runs at domain level zero and subsequent programs run in domain A, B, C, etc. Domains contain their own threads, heap and garbage collector and can communicate with other domains using portals. A portal is essentially the same as inter-process communication but using domains as processes instead [http://www.usenix.org/events/usenix02/full_papers/golm/golm.pdf].

===Motivation===

Java is a powerful language that already contains the code necessary for running on many different platforms. With the concept of virtual machines for each individual application it provides a layer of security that not every operating system has. Each virtual machine has it’s own heap which keeps other processes from accessing and writing over already allocated memory since the kernel manages the memory paging. With the use of just-in-time (JIT) compilers, these operating systems can almost achieve comparable run times when compared to native compiled applications.

Since all Java applications are compiled into the same set of bytecode, third-parties can develop their own implementation of the Java runtime. For example, Google has created the Dalvik Virtual Machine for use with the Android platform so it will run more efficiently on small devices while reducing the memory footprint [http://developer.android.com/guide/basics/what-is-android.html]. Google has just recently released Android 2.2 which includes a new JIT compiler for their Dalvik Virtual Machine which can improve speeds of applications up to 2-5 times [http://android-developers.blogspot.com/2010/05/dalvik-jit.html]. IBM also has their own version of the Java Virtual Machine, J9, that is used in many of their own pieces of software and also includes its own implementation of a JIT compiler.

===Achievements===

Android is probably one of the most well-known and mainstream Java based operating system currently on the market. Even though it’s the youngest of the operating systems discussed, it has become one of the newest standards for smartphones. With over 150 devices and counting, Android continues to grow and develop.

===Problems===

One major issue with using Java for an operating system is completely relying on the operating system and kernel to manage memory. Since Java is a garbage collecting language, developers do not have direct access to the memory and have to rely on the operating system to clean up after any objects have been left behind. This can be an issue with lower memory systems while running multiple applications at the same time.

===Current Status===

Each operating system has been created or worked on in the last ten years but some have either halted development or have not seen a major stable release in quite a while. JavaOS is still being maintained by Oracle after they had purchased Sun Microsystems. JNode has not seen an update in over a year and a half [http://sourceforge.net/projects/jnode/files/]. JX also seems to be at a stand still in development with only a minor update after its 0.1 release [http://www4.informatik.uni-erlangen.de/Projects/JX/download-sources.html]. Finally, Android is the most active with minor or major updates coming out every few months. The current state Android is in is Android 2.2 with Android 3.0 currently being hinted for quarter four of 2010 [http://www.techradar.com/news/phone-and-communications/mobile-phones/android-3-0-details-you-need-to-know-706243].

== References ==

Moon, David A. "Genera Retrospective." ''1991 International Workshop on Object Orientation in Operating Systems'' (1991): 2-8. Print.

Moon, David A., Thomas F. Knight, John T. Holloway, and Richard D. Greenblatt. "A Lisp Machine." ''ACM SIGIR Forum'' 15.2 (1980): 137-38. Print.

Pleszkun, A. R., and M. J. Thazhuthaveetil. "The Architecture of Lisp Machines." ''Computer'' 20.3 (1987): 35-44. Print.

Talk:COMP 3000 Essay 1 2010 Question 4

2010-10-13T01:19:37Z

Mkugler: /* Discussion */

== Discussion ==

Right then, I'm on it.

--[[User:Mkugler|Mkugler]] 01:19, 13 October 2010 (UTC)

Hi MK, and welcome to the group. Anil mentioned Oberon just today, which is apparently another OS based on a cousin of modula-3. If you could find a way to extend the Modula-3 section with Oberon, perhaps with your own subsection (Youcef has already started with a SPIN section) that should help us round things up nicely. Note the goal is to compare capabilities with C/C++, so feel free to take a global view for thematic consistency too. I'll be doing a bit more in this respect on the Smalltalk section. As Anil said in lecture today, it should hold together as an essay even without the wiki-ish headings.

--[[User:Jjpwilso|Jjpwilso]] 01:07, 13 October 2010 (UTC)

Hey guys. I'm a bit late to the punch on this as I've been preoccupied with a ton of other stuff. I've read through what you've all done thus far and frankly think it's phenomenal, which brings me to my quandry. I wasn't here when you all laid claim to the various components of the essay and am not entirely certain where my efforts should be directed. I noticed that LISP so far is empty, but that it was claimed by ScottG on the 8th.

Is there anywhere in particular where you would like me to work? I'm committed to spending the better part of the next 48 hours entirely on this, so I can put together anything remaining that's needed. If you guys can't get back to me, I'll just expand on whatever I can find more information on.

--[[User:Mkugler|Mkugler]] 23:16, 12 October 2010 (UTC)

The SPIN work is looking good Youcef. Note: please try to put links to your sources in the text so we can see where your ideas are coming from.

--[[User:Jjpwilso|Jjpwilso]] 20:45, 12 October 2010 (UTC)

Anil gave me another clue into how he was thinking of comparisons between these OSes and C/C++. For Smalltalk at least the central theme mentions nothing about processes. Smalltalk is about objects, methods, and messages rather than the traditional C notion of processes manipulating data. This distinction or something similar to it may be useful when looking at other operating systems we're exploring.

--[[User:Jjpwilso|Jjpwilso]] 20:42, 12 October 2010 (UTC)

I've got some small amount of comparison in mine (haven't posted it, since I'm still trying to compile info on MIT's Lisp Machine, but will likely have most of it up tonight), but I would think it would be easier to perhaps do some small comparisons in the individual sections -- I'll be pointing out some differences in Genera and C++ OS's in OO memory, for example -- and then make some more broad strokes in the conclusion encompassing two or more of our chosen OS's and C/C++.

--[[User:ScottG|ScottG]] 19:19, 12 October 2010 (UTC)

Hi all. I'm gradually posting the sections that I finished so far I'd love to hear your thoughts and comments.

Anil also mentioned an important note on our question, we have to compare these operating systems to the ones developed using C and C++. Are we going to do that in the conclusion section? because so far we are not answering the second half of the question.

As for the Oberon, I just did a quick read in Wiki and it says that its written in oberon programming language. But it says its based on a modified version of Modula-2 and they don't mention modula-3, can we still talk about this OS? I cant really start on that today I have a chemistery midterm tomorrow morning, and tomorrow I'm going to finish the rest of SPIN sections.

--[[User:Ymoussou|Youcef M.]] 19:00, 12 October 2010 (UTC)

Thanks for the link Anil! For the group: I asked Anil a couple of questions after class today, and another OS he had in mind was [http://en.wikipedia.org/wiki/Oberon_(operating_system) Oberon], invented by the creator of Modula-3. I don't know if there's more to find about this than there is about SPIN but I've got my hands full for now.

--[[User:Jjpwilso|Jjpwilso]] 18:29, 12 October 2010 (UTC)

Rather than Squeak I was thinking about Smalltalk-80. Here's a [http://portal.acm.org/citation.cfm?id=273&dl=GUIDE,ACM book on Smalltalk] that's available online in the ACM digital library. Just the preface should tell you everything you need to know. [[User:Soma|Anil]] 03:15, 12 October 2010 (UTC)

Great work on the Java section. I might toss in a bit on the problems section about cross-platform compatibility once I get done with my part.

--[[User:Jjpwilso|Jjpwilso]] 23:57, 10 October 2010 (UTC)

I've posted what I have written so far for the Java section, if anyone has any suggestion/corrections feel free to post them.
EDIT: I've added the other sections of the Java based operating system.

--[[User:Selliot3|Selliot3]] 16:50, 10 October 2010 (UTC)

Re: Motivation. I had Smalltalk in mind when I roughed out the headings and it's pretty much what you suggested. But the headings are only a guideline. If you prefer a different structure for your sections feel free to improvise. As for format I am assuming an essay style.

Re: SPIN. The ACM site has some stuff. You'll need your student card handy to get through the Carleton Library proxy.

Here are a couple of links (you can find a TON more if you search for SPIN at the top of the portal):

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380940&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Distributed LTL model-checking in SPIN]

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380935&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Using SPIN for feature interaction analysis—a case study]

--[[User:Jjpwilso|Jjpwilso]] 16:25, 10 October 2010 (UTC)

This is all I could find on SPIN

SPIN-An extensible microkernel for application-specific operating system devices [http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA293537]

Extensibility, Safety and Performance in the SPIN Operating System [http://cseweb.ucsd.edu/~savage/papers/Sosp95.pdf]

SPIN-Operating System [http://cs-pub.bu.edu/fac/richwest/cs591_w1/notes/spin.pdf]

Lecture 9: SPIN operating system [http://www.youtube.com/watch?v=YE9uztJ_CFg]

--[[User:Ymoussou|Youcef M.]] 16:06, 10 October 2010 (UTC)

What is meant by "Motivation"? Would that be motivation to use the language for an operating system? Also, what format should we be doing this in? I'm pretty much writing in an essay style for the overview to explain all of the operating systems in Java with an introduction and a paragraph for each of the systems. Then, I would fill out a paragraph or two for Motivation, Problems, etc. Does that seem fine?

--[[User:Selliot3|Selliot3]] 15:13, 10 October 2010 (UTC)

Here's a link to the main [http://www-spin.cs.washington.edu/ SPIN website].

--[[User:Jjpwilso|Jjpwilso]] 16:40, 9 October 2010 (UTC)

I'll start right away, but the reference link doesn't work...

--Youcef M. 15:06, 9 October 2010 (UTC)

Welcome, Youcef. It would probably be best if you focused on one operating system for now. Nobody has claimed SPIN yet, the OS in Modula-3. Do you think you could dig into that? There's a good reference below.

--[[User:Jjpwilso|Jjpwilso]] 15:02, 9 October 2010 (UTC)

Hey guys I'm in the group, sorry for not adding something yet. I've been working on a table which has all the operating systems in those languages and comparing them to each other. But it was harder than I thought, I was trying to find where the OS's are similar and where they are different. It got a little bit long and random; I can find a lot of info on one OS but almost none on the other. Do you guys think its worth the trouble to finish it or should just forget about and keep up with you guys?

--Youcef M. 14:41, 9 October 2010 (UTC)

Particular to Squeak: [http://portal.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=263754&type=pdf&coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 Back to the Future - The Story of Squeak, A Practical Smalltalk Written in Itself]

--[[User:Jjpwilso|Jjpwilso]] 13:29, 9 October 2010 (UTC)

From an interview with Alan Kay, founder of Smalltalk, I tracked down a very useful history:
[http://portal.acm.org.proxy.library.carleton.ca/results.cfm?coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 The Early History of Smalltalk]. There happen to be some important foundational points in here (with references) that relate to other systems as well. For instance he explains how LISP was a vital part of how he came to understand the power of languages. Warning: it's quite long and I don't understand half of it.

--[[User:Jjpwilso|Jjpwilso]] 13:02, 9 October 2010 (UTC)

I'd be fine doing LISP, among throwing out anything good for the other languages I happen to come across.

--[[User:ScottG|ScottG]] 21:27, 8 October 2010 (UTC)

Okay, lets all put down our preferences here and set a reasonable deadline of Saturday at 23:59 for a cutoff. Smalltalk would be my top choice. Of course any contributions to any language will be welcome.

--[[User:Jjpwilso|Jjpwilso]] 16:07, 8 October 2010 (UTC)

I would love to do the Java section. I`ve done quite a bit of development on Android and have also read a complete book on how the Android operating system works. Of course, there are other OS`s to look at but I`m a big fan of Android so I`m always happy to write about it haha.

--[[User:Selliot3|Selliot3]] 15:44, 8 October 2010 (UTC)

I recommend we use the habit of putting more recent comments at the top in case this gets to be a longish list. I've gone ahead and stubbed out a proposed structure. Please comment (thumbs up/down). If we all agree we can start dividing up the parts so we don't do the same work. We're lucky as a team to have such a nicely partitioned essay to write!

--[[User:Jjpwilso|Jjpwilso]] 13:23, 8 October 2010 (UTC)

Genera (LISP) - http://en.wikipedia.org/wiki/Genera_(operating_system) <-- only for a reference for now 
SPIN (Modula) - http://www-spin.cs.washington.edu%2Fexternal%2Foverview.html 
Squeak (SmallTalk) - http://en.wikipedia.org/wiki/Squeak <-- only a reference, says it's a programming language but can be used as an OS 
JavaOS (Java) - http://java.sun.com/developer/products/JavaOS/ 

--[[User:Selliot3|Selliot3]] 00:16, 6 October 2010 (UTC) or Charles

Not a great site, but gives a nice breakdown of the main points of Squeak - http://www.visoracle.com/squeak/overview.html 
And a much longer, more in-depth Squeak page - http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html 
A nice breakdown for JavaOS - http://www.operating-system.org/betriebssystem/_english/bs-javaos.htm 
And a very nice PDF for Genera - http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=183015&tag=1 
--[[User:ScottG|ScottG]] 13:08, 6 October 2010 (UTC)

For Java section: [http://developer.android.com/guide/basics/what-is-android.html What is Android] shows the limited role of DVM (Android's JVM). 
--[[User:Jjpwilso|Jjpwilso]] 14:31, 7 October 2010 (UTC)

User:Mkugler

2010-10-13T00:07:10Z

Mkugler: Created page with "This is the profile of Martin Kugler. You may contact me at mkugler@connect.carleton.ca if you need to reach me."

This is the profile of Martin Kugler. You may contact me at mkugler@connect.carleton.ca if you need to reach me.

Talk:COMP 3000 Essay 1 2010 Question 4

2010-10-13T00:06:23Z

Mkugler: /* Discussion */

== Discussion ==

Hey guys. I'm a bit late to the punch on this as I've been preoccupied with a ton of other stuff. I've read through what you've all done thus far and frankly think it's phenomenal, which brings me to my quandry. I wasn't here when you all laid claim to the various components of the essay and am not entirely certain where my efforts should be directed. I noticed that LISP so far is empty, but that it was claimed by ScottG on the 8th.

Is there anywhere in particular where you would like me to work? I'm committed to spending the better part of the next 48 hours entirely on this, so I can put together anything remaining that's needed. If you guys can't get back to me, I'll just expand on whatever I can find more information on.

--[[User:Mkugler|Mkugler]] 23:16, 12 October 2010 (UTC)

The SPIN work is looking good Youcef. Note: please try to put links to your sources in the text so we can see where your ideas are coming from.

--[[User:Jjpwilso|Jjpwilso]] 20:45, 12 October 2010 (UTC)

Anil gave me another clue into how he was thinking of comparisons between these OSes and C/C++. For Smalltalk at least the central theme mentions nothing about processes. Smalltalk is about objects, methods, and messages rather than the traditional C notion of processes manipulating data. This distinction or something similar to it may be useful when looking at other operating systems we're exploring.

--[[User:Jjpwilso|Jjpwilso]] 20:42, 12 October 2010 (UTC)

I've got some small amount of comparison in mine (haven't posted it, since I'm still trying to compile info on MIT's Lisp Machine, but will likely have most of it up tonight), but I would think it would be easier to perhaps do some small comparisons in the individual sections -- I'll be pointing out some differences in Genera and C++ OS's in OO memory, for example -- and then make some more broad strokes in the conclusion encompassing two or more of our chosen OS's and C/C++.

--[[User:ScottG|ScottG]] 19:19, 12 October 2010 (UTC)

Hi all. I'm gradually posting the sections that I finished so far I'd love to hear your thoughts and comments.

Anil also mentioned an important note on our question, we have to compare these operating systems to the ones developed using C and C++. Are we going to do that in the conclusion section? because so far we are not answering the second half of the question.

As for the Oberon, I just did a quick read in Wiki and it says that its written in oberon programming language. But it says its based on a modified version of Modula-2 and they don't mention modula-3, can we still talk about this OS? I cant really start on that today I have a chemistery midterm tomorrow morning, and tomorrow I'm going to finish the rest of SPIN sections.

--[[User:Ymoussou|Youcef M.]] 19:00, 12 October 2010 (UTC)

Thanks for the link Anil! For the group: I asked Anil a couple of questions after class today, and another OS he had in mind was [http://en.wikipedia.org/wiki/Oberon_(operating_system) Oberon], invented by the creator of Modula-3. I don't know if there's more to find about this than there is about SPIN but I've got my hands full for now.

--[[User:Jjpwilso|Jjpwilso]] 18:29, 12 October 2010 (UTC)

Rather than Squeak I was thinking about Smalltalk-80. Here's a [http://portal.acm.org/citation.cfm?id=273&dl=GUIDE,ACM book on Smalltalk] that's available online in the ACM digital library. Just the preface should tell you everything you need to know. [[User:Soma|Anil]] 03:15, 12 October 2010 (UTC)

Great work on the Java section. I might toss in a bit on the problems section about cross-platform compatibility once I get done with my part.

--[[User:Jjpwilso|Jjpwilso]] 23:57, 10 October 2010 (UTC)

I've posted what I have written so far for the Java section, if anyone has any suggestion/corrections feel free to post them.
EDIT: I've added the other sections of the Java based operating system.

--[[User:Selliot3|Selliot3]] 16:50, 10 October 2010 (UTC)

Re: Motivation. I had Smalltalk in mind when I roughed out the headings and it's pretty much what you suggested. But the headings are only a guideline. If you prefer a different structure for your sections feel free to improvise. As for format I am assuming an essay style.

Re: SPIN. The ACM site has some stuff. You'll need your student card handy to get through the Carleton Library proxy.

Here are a couple of links (you can find a TON more if you search for SPIN at the top of the portal):

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380940&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Distributed LTL model-checking in SPIN]

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380935&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Using SPIN for feature interaction analysis—a case study]

--[[User:Jjpwilso|Jjpwilso]] 16:25, 10 October 2010 (UTC)

This is all I could find on SPIN

SPIN-An extensible microkernel for application-specific operating system devices [http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA293537]

Extensibility, Safety and Performance in the SPIN Operating System [http://cseweb.ucsd.edu/~savage/papers/Sosp95.pdf]

SPIN-Operating System [http://cs-pub.bu.edu/fac/richwest/cs591_w1/notes/spin.pdf]

Lecture 9: SPIN operating system [http://www.youtube.com/watch?v=YE9uztJ_CFg]

--[[User:Ymoussou|Youcef M.]] 16:06, 10 October 2010 (UTC)

What is meant by "Motivation"? Would that be motivation to use the language for an operating system? Also, what format should we be doing this in? I'm pretty much writing in an essay style for the overview to explain all of the operating systems in Java with an introduction and a paragraph for each of the systems. Then, I would fill out a paragraph or two for Motivation, Problems, etc. Does that seem fine?

--[[User:Selliot3|Selliot3]] 15:13, 10 October 2010 (UTC)

Here's a link to the main [http://www-spin.cs.washington.edu/ SPIN website].

--[[User:Jjpwilso|Jjpwilso]] 16:40, 9 October 2010 (UTC)

I'll start right away, but the reference link doesn't work...

--Youcef M. 15:06, 9 October 2010 (UTC)

Welcome, Youcef. It would probably be best if you focused on one operating system for now. Nobody has claimed SPIN yet, the OS in Modula-3. Do you think you could dig into that? There's a good reference below.

--[[User:Jjpwilso|Jjpwilso]] 15:02, 9 October 2010 (UTC)

Hey guys I'm in the group, sorry for not adding something yet. I've been working on a table which has all the operating systems in those languages and comparing them to each other. But it was harder than I thought, I was trying to find where the OS's are similar and where they are different. It got a little bit long and random; I can find a lot of info on one OS but almost none on the other. Do you guys think its worth the trouble to finish it or should just forget about and keep up with you guys?

--Youcef M. 14:41, 9 October 2010 (UTC)

Particular to Squeak: [http://portal.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=263754&type=pdf&coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 Back to the Future - The Story of Squeak, A Practical Smalltalk Written in Itself]

--[[User:Jjpwilso|Jjpwilso]] 13:29, 9 October 2010 (UTC)

From an interview with Alan Kay, founder of Smalltalk, I tracked down a very useful history:
[http://portal.acm.org.proxy.library.carleton.ca/results.cfm?coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 The Early History of Smalltalk]. There happen to be some important foundational points in here (with references) that relate to other systems as well. For instance he explains how LISP was a vital part of how he came to understand the power of languages. Warning: it's quite long and I don't understand half of it.

--[[User:Jjpwilso|Jjpwilso]] 13:02, 9 October 2010 (UTC)

I'd be fine doing LISP, among throwing out anything good for the other languages I happen to come across.

--[[User:ScottG|ScottG]] 21:27, 8 October 2010 (UTC)

Okay, lets all put down our preferences here and set a reasonable deadline of Saturday at 23:59 for a cutoff. Smalltalk would be my top choice. Of course any contributions to any language will be welcome.

--[[User:Jjpwilso|Jjpwilso]] 16:07, 8 October 2010 (UTC)

I would love to do the Java section. I`ve done quite a bit of development on Android and have also read a complete book on how the Android operating system works. Of course, there are other OS`s to look at but I`m a big fan of Android so I`m always happy to write about it haha.

--[[User:Selliot3|Selliot3]] 15:44, 8 October 2010 (UTC)

I recommend we use the habit of putting more recent comments at the top in case this gets to be a longish list. I've gone ahead and stubbed out a proposed structure. Please comment (thumbs up/down). If we all agree we can start dividing up the parts so we don't do the same work. We're lucky as a team to have such a nicely partitioned essay to write!

--[[User:Jjpwilso|Jjpwilso]] 13:23, 8 October 2010 (UTC)

Genera (LISP) - http://en.wikipedia.org/wiki/Genera_(operating_system) <-- only for a reference for now 
SPIN (Modula) - http://www-spin.cs.washington.edu%2Fexternal%2Foverview.html 
Squeak (SmallTalk) - http://en.wikipedia.org/wiki/Squeak <-- only a reference, says it's a programming language but can be used as an OS 
JavaOS (Java) - http://java.sun.com/developer/products/JavaOS/ 

--[[User:Selliot3|Selliot3]] 00:16, 6 October 2010 (UTC) or Charles

Not a great site, but gives a nice breakdown of the main points of Squeak - http://www.visoracle.com/squeak/overview.html 
And a much longer, more in-depth Squeak page - http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html 
A nice breakdown for JavaOS - http://www.operating-system.org/betriebssystem/_english/bs-javaos.htm 
And a very nice PDF for Genera - http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=183015&tag=1 
--[[User:ScottG|ScottG]] 13:08, 6 October 2010 (UTC)

For Java section: [http://developer.android.com/guide/basics/what-is-android.html What is Android] shows the limited role of DVM (Android's JVM). 
--[[User:Jjpwilso|Jjpwilso]] 14:31, 7 October 2010 (UTC)

Talk:COMP 3000 Essay 1 2010 Question 4

2010-10-12T23:16:14Z

Mkugler:

== Discussion ==

Hey guys. I'm a bit late to the punch on this as I've been preoccupied with a ton of other stuff. I've read through what you've all done thus far and frankly think it's phenomenal, which brings me to my quandry. I wasn't here when you all laid claim to the various components of the essay and am not entirely certain where my efforts should be directed. I noticed that LISP so far is empty, but that it was claimed by ScottG on the 8th.

Is there anywhere in particular where you would like me to work? I'm committed to spending the better part of the next 48 hours entirely on this, so I can put together anything remaining that's needed.

--[[User:Mkugler|Mkugler]] 23:16, 12 October 2010 (UTC)

The SPIN work is looking good Youcef. Note: please try to put links to your sources in the text so we can see where your ideas are coming from.

--[[User:Jjpwilso|Jjpwilso]] 20:45, 12 October 2010 (UTC)

Anil gave me another clue into how he was thinking of comparisons between these OSes and C/C++. For Smalltalk at least the central theme mentions nothing about processes. Smalltalk is about objects, methods, and messages rather than the traditional C notion of processes manipulating data. This distinction or something similar to it may be useful when looking at other operating systems we're exploring.

--[[User:Jjpwilso|Jjpwilso]] 20:42, 12 October 2010 (UTC)

I've got some small amount of comparison in mine (haven't posted it, since I'm still trying to compile info on MIT's Lisp Machine, but will likely have most of it up tonight), but I would think it would be easier to perhaps do some small comparisons in the individual sections -- I'll be pointing out some differences in Genera and C++ OS's in OO memory, for example -- and then make some more broad strokes in the conclusion encompassing two or more of our chosen OS's and C/C++.

--[[User:ScottG|ScottG]] 19:19, 12 October 2010 (UTC)

Hi all. I'm gradually posting the sections that I finished so far I'd love to hear your thoughts and comments.

Anil also mentioned an important note on our question, we have to compare these operating systems to the ones developed using C and C++. Are we going to do that in the conclusion section? because so far we are not answering the second half of the question.

As for the Oberon, I just did a quick read in Wiki and it says that its written in oberon programming language. But it says its based on a modified version of Modula-2 and they don't mention modula-3, can we still talk about this OS? I cant really start on that today I have a chemistery midterm tomorrow morning, and tomorrow I'm going to finish the rest of SPIN sections.

--[[User:Ymoussou|Youcef M.]] 19:00, 12 October 2010 (UTC)

Thanks for the link Anil! For the group: I asked Anil a couple of questions after class today, and another OS he had in mind was [http://en.wikipedia.org/wiki/Oberon_(operating_system) Oberon], invented by the creator of Modula-3. I don't know if there's more to find about this than there is about SPIN but I've got my hands full for now.

--[[User:Jjpwilso|Jjpwilso]] 18:29, 12 October 2010 (UTC)

Rather than Squeak I was thinking about Smalltalk-80. Here's a [http://portal.acm.org/citation.cfm?id=273&dl=GUIDE,ACM book on Smalltalk] that's available online in the ACM digital library. Just the preface should tell you everything you need to know. [[User:Soma|Anil]] 03:15, 12 October 2010 (UTC)

Great work on the Java section. I might toss in a bit on the problems section about cross-platform compatibility once I get done with my part.

--[[User:Jjpwilso|Jjpwilso]] 23:57, 10 October 2010 (UTC)

I've posted what I have written so far for the Java section, if anyone has any suggestion/corrections feel free to post them.
EDIT: I've added the other sections of the Java based operating system.

--[[User:Selliot3|Selliot3]] 16:50, 10 October 2010 (UTC)

Re: Motivation. I had Smalltalk in mind when I roughed out the headings and it's pretty much what you suggested. But the headings are only a guideline. If you prefer a different structure for your sections feel free to improvise. As for format I am assuming an essay style.

Re: SPIN. The ACM site has some stuff. You'll need your student card handy to get through the Carleton Library proxy.

Here are a couple of links (you can find a TON more if you search for SPIN at the top of the portal):

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380940&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Distributed LTL model-checking in SPIN]

[http://portal.acm.org.proxy.library.carleton.ca/citation.cfm?id=380921.380935&coll=ACM&dl=ACM&CFID=108110330&CFTOKEN=12401653 Using SPIN for feature interaction analysis—a case study]

--[[User:Jjpwilso|Jjpwilso]] 16:25, 10 October 2010 (UTC)

This is all I could find on SPIN

SPIN-An extensible microkernel for application-specific operating system devices [http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA293537]

Extensibility, Safety and Performance in the SPIN Operating System [http://cseweb.ucsd.edu/~savage/papers/Sosp95.pdf]

SPIN-Operating System [http://cs-pub.bu.edu/fac/richwest/cs591_w1/notes/spin.pdf]

Lecture 9: SPIN operating system [http://www.youtube.com/watch?v=YE9uztJ_CFg]

--[[User:Ymoussou|Youcef M.]] 16:06, 10 October 2010 (UTC)

What is meant by "Motivation"? Would that be motivation to use the language for an operating system? Also, what format should we be doing this in? I'm pretty much writing in an essay style for the overview to explain all of the operating systems in Java with an introduction and a paragraph for each of the systems. Then, I would fill out a paragraph or two for Motivation, Problems, etc. Does that seem fine?

--[[User:Selliot3|Selliot3]] 15:13, 10 October 2010 (UTC)

Here's a link to the main [http://www-spin.cs.washington.edu/ SPIN website].

--[[User:Jjpwilso|Jjpwilso]] 16:40, 9 October 2010 (UTC)

I'll start right away, but the reference link doesn't work...

--Youcef M. 15:06, 9 October 2010 (UTC)

Welcome, Youcef. It would probably be best if you focused on one operating system for now. Nobody has claimed SPIN yet, the OS in Modula-3. Do you think you could dig into that? There's a good reference below.

--[[User:Jjpwilso|Jjpwilso]] 15:02, 9 October 2010 (UTC)

Hey guys I'm in the group, sorry for not adding something yet. I've been working on a table which has all the operating systems in those languages and comparing them to each other. But it was harder than I thought, I was trying to find where the OS's are similar and where they are different. It got a little bit long and random; I can find a lot of info on one OS but almost none on the other. Do you guys think its worth the trouble to finish it or should just forget about and keep up with you guys?

--Youcef M. 14:41, 9 October 2010 (UTC)

Particular to Squeak: [http://portal.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=263754&type=pdf&coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 Back to the Future - The Story of Squeak, A Practical Smalltalk Written in Itself]

--[[User:Jjpwilso|Jjpwilso]] 13:29, 9 October 2010 (UTC)

From an interview with Alan Kay, founder of Smalltalk, I tracked down a very useful history:
[http://portal.acm.org.proxy.library.carleton.ca/results.cfm?coll=ACM&dl=ACM&CFID=107940135&CFTOKEN=78771329 The Early History of Smalltalk]. There happen to be some important foundational points in here (with references) that relate to other systems as well. For instance he explains how LISP was a vital part of how he came to understand the power of languages. Warning: it's quite long and I don't understand half of it.

--[[User:Jjpwilso|Jjpwilso]] 13:02, 9 October 2010 (UTC)

I'd be fine doing LISP, among throwing out anything good for the other languages I happen to come across.

--[[User:ScottG|ScottG]] 21:27, 8 October 2010 (UTC)

Okay, lets all put down our preferences here and set a reasonable deadline of Saturday at 23:59 for a cutoff. Smalltalk would be my top choice. Of course any contributions to any language will be welcome.

--[[User:Jjpwilso|Jjpwilso]] 16:07, 8 October 2010 (UTC)

I would love to do the Java section. I`ve done quite a bit of development on Android and have also read a complete book on how the Android operating system works. Of course, there are other OS`s to look at but I`m a big fan of Android so I`m always happy to write about it haha.

--[[User:Selliot3|Selliot3]] 15:44, 8 October 2010 (UTC)

I recommend we use the habit of putting more recent comments at the top in case this gets to be a longish list. I've gone ahead and stubbed out a proposed structure. Please comment (thumbs up/down). If we all agree we can start dividing up the parts so we don't do the same work. We're lucky as a team to have such a nicely partitioned essay to write!

--[[User:Jjpwilso|Jjpwilso]] 13:23, 8 October 2010 (UTC)

Genera (LISP) - http://en.wikipedia.org/wiki/Genera_(operating_system) <-- only for a reference for now 
SPIN (Modula) - http://www-spin.cs.washington.edu%2Fexternal%2Foverview.html 
Squeak (SmallTalk) - http://en.wikipedia.org/wiki/Squeak <-- only a reference, says it's a programming language but can be used as an OS 
JavaOS (Java) - http://java.sun.com/developer/products/JavaOS/ 

--[[User:Selliot3|Selliot3]] 00:16, 6 October 2010 (UTC) or Charles

Not a great site, but gives a nice breakdown of the main points of Squeak - http://www.visoracle.com/squeak/overview.html 
And a much longer, more in-depth Squeak page - http://www.cosc.canterbury.ac.nz/wolfgang.kreutzer/cosc205/smalltalk1.html 
A nice breakdown for JavaOS - http://www.operating-system.org/betriebssystem/_english/bs-javaos.htm 
And a very nice PDF for Genera - http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=183015&tag=1 
--[[User:ScottG|ScottG]] 13:08, 6 October 2010 (UTC)

For Java section: [http://developer.android.com/guide/basics/what-is-android.html What is Android] shows the limited role of DVM (Android's JVM). 
--[[User:Jjpwilso|Jjpwilso]] 14:31, 7 October 2010 (UTC)