The essential goodness of SLS is that no part of the application is ever involved with moving things between memory and disk. Everything has an address, and when you access that address, the operating system decides whether data is available or whether it needs to be paged in.

This is hugely beneficial from the standpoint of only requiring a single paging mechanism that can be performance tuned to the hilt. Not only that, but it can automatically support any new technology including as Mike has already mentioned, moving to the cloud.

Perhaps the largest potential problem with SLS is that paged memory works best with procedural code rather than object oriented code. People using the same code sequence and each having their own contiguous memory area (the RPG/PAG model) is going to work much better in a paged environment than the random-access nature of object-oriented programming, where bits of data and code are littered all over the virtual memory space and need to be accessed sporadically.

Most other points, from security to obscurity, are pretty much red herrings, as they all apply in one way or another to every system and thus aren't really specific to SLS. For example the 16MB space boundary, while problematic, is a design tradeoff specific to the i5/OS implementation and not an inherent limitation of SLS itself. This last paragraph is an HPO (Humble Pluta Opinion, TM, PatPend).

Joe

Folks:

Can anyone recommend a good way to explain single level store for non i, but technical, people (i.e., java devs, windows devs, etc)?

david



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].