Agentless Backup is Not a Myth

Adobe MAX Europe Adobe Systems has provided more details on a research project that converts and compiles C and C++ to ActionScript and brings raw speed to the Flash virtual machine.

Alchemy enables re-use of existing C libraries within the Flash runtime. Examples shown here at MAX Europe include OpenSSL encryption code, code to generate image files in PNG format, and code to preview PDF documents in Flash. Part of the rationale is that there is more open-source code in C or C++ than in any other language.

This means you might also use Alchemy to optimize Flash applications, and Adobe Flash Player engineer Jim Corbett said he expects this kind of usage to be common. But why is Alchemy code faster? And why has Adobe not optimized the ActionScript runtime to run normal code equally well?

The answer is Alchemy code runs in a different way. ActionScript 3.0 is a modern garbage-collected language similar in many respects to Java or C#. This imposes a performance overhead, and Scott Petersen, who developed Alchemy, found his early experiments impossibly slow as a result.

Adobe solved this by adding a special per-application byte array in the Flash 10 player. This becomes the memory available to Alchemy code. "All the code does is jump around a byte array," according to chief scientist Mark Anders. The consequence is that the code runs up to 25 times faster, but the developer has to manage memory just as with native C programming.

That said, errors like buffer overruns or memory leaks, while they may crash the Alchemy application, should not have wider consequences. "All the security stuff works exactly as it does in ActionScript today," said Corbett.

There are other reasons why Alchemy code runs faster. The project uses the Low-Level Virtual Machine (LLVM) compiler, an open source project that compiles C and C++ to optimized intermediate code. Alchemy then compiles this intermediate code to ActionScript, which is not human-readable. "The LLVM tools optimize a lot better than the ActionScript tools," Corbett said.

Alchemy opens up a number of intriguing possibilities. One is support for other dynamic languages within Flash, using existing open source interpreter code.

"We've been working on Ruby and Lua and even Java," Corbett told MAX. It is also ideal for number-crunching algorithms and will be eyed with interest by game developers.

It glitters, but it 'ain't gold

Unfortunately, there are some snags. One is that all applications that use Alchemy include the compiled version of the C standard library, which adds around 140K to the download size. It is possible that Adobe will create a signed version of this library, enabling it to be installed in a local cache where it would be shared. However, apparently all Alchemy code is poorly optimized for size as yet.

Another problem is that while Alchemy code itself is fast, marshalling objects across the boundary between normal ActionScript and Alchemy code is slow and difficult to code, though there is a wrapper library called GlueGen that simplifies this to some extent. It is not suitable for applications that make a lot of these transitions. Debugging is currently primitive. Adobe will not say when Alchemy will be ready for production use or even if it will ever make it out of the Adobe Labs research area - though given the high level of interest that seems likely.

This is also a project that may help Adobe in its battle with Microsoft for developer mindshare. Silverlight's .NET runtime executes non-visual code faster than ActionScript in some tests, but probably not as fast as Alchemy, and if Adobe delivers the ability to execute other dynamic languages via an Alchemy interpreter, that could be an answer to Microsoft's Dynamic Language Runtime for .NET. ®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery