But you don't want to provide N 'runtime entities' on the server, since N is very large. In the stateless-shells Neville describes, the M runtime entities are these fillable object shells which can be stuffed from a much larger number of possible server objects. Hence, you can't take a given box and run one thread per every client that tries to access it over the Internet - you need to do some mapping from your limited supply of threads to the boundless number of client requests you want to service. But in the 'shell game', this isn't clear to me. That's 100M. Yawn.
RAM is cheap.
Virtual memory is standard equipment these days even on crappy OSes like Win95. Memory scaling isn't something worth fudging up the application architecture over. When dealing with method bound activation policies, this becomes a major performance problem. My experience has been that a large portion of the state of the application involved in any given transaction is read-only. That is, during a typical transaction, several objects are activated and used for navigating to the 'target' object that will be changed.