MOSA Project

Rated 5 Stars (out of 5) - Very very good project at start. Please don't stop it! You may be one of the pioneers of the future OSes.

Checked in by server upgrade

duplicate

duplicate

>>I'm still puzzling with this one and I don't fully understand your reaction. I think that you mean that you let the compiler figure out what to swap and what not, is it not? The compiler has no idea... it depends on the scheduler granting ... [More] CPU if you have no CPU you can be swapped out. >>Knowing what is not active so it can be swapped out is key for virtual memory. A number of language items could maintain meta data to determine if it's probable that they will be used soon and thus reloaded. Things like creation and access time and a usage number would incur a cost for memory and maintaining though. Yes this would be too expensive.. You could get the compiler to add a write/read barrier to base the information on but basically if you are on teh Run list you will need some memory. Note it is very similar to hw paged memory except for the granularity. > - AppDomain (process) Swapping a whole domain is probably to course and could be impossible if more memory is needed for a single appdomain than is physically on the machine. You can swap all the memory used out by the domain or better yet in large blocks ( eg 2 Meg) as desired ( the more conetention the more big blocks you move out obviosuly tasks with some blocks already out should be favoured) , also note here a GC also grabs large blocks from the system . >- Functions Could be swapped to disk but code is normally to small to be of any benefit - Classes and structs Maintaining metadata for a class next to a vtable should be manageable and maintaining a table where all the objects of a class are tracked so they can be swapped out to disc. - indivual objects on the heap I think that maintaining metadata for every object would probably be to heavy. It could be done if the programmer opts in certain objects but relying on the despondence of the programmer for the stability of the system would be wrong. - indivual objects on the stack stack objects will probably be used sooner than later why would they be on the stack otherwise. I'm thinking along the lines of upgrading the GC to also let it move the objects to disk, that are less often used. It is almost impossible to do this . To get an idea of how often objects and memory is used you need a read and write barrier ( compiler inserted) which is prohibitively expensive. What im looking at in SOOOS is to break applications down into smaller reusable services . In the past we have used libraries but libraries have the issues of They are difficult to reuse. A service with an interface can be used on any machine local or remote and avoids the lib versioning hell you get on Linux . Code that fails in a lib forces the caller to die since its state is unknown   By breaking apps into smaller services we have - no perf penalty on managed systems due to the low task switch costs - increased reliability since a service can fail and not affect a caller . eg a browser add on cant stop a browser( Flash anyone) - services can be restarted , the result is a failure will cause part of an app not to work and when restarted start working again. - Services can start multiple instances to process requests and be load balanced on cores or even machines. eg if a part of an app is hot ( say encryption) the system can fire up more services which get processed on more cores without any multi threaded code. - Services with no CPU which are blocking can be swapped out of memory . IMHO this maybe be superior to the current paging which is broken. - Increased code reuse and more standardization . - Improved security as "apps" become really small and have few rights. - Easy to isolate problems to a service which can all log. - Services can be local or in a cloud.. eg a Campus could have a huge compiler bank for all services which programs ( make files/ build scripts can use) , devs can run services local on the machine or in the cloud and can move them trivially. All this can be done now it will just become trivial to code. Note there are still DLLs just a lot less and anyway its miles off and im still working on IPC. Obviously it uses Async IPC. [Less]

>>I'm still puzzling with this one and I don't fully understand your reaction. I think that you mean that you let the compiler figure out what to swap and what not, is it not? The compiler has no idea... it depends on the scheduler granting ... [More] CPU if you have no CPU you can be swapped out. >>Knowing what is not active so it can be swapped out is key for virtual memory. A number of language items could maintain meta data to determine if it's probable that they will be used soon and thus reloaded. Things like creation and access time and a usage number would incur a cost for memory and maintaining though. Yes this would be too expensive.. You could get the compiler to add a write/read barrier to base the information on but basically if you are on teh Run list you will need some memory. Note it is very similar to hw paged memory except for the granularity. > - AppDomain (process) Swapping a whole domain is probably to course and could be impossible if more memory is needed for a single appdomain than is physically on the machine. You can swap all the memory used out by the domain or better yet in large blocks ( eg 2 Meg) as desired ( the more conetention the more big blocks you move out obviosuly tasks with some blocks already out should be favoured) , also note here a GC also grabs large blocks from the system . >- Functions Could be swapped to disk but code is normally to small to be of any benefit - Classes and structs Maintaining metadata for a class next to a vtable should be manageable and maintaining a table where all the objects of a class are tracked so they can be swapped out to disc. - indivual objects on the heap I think that maintaining metadata for every object would probably be to heavy. It could be done if the programmer opts in certain objects but relying on the despondence of the programmer for the stability of the system would be wrong. - indivual objects on the stack stack objects will probably be used sooner than later why would they be on the stack otherwise. I'm thinking along the lines of upgrading the GC to also let it move the objects to disk, that are less often used. It is almost impossible to do this . To get an idea of how often objects and memory is used you need a read and write barrier ( compiler inserted) which is prohibitively expensive. What im looking at in SOOOS is to break applications down into smaller reusable services . In the past we have used libraries but libraries have the issues of They are difficult to reuse. A service with an interface can be used on any machine local or remote and avoids the lib versioning hell you get on Linux . Code that fails in a lib forces the caller to die since its state is unknown   By breaking apps into smaller services we have - no perf penalty on managed systems due to the low task switch costs - increased reliability since a service can fail and not affect a caller . eg a browser add on cant stop a browser( Flash anyone) - services can be restarted , the result is a failure will cause part of an app not to work and when restarted start working again. - Services can start multiple instances to process requests and be load balanced on cores or even machines. eg if a part of an app is hot ( say encryption) the system can fire up more services which get processed on more cores without any multi threaded code. - Services with no CPU which are blocking can be swapped out of memory . IMHO this maybe be superior to the current paging which is broken. - Increased code reuse and more standardization . - Improved security as "apps" become really small and have few rights. - Easy to isolate problems to a service which can all log. - Services can be local or in a cloud.. eg a Campus could have a huge compiler bank for all services which programs ( make files/ build scripts can use) , devs can run services local on the machine or in the cloud and can move them trivially. All this can be done now it will just become trivial to code. Note there are still DLLs just a lot less and anyway its miles off and im still working on IPC. Obviously it uses Async IPC. [Less]

This is the first public pre-release of MOSA 0.1.This is now out-dated.Go to GitHub: http://github.com/mosa/MOSA-Project to download the latest source code.Or visit our site: http://www.mosa-project.org

This is the first public pre-release of MOSA 0.1.This is now out-dated.Go to GitHub: http://github.com/mosa/MOSA-Project to download the latest source code.Or visit our site: http://www.mosa-project.org

This is the first public pre-release of MOSA 0.1.This is now out-dated.Go to GitHub: http://github.com/mosa/MOSA-Project to download the latest source code.Or visit our site: http://www.mosa-project.org

This is the first public pre-release of MOSA 0.1.This is now out-dated.Go to GitHub: http://github.com/mosa/MOSA-Project to download the latest source code.Or visit our site: http://www.mosa-project.org