Re: Explaining single level store to non i people

Joe wrote:

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.

On the other hand, the internals of single-level store are rarely exposed
to the iSeries programmer. Within a program, you still deal with a model
where you open, read, write, update, and close files. That is, the
programmer deals with a model not unlike that of conventional systems.

Actually, you can't really have it any other way. One way or another, the
operating system still needs to synchronize access to the "file" objects.

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.

On a conventional modern operating system, new devices are typically
supported through device drivers. Once the driver has been installed,
programmers (system and application programmers) deal with it just like
other devices on the system. That is, the device drivers shield the
implementation details from the programmer.

BTW, "Single paging mechanism"? I was not aware that operating systems
could have multiple paging mechanisms!

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.

While of course, applications perform better when there are fewer page
faults, positioning segments of code within the address space is one of
the things done by good optimizing compiler back-ends. I don't see that OO
code is going to be any different than procedural code. In particular, for
many interpreted OO languages, the core of the interpreter would normally
be used so much that it won't be paged out at all. Anyways, for either
procedural or OO code, the most frequently accessed code will be paged
less, regardless of where it resides in the virtual address space. So I'm
not really sure what your point is here.

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).

Considering that SLS needs to be implemented on real hardware, and since
no CPU (as far as I know) implements greater than a 64-bit address space,
you're always going to have to make some difficult trade-offs with respect
to space size in any SLS implementation. That is, do you want bigger
spaces? Or more possible spaces? (I remember the 48-bit S/38, which
occasionally ran out of addresses.) In the design of a conventional
machine architecture, you don't have to make the same trade-off. You get a
separate 64-bit space for each process.

For the iSeries to grow beyond the 16MB space limitation while maintaining
the SLS architecture, it needs a CPU that supports >64-bit addressing.
While certainly possible, that would necessarily bump up the cost of such
a machine. Frankly, considering the current demand for iSeries machines, I
doubt if a business case can be put together for such a product.

Cheers! Hans