Blakod

In order to make the server incredibly safe, I would estimate that over half of the code is for error checking. For example, even though all Blakod objects’ references to other objects are always valid, the return value of GetObjectByID is checked against NULL. Instead of using the now-common practice of using assertions to abort a program when unforeseen circumstances arise, the server treats these as possible error conditions and logs the problem, instead of aborting. Since even a single crash could cost hundreds or thousands of dollars of customer service time, this was deemed crucial to the game’s success.

Since there is only a minimal amount of game-specific code in the server, the overall design of the server is quite clean (and fairly obvious). The heart of the server is the Blakod interpreter, which runs the actual game code. Blakod calls are made when messages are received from clients or timers expire. Since the Blakod interpreter is single threaded, only one call into Blakod exists at any time. This puts several demands upon the interpreter. First, it must be rather fast, so that the server does not become backed up by client requests. Second, it must endeavor to prevent infinite loops or infinite recursion in Blakod so that one poorly written Blakod function does not hang the entire system.
To support the Blakod interpreter, the server has modules that handle the storage of Blakod objects, Blakod list nodes, Blakod strings, Blakod resources, Blakod strings, Blakod timers, and callback functions. These callback functions, called C code functions, exist so that Blakod may interact with the server, since Blakod has no inherent input or output.
The server’s primary task outside of Blakod interpreting is keeping track of network connections made by clients. It needs to verify user logins, allow administration of the game, and parse client messages from the network to send the necessary messages to Blakod.

The garbage collection system exists in BlakServ to reclaim memory wasted by objects, list nodes, and strings that are no longer needed in the game. Without garbage collection, any machine running BlakServ would run out of memory in a matter of days. With garbage collection, BlakServ is able to run for weeks at a time without needing to be stopped and restarted.
BlakServ uses the “stop and sweep” garbage collection strategy, which means that for a fraction of a second the server stops all processing, performs garbage collection, and then resumes normal operation. Garbage collection is performed in several stages. The first stage reclaims list nodes, the second stage reclaims objects, and the final stage reclaims strings.
The garbage collection system uses the garbage ref field of the various structures as temporary storage to keep track of which structures are referenced and what their new id will be after the garbage collection is done. The list node garbage collection starts by traversing every property of every object and marking every list node referenced by a property. Each list node that is referenced is then given a new list node id in its garbage ref field. All objects are again traversed, and any references to list nodes are changed to refer to the new list node’s new id. Then, the list node array itself is compacted, so that unreferenced list nodes are deleted and all list nodes have their new list node id. One important thing to note about list node garbage collection is that there is a flaw–objects that are later cleared in object node garbage collection may reference list nodes and these list nodes will be saved, even though they could be erased.
The garbage collection of objects works in a similar fashion. It is slightly complicated by the fact that objects are referenced by more places in the server than list nodes. Object node garbage collection begins by traversing the objects associated with every user account in the system. Every object referred to by a property of a user object is marked as referenced and then recursively checked itself–any object referred to by their properties is marked, etc. If a property is a list node, then the list is traversed and any objects referred to by the list are marked and then checked themselves. The system object is also automatically marked and traversed. In this way, every object that is still used by the game is marked as needed, and all unreferenced objects can be prepared to be deleted. No Blakod messages are sent during garbage collection to garbage collected objects.

The garbage collector next goes through every object and gives all marked objects a new object id in the object’s garbage ref field. It then proceeds to traverse every property of every object, every list node, user account, session, and timer and replaces any object id with the new post-garbage collection object id. Then, the object node array itself is compacted, so that unreferenced objects are deleted and all object nodes have their new object node id.
String garbage collection works much the same way. First, every property of every object is traversed, and all strings that are referenced are marked. All list nodes and other objects referenced by each traversed property are recursively traversed, thereby marking all strings referenced by any object or list node in the system. Each marked string is then given a new string id which is temporarily stored in each string node’s garbage ref field. Each object and list node is traversed and all references to strings are changed to refer to the string’s new post-garbage collection id. The string nodes are then traversed and non-referenced string nodes are deleted.
Timer garbage collection works much the same way, although it is a bit simpler. Timers aren’t garbage collected, because they are automatically deleted when they go off. At garbage collection time, each timer is given a new timer id. The lowest id timer becomes timer id 0, and each timer is given a new id one larger than the previous timer’s id. Then, each object and list node is traversed and timer id’s are changed to the new id. This allows timers to be freely used in Blakod without the fear that timer id’s could rollover 28 bits and cause problems.
As described earlier, BlakServ was designed to be a very stable server. In order to prevent crashes, many checks are performed on function return values which should be guaranteed. For example, in the garbage collector, for every list node that is attempted to be traversed, the list node id is checked to be valid. If a list node that is referenced does not exist, a “death by garbage collection” error is printed, and the server does not crash. However, with a serious error such as this, objects will be left with invalid references, which may cause the game not to function, depending on the specific Blakod. Checks are performed on objects, list nodes, strings, and timers, and all could report an error. Invalid references can only exist if there is a serious bug in either Blakod or BlakServ. Correct code will not generate these types of errors.

I performed some profiling tests on the server in the summer of 1995 which allowed me to increase the server performance by about 50% on a Pentium class machine. I achieved these gains by inlining the RetrieveValue function, changing a linked list of all loaded Blakod classes into a hash table, and giving the class structure a pointer to its parent class, rather than just the parent class id.

You will not get me to like garbage collection by changing it up and giving it a different name. I simply do not want it. And now you've gone and made it into a hash table because you read somewhere that access was O(1). Great, now the garbage collector has to deal with allocating a cockload of memory just to keep track of memory and the pauses are moved from scanning to allocation whenever the table it full. The next innovation well have GC in a GC to simplify garbage collection.

>>1
If you just copy pasted an internal document, we could get your fired. You realize that right?

>>6
copypasting internal document may get you sued, especially if some vandal uses it to damage company's services.

http://meridian59.com/about-early-history.php

>>6,7
Do you know how to search the web to verify things?

>>9
Yes.

>>8

In the summer of 1993, I had just finished my junior year at MIT

MIT people turn any project into a Scheme interpreter.

I thought that just re-implementing C lost the benefit of a simple language that more people could understand. Being at MIT, I was heavily influenced by the Scheme dialect of Lisp, and I also read quite a bit about Smalltalk.

>>11
Can you blame them?

>>13
Yes. They are overly arrogant.

" It was one of the early games written by programmers with a formal computer science background, a practice that is much more common today than in 1994. We believe that this kind of discipline helped make the game more stable, and allowed it to grow even after its original creators had left. In over 3 years of continual operation, the original server code has not crashed once, a record still unmatched today."