What Managed Runtime Environments (MRTEs) Mean To You

by Regina Preciado

Introduction

"Microprocessor software is currently witnessing the most important behavioral change since the move from assembly language to high-level language programming," writes Intel senior fellow Justin Rattner in his introduction to the Managed Runtime Environment issue of the Intel Technology Journal (Volume 7, Issue I).

It's a change that affects software developers, strategists, product managers, CxOs, and pretty much everyone else associated with computers. Done right, the change will be invisible to end users other than those perceptive few who might notice that their applications crash less often, run faster, and integrate better with other applications.

MRTEs have infiltrated the collective independent software vendor (ISV) consciousness since Java* exploded into the mainstream in the mid-1990s. It's not just the programmers talking about it-thinkers at all levels are eyeing MRTEs with a mixture of anticipation and skepticism. Anticipation because if MRTEs live up to their promises, development teams can breathe easier about other paradigm shifts occurring in the immediate future. Skepticism because of the tendency in our industry for promises to crumble like so much burnt toast as soon as the products reach the market (assuming they get there in the first place).

But it looks like MRTEs is here to stay. Keith Yedlin, Intel senior engineer and leading thinker on MRTEs, predicts that 70 percent of developers will be using MRTEs by 2005. And that's one reason why "Intel views MRTEs as one of the important areas we will spent a lot of effort on," according to Jesse Fang, director of Intel's programming systems lab in the microprocessor research labs.


What Is a MRTE?

A MRTE, also known as a dynamic runtime environment, is a platform that abstracts away the specifics of the operating system and the architecture running beneath them.

Instead of barking orders directly at the processor, developers write to a runtime that handles many of the generic tasks that the programmers used to have to anticipate and build in. For example, the managed runtime can handle things like heap management, security, class loading, garbage collection, and memory allocation, freeing developers to concentrate on the business logic specific to their application. Because of the runtime's close relationship with the operating system and architecture, it's often called a "virtual machine."

"It's a way of making use of the capabilities that the processor and operating system provide without actually having to create the processor and operating system," explains Intel technical marketing engineer, Paul Steinberg. "The developer writes applications that are installed and run on top of 'virtual machines' created by the runtime. Ideally, the runtime then translates the application for many operating systems on numerous devices."

Before Java spilled the beans way back in '95, runtime was m ostly confined to deepgeek communities like SmallTalk* user groups. Java was hailed as a boon to Internet developers whose applications need to run on all kinds of systems and devices. Programmers used a library of Java APIs and wrote in Java code and were able to deploy the results on any platform that spoke Java (with varying levels of success).

Microsoft one-upped Sun Microsystems a few years later when they released .NET*, which allowed programmers to use just about any programming language in existence, rather than confining them to a single language.


The Next Big Thing

Managed runtime is "the right way to go for cost-conscious IT organizations," says Yedlin. "The more information you need to handle to build the application, the harder it is and the longer it takes to build. MRTEs enable developers to take a 'minimalist' approach."

Here's how that minimalism translates into better business:

  • Faster time to market: It doesn't take as long to write an application because developers don't have to code the functions the managed runtime handles.
  • Safer code: Managed runtimes promote safer code by taking some of the security and hardware management responsibility off of developers.
  • Lower deployment costs: Component-based architecture makes it easier and faster to deploy applications in an enterprise environment characterized by multiple platforms, devices, and legacy systems.
  • Better quality software: Managed runtime frees developers to focus on the business logic and code specific to the application while reducing the number of coding errors.
  • Cross-platform: With the runtime to translate between your application and the operating system, you can code once while allowing customers to run the application on multiple systems. (Yedlin stresses the importance of testing on all platforms rather than assuming the code will just work.)
  • Code reach: Runtime is a major step in the evolution of object-oriented programming, enabling modular code that can be recycled to new applications and new systems.

 


Tune-up: Runtime Depends on Architecture

"Intel has taken a special interest in [runtime] environments as they may lead to new architectural and micro-architectural elements in future designs," writes Rattner.

In other words, runtime is tied to architecture. And it works best in tandem with architecture tuned to support it.

Intel has worked with key ISVs, including BEA and Microsoft, to pinpoint managed runtime's architecture dependencies and to build support for those dependencies into Intel's hardware. (You can download BEA WebLogic Jrockit, which is optimized for Intel® architecture, here.)

"Intel continues to invest in extensive analysis and characterization of MRTEs' architectural dependencies," says Yedlin. "That data has a strong impact on the direction of our architecture moving forward."

One moth in the Harvard Mark II* of MRTEs is the risk of bloated code as the runtime attempts to cover every possibility, even if unneeded by a particular system. XML-based applications already require more MIPS to execute than traditional applications that don't use XML, so any extra code growth only slows things down. To combat this, researchers are looking for-and finding-ways to reduce the number of MIPS required for runtime environments.

Fang reports that "one version of [Intel's] code is in open source, to promote research outside Intel as well as inside." (You can learn more about the Open Runtime Platform here, or download it here*.)


Looking Ahead

Hyper-Threading Technology is already having a significant impact on the performance of applications designed to take advantage of MRTEs. It's Moore's Law in action, extending the hardware's capabilities through parallelization: an HTT-enabled processor executes several instructions at once, independent of the code path.

This ability to extend the growth of gates-that is, to make more processor resources available to applications-while managing the explosion of power consumption has succeeded in the real world as well as in the research lab. "We've seen significant performance improvements when combining MRTEs with Hyper-Threading," says Yedlin, who points out that managed runtimes reduce the complexity of writing threaded applications and enable enterprise developers to safely and quickly exploit the value of Hyper-Threading.

"We encourage software developers to adopt virtual machine from vendors – like BEA and Microsoft – that have worked with Intel," says Yedlin. "That way developers can benefit from the value that tuned architecture brings to runtimes."


Additional Resources

For more information on topics covered in this article, see:

 

Intel, the world's largest chipmaker, also provides an array of value-added products and information to software developers:

 


About the Author

Regina Lynn Preciado writes often about technology from her home in Los Angeles.

Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.
Tags: