Reinventing the wheel!
Seriously. As I write my own hashmap implementation in C, I'm wishing I had access to the STL. Fortunately, this is for the bootstrap loader in M2VM, so it only needs to index the bootstrap classes. There are 14 (see footnote), so if I take a shortcut and make lookups O(n), nothing will catch fire.
M1 avoided this whole issue by hardcoding the bootstrap classes, creating them directly from the C code. This is rather icky and makes development a pain. It's also silly in terms of M2VM, since none of these classes have any distinguished role from the VM's perspective.
Footnote: to start the userspace classloader, written in Mongoose, the M2VM needs the following classes: Object, Class, Nil, Boolean, True, False, SmallInteger, Character, String, Method, Array, ByteArray, MethodContext, and BlockContext. Character is technically optional, but I'm including it to ensure that Strings are fully functional. Object is also technically optional, as Mongoose has no distinguished root class, but it makes the class graph complete.
Unlike most Smalltalk-derived VMs, the Symbol class — which represents unique, interned Strings, for message sends and the like — is not distinguished. It's implemented entirely in userspace using a pretty standard GoF flyweight pattern.