From a project management perspective, it was quite challenging to provide the customer with the visibility expected to measure progress and track changes since the database engine was huge and the testing phase only started when we were a significant way into the project. Though we had in-house IA-64 servers to work on, the customer had a full-fledged development team that was working in parallel to add/modify/remove some application features. This led to instances where the customer’s team used to update the source tree and affect our internal source tree. To sync up with the in-house team and up-to-date all the time was a big challenge.

Even with considerable IA-64 migration expertise, the size, complexity, and the complicated development environment (low-level assembly/machine instructions, and ABI) of the application was of a different scale. This meant a huge learning curve but with little time to master it. Even the test suite was comprehensive and had to be understood properly to make sure the acceptance criteria were met.

The Road Traversed
A significant amount of time was spent understanding the existing application (architecture, design, functionalities, etc.) as well as the intricacies of IA-64. Knowledge sharing with the application experts on the client’s side was useful in avoiding delays and possibly reinventing things on our own.

We followed an iterative approach in this project. Using the client’s help, we broke functionalities down to a list of language constructs and features to be ported in order of importance. We also worked in an iterative fashion to have more commands/constructs ported at the end of the each iteration. At every iteration we ported the required assembly files, runtime, and dynamic machine code generation and tested the product for the correctness of the feature.

Although this project was meant to support IA-64 on Linux and HP-UX, we got things working on HP-UX/IA-64 and then reused most of that work to get Linux/IA-64 working. This approach was so successful that we needed just a 10% incremental effort to get the second combination working.

Caution was taken not to disrupt any existing 32-bit platforms, define appropriate portable macros, and use system-defined portable data types instead of standard data types. The application was set up on a reference 32-bit machine to make sure there were no regressions.

Drilldown
We defined the necessary generic structures and unions to create the templates and the macros necessary to encode machine instructions to take care of the conflicting endian support of Linux and HP-UX. This made things very generic and supported further encoding of any additional instructions in the future.

The necessary memory barrier macros were defined and used in the code to overcome the memory-ordering issue in multiprocessor environments.

Performance Tuning and Testing
We used the PBO (profile-based optimization) feature provided by HP’s aCC on HP-UX and Intel’s icc on Linux to demonstrate the performance improvement. We added the necessary hooks to the database engine’s existing development environment to streamline this exercise.

In addition to the application’s testing framework, we built an exhaustive test plan and created a detailed dashboard to share the progress of the project. The progress of the project was a direct measure of the completeness of the dashboard. This offered greater visibility into the progress and made us and the customer more confident about the approaching milestones.

Conclusion
Considering the nature of databases, IA-64 offers significant advantages in terms of scalability and performance. The journey toward IA-64 can be challenging even for in-house development teams, considering that the skills required are related to migration and 64-bit architecture. But with sufficient planning, hiring migration experts, and using proven software migration processes, migration projects can be executed in a cost-effective manner in a predictable time frame.