% adb forward tcp:8000 tcp:8000

and then connect to it with your favorite debugger (using jdb as an example here):

% jdb -attach localhost:8000

When the debugger attaches, the VM will be in a suspended state. You can set breakpoints and then tell it to continue.

You can also connect through DDMS, like you would for an Android application. Add, to the "dalvikvm" command line:

-agentlib:jdwp=transport=dt_android_adb,suspend=y,server=y

Note the transport has changed, and you no longer need to specify a TCP port number. When your application starts, it will appear in DDMS, with " " as the application name. Select it in DDMS, and connect to it as usual, e.g.:

% jdb -attach localhost:8700

Because command-line applications don't include the client-side DDM setup, features like thread monitoring and allocation tracking will not be available in DDMS. It's strictly a debugger pass-through in this mode.

See Dalvik Debugger Support for more information about using debuggers with Dalvik.

The Dalvik VM can also be used directly on the desktop. This is somewhat more complicated however, because you won't have certain things set up in your environment, and several native code libraries are required to support the core Dalvik libs.

Start with:

You should see something like:

This configures you to build for the desktop, linking against glibc. This mode is NOT recommended for anything but experimental use. It may go away in the future.

You may see TARGET_BUILD_TYPE=release or =debug or possibly nothing there at all. You may want to replace the lunch command with choosecombo Simulator debug sim eng.

Build the world (add a -j4 if you have multiple cores):

When that completes, you have a working dalvikm on your desktop machine:

To actually do something, you need to specify the bootstrap class path and give it a place to put DEX data that it uncompresses from jar files. You can do that with a script like this:

The preparation with dx is the same as before:

As above, you can get some info about valid arguments like this:

This also shows what options the VM was configured with. The sim "debug" build has all sorts of additional assertions and checks enabled, which slows the VM down, but since this is just for experiments it doesn't matter.

All of the above applies to x86 Linux. Anything else will likely require a porting effort. If libffi supports your system, the amount of work required should be minor.