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).
Can anyone recommend a good way to explain single level store for non i, but technical, people (i.e., java devs, windows devs, etc)?