JODY POTTER | University RelationsMost of the time, the problem of legacy computer systems — old programs, often running on old hardware, too — is invisible to the average person. But when you are stuck at home, trapped in a race between past-due bills and a government stimulus check, the trouble becomes painfully clear. That was the case in the terrifying early days of the pandemic, when Americans learned that the federal government’s $1,200 per person stimulus checks might be delayed up to 20 weeks because the Internal Revenue Service still relies on applications designed and built in the 1960s, including the Individual Master File, which comprises data from 1 billion taxpayer accounts.
“If you are not the original author of legacy software, you approach it with no existing mental model for how the code is originally intended to work, nor any formal model of how the code actually works, intended or not.”
It’s not just the IRS. Millions of workers lost their jobs in spring 2020, overwhelming the creaky software powering unemployment systems in 19 states and led to weeks-long delays in accessing unemployment assistance. In desperation, New Jersey’s governor even made a public plea for volunteer COBOL programmers to help patch his state’s old code.
Legacy systems still used by airlines have led to the cancellation of thousands of flights. Insurance companies and banks also frequently rely on old and outdated software as well, and these legacy systems are vulnerable to hackers. The massive Equifax breach in 2017, which exposed the data of 146 million individuals, was traced to a vulnerability in a dispute-resolution program built in the 1970s.
How is this supposed to work?
Thomas Gilray, Ph.D., and his students use artificial intelligence (AI)-based programming languages to create simulations of large legacy systems in order to allow humans to experiment with approaches to modernizing or replacing those systems.Updating these old systems is not as simple as it may sound. Software updates always carry the risk of catastrophic failures, and the investment is massive. By one estimate, companies and governments worldwide have spent at least $2.5 trillion on replacing legacy IT systems. Once programmers start to make changes, they often discover that these efforts trigger a wave of inexplicable errors elsewhere. That $2.5 trillion figure includes $720 billion spent on efforts that eventually failed.
The Defense Advanced Research Projects Agency, or DARPA, is tackling these problems through its Verified Security and Performance Enhancement of Large Legacy Software program. V-SPELLS “aims to make it possible for developers to incrementally enhance existing legacy software components with new verified code and ensure that the resulting software will safely compose with an existing system,” according to an agency press release.
“If you are not the original author of legacy software, you approach it with no existing mental model for how the code is originally intended to work, nor any formal model of how the code actually works, intended or not,” said Thomas Gilray, Ph.D., assistant professor in the UAB Department of Computer Science.
Simulating systems to experiment with solutions
Gilray is co-director of the High Performance Automated Reasoning and Programming, or HARP, lab at UAB, which is pursuing an intriguing, mostly automated approach to making old software give up its secrets. He and his students use artificial intelligence (AI)-based programming languages to create simulations of large legacy systems in order to allow humans to experiment with approaches to modernizing or replacing those systems.
“Code often surprises its own writer. What else is a bug but that mismatch between expectation and reality?”
The HARP lab is now working on V-SPELLS through a subcontract with Galois, Inc., a company that focuses on software and hardware trustworthiness. “Our team’s focus within this larger project is mainly in exploring more sophisticated program-analysis techniques, iterative approaches with a human in the loop, and methods for scaling and parallelizing our systems to work well on very large and complex legacy codebases,” Gilray said. The end result, he said, is to allow “reasoning about code at scale — in the cloud and on supercomputers.”
Finding unpleasant surprises
“Code often surprises its own writer,” Gilray said. “What else is a bug but that mismatch between expectation and reality?”
Gilray’s research focus is program analysis: understanding code. “Simple program analyses can infer latent facts about program behavior that are implicit across a few lines of code but are written nowhere,” he said. “More sophisticated program analyses are essentially wholesale simulations of a codebase. Given that so much increasingly depends on the safety and correctness of code in the wild, I expect that improvements in program-analysis technology, over the next decade or so, will have a surprising, outsized real-world impact.”
“Given that so much increasingly depends on the safety and correctness of code in the wild, I expect that improvements in program-analysis technology, over the next decade or so, will have a surprising, outsized real-world impact.”
One of the tools that Gilray and his students use to explore and model legacy C or C++ code — and other similarly low-level, structured programming languages — is itself a language Gilray has developed called Slog. “Far from being an invention all our own, Slog is a major extension of a decades-old language called Datalog that originated in the early days of AI and has seen a resurgence of interest in recent years,” Gilray said. “It’s essentially a smart-database language that enables higher-order reasoning over its data, not just efficient storage and selection of data. Slog is designed to be both more terse and more expressive as an implementation compared to Datalog and related existing languages. A program in Slog consists of a set of high-level symbolic rules for deduction that are interpreted automatically on a database; it is naturally expressive enough to translate the math that designers of program analyses use to communicate our ideas to one another, mostly verbatim, into Slog code. Our dream is to enable designers of program analyses to develop easy-to-understand, high-performance analyses as easily as they can invent them conceptually and write them down.”
Coding an automated programming partner
Behind the scenes, Slog is built using techniques that Gilray developed in collaboration with Sidharth Kumar, Ph.D., a fellow assistant professor in the computer science department at UAB (and co-director of the HARP lab). These techniques enable fast, massively parallel relational algebra on databases that can scale from individual machines to computer clusters “to ‘the cloud’ and to some of the largest supercomputers in the world,” Gilray said.
“Our dream is to enable designers of program analyses to develop easy-to-understand, high-performance analyses as easily as they can invent them conceptually and write them down.”
How did he get interested in this research area? “Computer science is a great field in which to have an impulse for looking at the meta-level: to think about thinking, program tools for programming, etc.,” Gilray said. “Anything one can do as a programmer on the computer could conceivably be automated, so there is a natural draw to want to automate one’s own work as a programmer more completely. Understanding code is one of the hardest things I’ve learned to do, even with years of practice; so, the prospect of writing code that does that same work of writing and reasoning about code, automatically, perhaps better than I could, is a thrilling mission to be involved with.”
The idea is to give people the power to play to our strengths, Gilray says. “The research we are doing will help to empower human creativity while enabling computers to do the heavy lifting in reasoning about and checking our work.”
