Dynamic Languages have been around for a long time (Perl 5 was released in 1994).
They have traditionally run on top of loosely-defined C runtimes, which are custom to each language. Sometimes they have a type of virtual machine used for execution - but not one which corresponds closely with the Java or .NET VMs.
For many reasons, not least of which taking advantage of the more enterprise features of the VMs, and interoperating with modules written in other languages, there are many groups and developers interested in running dynamic languages on the general purpose VMs.
The problems involved in doing this are manifold - the most valuable languages (ie those with most developer marketshare) were not designed with the Java or .NET VM in mind - and the VMs were designed with type and dispatch systems which are not at first glance suitable for dynamic languages.
In the .NET case, the Compilers group at MSFT are producing extra functionality for dynamic dispatch for C# 4.0, and with IronPython and IronRuby are producing a new component called the Dynamic Languages Runtime. John Lam's blog at http://www.iunknown.com/ is a good place to start for the .NET side of things.
For Java, the work is centred around JSR 292 (see http://jcp.org/aboutJava/communityprocess/edr/jsr292/) - and while initially attention was focused around a new bytecode invokedynamic (to add to invokevirtual and friends) there is some debate as to whether a new opcode is the right approach - or whether the same end could be achieved by using invokeinterface as the opcode, and a special class (in the java.dyn package, perhaps) which was treated in a special way by the runtime.
This second approach (classes with special treatment by the runtime) is apparently already used by the implementations of other VM features in HotSpot, so may prove to be the approach used. People still talk about invokedynamic as a name for the featureset, even without the new bytecode.
Next time I'll post my build instructions for trying to get OpenJDK 7 with invokedynamic on Mac. This will only work on Leopard, as Tiger's build infrastructure is not quite up to it.