Vulcan Announcement

From Jim Starkey on the Firebird Development List 16th December 2003

I've been hired by IBPhoenix to product a 64bit, SMP-friendly reference port for Firebird. The formal deliverable will be for 64bit Solaris Sparc, though I plan to produce AMD64/Opteron versions for WinXP and Linux on the way. I'm calling it Project Vulcan (I wanted to call it IBAlbuquerque but Mozilla is already using the name).

The requirement is for a thread-safe, embeddable, 64bit versions capable of 3X performance on a four processor system (or run out of disk bandwidth trying) in a three month period. The resulting code will be released under the standard Interbase Public License.

Given the aggressive schedule, I'm going to deviate somewhat from the normal development methodology. I will be starting with the Firebird 2 code base (as of last Thursday), but will be working out of a private CVS tree. If folks are interested, I'm willing to grant read-only access to the tree as long as things don't get too crazy. The plan is for IBPhoenix to re-integrate the code bases at the end of the project. If there are volunteers, it may be possible/feasible to migrate changes from Vulcan to Firebird enroute, but the schedule dictates that I work without external dependencies. My goal is to produce a working, maintainable, fast, lightweight system. If folks want to have a brawl over the political correctness of my code, they can do so after I'm done. Ann has been designated by IBPhoenix to lead the reintegration phase.

I'd be more than delighted to talk and argue about the project as we go, treating the process as an extended masters class. If folks are happy, we can do it here on the developers list. If not, I'll start up an ad hoc list for the duration of the project.

My primary development platforms will be WinXP (32bit and 64bit) under MSVC with frequent checkouts on Linux (RedHat 32bit and probably Suse64 bit), and finally Solaris.

Subject to delivery of my development hardware, my plan of attack is:

• Clean up the layering: server / Y-valve / subsystems. I will rewrite why.c to use a canonical C++ class as the sole interface to data management systems, which can be either linked or dynamically loaded. There will be only one Y-valve component shared by client and server processes. During the rewrite I will sanitize the code base of modules not under the Interbase Public License. Introduce thread synchronization technology (fast lock shared/exclusive monitors) from Netfrastructure.
• Remove dead code from the Firebird code base. GDS_VAL, WAL, thread_enter/thread_exit are all endangered.
• Reconstitute major engine components as proper C++ objects. The cache manager (CCH) is the priority candidate.
• Add monitors for major data structures. Note: delivery requirements dictates a 64bit development version before thread safety, so there is a race condition between hardware delivery and thread safety. The monitor code will be in mainline, not conditionalized.
• 64bit compilation and execution on Microsoft, gcc, and probably Sun compilers. Crap and dead conditionals that get in my way will be dealt with ruthlessly.
• Cleanups, encapsulation, simplification, and exception handling will happen as needed. If the std:: crud gets in my way, I'll replace it with something lighter weight and more portable. I generally restrict myself a C++ subset roughly consistent with Java, so again, if provoked, I'll substitute straightforward code for arcanity (gosh, until I read the Firebird code, I didn't even know you could call an object's destructor).

I think this is going to be fun. And I think it will be a bang-up product at the end. I think the AMD 64bit architecture is the best thing since the death of the PDP-11.