In God RAM, all objects are in a global, ObjectCapabilityModel secure, infinite, persistent, robust, concurrent, AtomicConsistentIsolatedDurable, and uniformly high-performance address space at all times after introduction.

We don't have God RAM, of course, so we build much infrastructure to provide elaborate illusions thereof. Examples:
* We use complex caching mechanisms to achieve several of these purposes: uniformly high performance in the face of distribution, persistence, and relying upon slower bulk-storage for the infinite RAM illusion.
* We use GarbageCollection to reclaim memory that becomes inaccessible, which allows finite RAM to support an unbounded number of objects.
* We must introduce redundancy and robust protocols regenerate objects and keep the system objects alive, active, and consistent in the face of network disruption, delays, and permanent loss of nodes or links.
* We use PublishSubscribeModel to support caches... even CPU units 'listen' for cache invalidation.
* We use SoftwareTransactionalMemory, lock-free algorithms, and locks, attempting to provide various ACID properties in the face of concurrency.
* We limit the set of operations on our "objects" and pass these thru a specialized layer to achieve ACID semantics on this subset (typically in a database by using SQL but also in a PrevalenceLayer).
* We hide references behind types to make them more secure and unforgeable within a language.
* We create a variety of namespaces to achieve global references and distribution.
** For example each table in a database is a namespace and sequence generated IDs are used for unique addressing.
* We use SingletonPattern, DependencyInjection, boiler-plate initializations, and various ambient capabilities (e.g. procedures accessing the 'local' OS) to offer the illusion of objects available and preconfigured even before we start up an application.

Unfortunately, we often make trade-offs between which GodRamIllusion features we wish to possess. For example, ambient capabilities (unless done carefully) make it difficult to achieve security for mobile code, which in turn makes it difficult to move or cache code to be near the user. Similarly, in achieving high performance we often sacrifice persistence. The sacrifices involved generally aren't reversible... not without basically writing a whole new language or framework in the old one. As such, '''support for the GodRamIllusion is a (whole set of) KeyLanguageFeature(s).'''

As with any set of CrossCuttingConcern''''''s, we can hurt the GodRamIllusion with decisions that seem irrelevant. The traditional implementation for constructors in OO languages, for example, makes persistence, caching, and redundancy of object-graphs incredibly difficult to achieve. This suggests that, if we wish to support the GodRamIllusion as a KeyLanguageFeature, we probably need more specialized alternatives to constructors. (Related: ConstructorsAreEvil.)

I suspect that we could achieve much larger chunks of the GodRamIllusion - perhaps the whole shebang - without sacrifices to either the other areas of the GodRamIllusion or the other language features and temporal optimizations. There are almost always alternatives to sacrifice.
-------
Some discussion moved to GodRamIllusionHassle

''With all due respect, I think you misunderstood the above.  Reference to unique IDs in databases is irrelevant.''

You (I assume) gave examples. So did I when rephrasing Top. But it seems still not to have been enough, so I tried again. 
I really think that Top relates to the points made but just doesn't come across. But that's not his fault alone. A modern DB '''does''' address many of the GodRam 'features' but alas not those many of us prefer most.
--------
'''Large Addresses'''

One thing that sort of bothers me about universal address space is that high-usage rows/objects could potentially have a low number and thus save space because they are referenced often. For example, lets say we have a Product table in our retail store system. The store has about 2,000 products. The product numbers would be relatively small compared to say invoice ID because there's likely far more invoices than products. 

If instead the row ID's are universal across table-space, then product numbers may be rather large. Because they are referenced often, more space is then taken up. One may argue for a separate custom ID for product catalog, but then we are wasting space because we have two ID's: the native one and the custom one. Per-entity numbering thus seems to result in less memory/disk being used because the ID's are often smaller for commonly-used objects/records. It's almost a "natural" form of Huffman encoding where the most common pattern references are the shortest reference identifiers.

I'm not sure the space matters that much these days, but it could be a noticeable factor for a very large system, especially where the "thin table" design philosophy tends to be prevalent.

--top 

'address space' doesn't necessarily mean that we have 'unique ids'. The addresses may be abstract and not convertible to numeric. Example: Javas objects references cannot be converted to numeric. This allows the GC to move these obejcts around.
Maybe one wants to have numeric IDs. In that case this could be an explicit operation or one for which the context of applicability is constrained or controlled. Then the size issue can easily optimized away by inferring large parts of the address from the inferred or given context.
Example: Your product ID ''would be'' the unique ID because the remaining parts can be inferred from the table name (and the DB it resides etc.).

''To emulate existing RAM, it does have to have a numeric and unique address. If not, then perhaps not call it "RAM", because it would be misleading.''

RAM simply means Random Access Memory. "Random Access" simply refers to the "uniformly high performance" and the ability to access in arbitrary order. It ''does not'' refer to any particular addressing scheme.

And if you wanted to emulate existing RAM in God RAM, you'd simply create an object that maps small integers to small integers. But it's worth noting that the goal of hardware, OS, and language developers is the other way around: RAM to better match God RAM.

''Universally unique addresses would ideally be part of the upgrade, no?''
----
See: NameSpace, SingleAddressSpaceOperatingSystem
----
OctoberTen