Program data storage.
Program data storage.
Here's my idea,
A file is like non-volatile memory (i.e the data isn't lost when power off or program termination). Why not make each program have it's own "non-volatile" piece of memory. It would act like basically a page of memory.
This would make programs start up quicker, and would have no overhead when reading the data.
Is there any problems with this approach
A file is like non-volatile memory (i.e the data isn't lost when power off or program termination). Why not make each program have it's own "non-volatile" piece of memory. It would act like basically a page of memory.
This would make programs start up quicker, and would have no overhead when reading the data.
Is there any problems with this approach
Microsoft: "let everyone run after us. We'll just INNOV~1"
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
It would waste hard drive space for one thing and programs usually have configuration files and save files for non-volatile storage. I am assuming you mean non-volatile storage like when a computer saves everything in memory to disk like when you hibernate the computer, except that you are planning on only saving the programs memory image.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Not to mention it would use an excessive amount of resources... power failures would also make this idea a failure, and what about running multiple instances of the same application? - I'm assuming that when a process is terminated it can resume it's position when restarted as well? - How would you manage this? - Security concerns? proprietary API's?
Even if this was possible, which I highly doubt.. you would be insane to try it..
Even if this was possible, which I highly doubt.. you would be insane to try it..
It would basically be a saved paged (if that makes since).Brynet-net wrote: But RAM isn't non-volatile... I can't find your logic, is it missing?
it would only be as slow as when read a page from disk.pcmattman wrote: Hard drive access is much slower than the RAM, which is why programs take a while to load.
The program could save it's data structures (i.e logs, Binary trees, linked lists, configuration data, program state, etc). Edit: Also it could act as a shared memory location to.frank wrote: It would waste hard drive space for one thing and programs usually have configuration files and save files for non-volatile storage. I am assuming you mean non-volatile storage like when a computer saves everything in memory to disk like when you hibernate the computer, except that you are planning on only saving the programs memory image.
Like the paging system, the resources would only be used when neededBrynet-Inc wrote: Not to mention it would use an excessive amount of resources...
These are problems I've yet to work out. Although, A MD5(or some sort of hash) could be used to manage data, this also would help prevent viruses.power failures would also make this idea a failure, and what about running multiple instances of the same application?
I'm assuming that when a process is terminated and can resume it's position when restarted? - How would you manage this? - Security concerns? proprietary API's?
it'd be very simple to implement, it would be incorporated into the paging subsystem. which when a program reads a particular address, the paging system loads the data from disk.Even if this was possible, which I highly doubt.. you would be insane to try it.
Microsoft: "let everyone run after us. We'll just INNOV~1"
- Kevin McGuire
- Member
- Posts: 843
- Joined: Tue Nov 09, 2004 12:00 am
- Location: United States
- Contact:
It seems to be the same as:
.. program startup ..
LoadSettingsFromFile(SETTINGS_FILE);
SaveSettingsToFile(SETTINGS_FILE);
The only different is that you are making the system perform this operation instead of the application.
Take for instance CAD software, it might consist of large list linked structures holding objects, geometry arrays, and such other things. The problem is these change when the user loads a new drawing. Why not just let the application handle this data? This is the only major type of information I could figure would be stored in linked list and trees.
Configuration Data
This could be used with the idea since should consist most of GUI settings (default windows placements, styles, blah and blah).
Program State
When you say program state I think of all the above. This would be very similar to hibernation -- which is an idea. Why not save the entire program state when the user closes the application? The only draw back is you would need to provide two close buttons or methods so that the user can completely restart a application or hibernate it. The reason is bugs can slowly start to show over time which is why a very common solution to fixing bugs is to restart the computer or application -- anyway this might be an idea.
Try It?
I can see an idea that should work by providing two methods to (close a window in a GUI environment) where one completely terminates the application and the other hibernates it. The hibernation would allow the application to start much faster next time it is used.
I would try.
.. program startup ..
LoadSettingsFromFile(SETTINGS_FILE);
SaveSettingsToFile(SETTINGS_FILE);
The only different is that you are making the system perform this operation instead of the application.
Linked Lists And Trees(i.e logs, Binary trees, linked lists, configuration data, program state, etc). Edit: Also it could act as a shared memory location to./
Take for instance CAD software, it might consist of large list linked structures holding objects, geometry arrays, and such other things. The problem is these change when the user loads a new drawing. Why not just let the application handle this data? This is the only major type of information I could figure would be stored in linked list and trees.
Configuration Data
This could be used with the idea since should consist most of GUI settings (default windows placements, styles, blah and blah).
Program State
When you say program state I think of all the above. This would be very similar to hibernation -- which is an idea. Why not save the entire program state when the user closes the application? The only draw back is you would need to provide two close buttons or methods so that the user can completely restart a application or hibernate it. The reason is bugs can slowly start to show over time which is why a very common solution to fixing bugs is to restart the computer or application -- anyway this might be an idea.
Try It?
I can see an idea that should work by providing two methods to (close a window in a GUI environment) where one completely terminates the application and the other hibernates it. The hibernation would allow the application to start much faster next time it is used.
I would try.
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
So when the program finishes loading, the OS would save a 'snapshot' of the programs memory to the harddrive and just load that the next time the program loads?
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
What you're talking about is precaching the resources a program needs, right?
Well, generating linked lists, trees, etc, are (1) fast, compared to disk access and (2) depend heavily on pointers, which change with every process instance. (This has been mentioned above)
The main loading time for many programs (especially graphics-intensive programs like games) comes from the resources they load (from disk).
Windows Vista actually has a nice feature (!!!) that caches the filenames that a process accesses on startup, then, next time that process is run, it precaches those files in RAM (in a highly efficient manner, certianly a lot more efficient than the random-access most programs use).
Also, there is a lot of talk about (has it been implemented yet?) having a small flash drive in the computer, that gets saved with the kernel/important startup files. This is persistent storage, and much faster than an HDD. It speeds up bootup time by <insert statistic>.
Just my 2-pennies worth,
JamesM
Well, generating linked lists, trees, etc, are (1) fast, compared to disk access and (2) depend heavily on pointers, which change with every process instance. (This has been mentioned above)
The main loading time for many programs (especially graphics-intensive programs like games) comes from the resources they load (from disk).
Windows Vista actually has a nice feature (!!!) that caches the filenames that a process accesses on startup, then, next time that process is run, it precaches those files in RAM (in a highly efficient manner, certianly a lot more efficient than the random-access most programs use).
Also, there is a lot of talk about (has it been implemented yet?) having a small flash drive in the computer, that gets saved with the kernel/important startup files. This is persistent storage, and much faster than an HDD. It speeds up bootup time by <insert statistic>.
Just my 2-pennies worth,
JamesM
- AndrewAPrice
- Member
- Posts: 2300
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
This has given me a few interesting ideas. How about hibernating programs? Like, if you need to close a program, you have a choice of saving it's state.
My OS is Perception.
Some potential problems:MessiahAndrw wrote:This has given me a few interesting ideas. How about hibernating programs? Like, if you need to close a program, you have a choice of saving it's state.
* What if your program requires dynamic linking? There is a high chance that when it wakes up, the dll could be in a different place.
* What if your program makes use of something like its Program ID or Window ID which are likely to be assigned dynamically?
* How do you solve the problem of several instances of the program running / hibernating concurrently.
I think it's a good idea in some cases, but just wanted to throw some thoughts in to the melting pot
I have heard of an OS storing the disk sectors required to be loaded each time a program starts, and going from that list. I guess that causes problems for defragmenters though!
Cheers,
Adam
As I mentioned above, Vista does that. Although it stores the filenames instead of the disk sectors so it can shimmy sectors around on disk to it's heart's content.I have heard of an OS storing the disk sectors required to be loaded each time a program starts, and going from that list. I guess that causes problems for defragmenters though!