Yes, the application is running inside of a virtual machine.  The
virtual machine is responsible for the JIT and garbage collection
functions of the application (among other lesser things, of course).

I presume by AOT you mean "ahead of time", i.e. what's commonly known as
a native compiler?

The native compiler will generate code that causes garbage collection to
happen.  The exact details of the garbage collector (whether it's a
parallel thread or not, etc.) will depend on the native compiler, and
possibly on which options you give it when compiling.

Modern JVM implementations of Sun (and probably of other vendors as well) are based on HotSpot
technology, which includes a bytecode interpreter, a bytecode-to-native compiler (HotSpot compiler),
memory management and garbage collection functionality.

You'll find a more detailed explanation of all of this at
<http://java.sun.com/docs/books/performance/1st_edition/html/JPAppHotspot.fm.html>

Regards,
Z.

There is a run time that converts JVM byte codes to native. Other
modules handle gc in the same sort of a way in a pure interpreter,
though the move is to generational collectors rather than simple
mark/sweep.  see http://mindprod.com/jgloss/garbagecollection.html

There is nothing that stop there from being dozens of other threads in
an AOT, any more than you could not have dozens of threads in a C++
program.