The other is empty, and is used during an event called 'The Scavenge'. A fourth space, 'LargeSpace', is used to handle large objects as a modification to the original algorithm, and attempts to reduce the movement of large byte objects between Survivor spaces. Strings that exceed roughly 1K are created in LargeSpace with a link to Eden. During a scavenge, the VM locates all objects in Eden and the active SurvivorSpace reachable by the systems roots and copies them into the empty SurvivorSpace. Once the scavenge completes examining Eden and the original active SurvivorSpace, those spaces now only contain dead objects, and are deemed empty.
Memory allocation starts again, with objects being placed into Eden.
As you can see, survivor objects are shuffled between the two SurvivorSpaces on each scavenge, with new objects being added from Eden. Objects which die in SurvivorSpace are not copied during the Scavenge, and overall growth is based on how good or bad your application is in creating and holding new objects. You will notice that 40K or so of memory isn't very big, so once the number of bytes in SurvivorSpace reaches the defined threshold, the scavenger will tenure objects to OldSpace from SurvivorSpace until there is room in the SurvivorSpace. OldSpace is a number of memory segments that combine to form a virtual chunk of contiguous memory. This fact leads to the external behavior shown to the hosting operating system.