Program data storage.

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
B.E
Member
Member
Posts: 275
Joined: Sat Oct 21, 2006 5:29 pm
Location: Brisbane Australia
Contact:

Program data storage.

Post by B.E »

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
Image
Microsoft: "let everyone run after us. We'll just INNOV~1"
User avatar
Brynet-Inc
Member
Member
Posts: 2426
Joined: Tue Oct 17, 2006 9:29 pm
Freenode IRC: brynet
Location: Canada
Contact:

Post by Brynet-Inc »

But RAM isn't non-volatile... I can't find your logic, is it missing? :wink:
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Freenode IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

Hard drive access is much slower than the RAM, which is why programs take a while to load.
frank
Member
Member
Posts: 729
Joined: Sat Dec 30, 2006 2:31 pm
Location: East Coast, USA

Post by frank »

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.
User avatar
Brynet-Inc
Member
Member
Posts: 2426
Joined: Tue Oct 17, 2006 9:29 pm
Freenode IRC: brynet
Location: Canada
Contact:

Post by Brynet-Inc »

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..
Image
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
User avatar
B.E
Member
Member
Posts: 275
Joined: Sat Oct 21, 2006 5:29 pm
Location: Brisbane Australia
Contact:

Post by B.E »

Brynet-net wrote:But RAM isn't non-volatile... I can't find your logic, is it missing?


It would basically be a saved paged (if that makes since).

pcmattman wrote:Hard drive access is much slower than the RAM, which is why programs take a while to load.


it would only be as slow as when read a page from disk.

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.


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.

Brynet-Inc wrote:Not to mention it would use an excessive amount of resources...


Like the paging system, the resources would only be used when needed

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?


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.

Even if this was possible, which I highly doubt.. you would be insane to try it.


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.
Image
Microsoft: "let everyone run after us. We'll just INNOV~1"
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Freenode IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

What you're talking about sounds a lot like page swapping, where pages are swapped out to a pagefile when they haven't been used for a while (and then swapped back in when they're needed).
Crazed123
Member
Member
Posts: 248
Joined: Thu Oct 21, 2004 11:00 pm

Post by Crazed123 »

Actually, it sounds a lot more like orthogonal persistence.
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

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.

(i.e logs, Binary trees, linked lists, configuration data, program state, etc). Edit: Also it could act as a shared memory location to./

Linked Lists And Trees
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. :D
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Freenode IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

All you'd need to do would be write the entire address space to a file, and then when it needs to be loaded again there should be no problems with writing it all back (starting with the page directories and tables might help)
User avatar
piranha
Member
Member
Posts: 1391
Joined: Thu Dec 21, 2006 7:42 pm
Location: Unknown. Momentum is pretty certain, however.
Contact:

Post by piranha »

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
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

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
User avatar
AndrewAPrice
Member
Member
Posts: 2294
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

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.
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Post by AJ »

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.


Some potential problems:

* 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
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

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!


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.
Post Reply