Change handling of edge case.

Generally speaking, you can't create an instance of a class before
the class is initialized.  When you're talking about java.lang.Class
itself, this doesn't apply.  We were trying to sneak in a just-in-time
initialization, but the recent addition of SMP-mandated opcode rewrites
screwed things up a bit.

Happily, the creation of the java.lang.Class class object now happens
at a known time, which means we can explicitly initialize the class
at the right time (when it's far enough along to be able to execute
the class initializer, but before anything tries to use a virtual
method or instance field in java.lang.Class).

Also, changed a LOGE+abort to a simple assert.  The test in question is
performed earlier during linking, so this doesn't merit more than an
assertion.

Bug 3045762.

Change-Id: Ifffb5083a3de108e1d91b3de7b75fd5e97705912

Conflicts:
	vm/oo/Class.cpp
Fix clazz->initThreadId ordering

We want to make sure that, if the class we're interested in is in
CLASS_INITIALIZING, we're not loading a stale value for initThreadId.
This is an issue in dvmIsClassInitializing, which reads the value
without holding a lock.

Bug 3069119

Change-Id: I5b492249429cd7a8fbffd526b9a546fb5fb8e6bd

Conflicts:
	vm/oo/Class.cpp
Avoid lookup of loadClass().

Fix a TODO item: do the lookup of ClassLoader.loadClass() during init
instead of on every class load through a non-bootstrap loader.

Change-Id: Iebd145a721937bec7c09b0a7b7dbd78da8083cbe

Conflicts:
	vm/oo/Class.cpp
Don't do ClassLoader prep in dexopt.

The code to cache the method info for ClassLoader.loadClass() was
happening in dexopt, which is a problem when you're optimizing core.jar.
This splits it out into a different function, which the dexopt startup
doesn't call.

Change-Id: I0bd5b9323b65e8f152b2ab4ea8e58fcf0039e53c
Track result from dvmCallMethod

When dvmCallMethod returns an object reference, we need to ensure
that the GC doesn't release or relocate the storage.  Unless we have
a clear view of how the object is used, we need to explicitly track
and release it.

This adds additional tracking, or comments indicating that explicit
tracking is not necessary.

On a similar note, clearing/restoring a pending exception requires
explicit tracking of that exception, since there's a fair chance
that it's no longer in the root set.  That needed fixing in a couple
of places.

Bug 3009076.

Change-Id: I39def8c3a5a628f0ee86fc094e34d7c69248c28b

Conflicts:
	vm/Debugger.cpp
	vm/Properties.c
	vm/oo/Class.cpp
Verify method invocation type.

Dalvik provides five different ways to invoke a method (virtual, super,
direct, static, interface).  Using a virtual invoke instruction to call
a direct method will not produce the desired results.

This adds a test to the verifier that ensures the method targeted by
an invocation instruction is of an appropriate kind.

Bug 3082885.

Change-Id: Iacf14b9b3959a0894d89d727286e10e3ecf72680

Conflicts:
	vm/analysis/CodeVerify.cpp
Keep track of debugger call results

The debugger can execute arbitrary methods in threads that are stopped
at a breakpoint.  The result is passed back from the target thread to
the debugger through the JDWP thread.  During this time, nothing else
has a copy of the return value, so if it's an object reference we need
to make sure the GC doesn't move or discard it.

The object is added to the "GC don't touch" list by the JDWP code,
but it was happening after the object was passed between threads.
We now register the object right after we get it.

Also, don't call dvmAddTrackedAlloc on a null object.

Bug 3009076

Change-Id: I5ab07a70ad7141b6867707c75843cfb60c35446d
Bump version.

Increment the minor version post-GB.  Increment DALVIK_VM_BUILD, which
should've happened when I added return-void-barrier.

Change-Id: I65480ced9183d0e3c84be2c1eeb9670017bbbc8f
Minor rename.

Rename two dummy-result variables to "unused".

Change-Id: Ib3e49436904123c6ceebe9bfb6e461f654209b23
Fine-tune the instructions on the method invocation path.

1) Initialize the register and out sizes for callee methods through
   constant moves.
2) Eliminate an unnecessary load of Dalvik PC for chained and
   native callees.

Improved method invocation performance by ~3%.

Change-Id: Iead1276eed0ba527e82eb876f08d169ab9b496b2
Switch to VMWAIT before sending to DDMS

If you stop DDMS with Ctrl-Z, packets sent from the VM will start
to back up and eventually the network write will block.  The VM was
doing the write in "running" state, which meant that if another thread
tried to GC it would be unable to suspend the stalled thread and the
VM would abort.

Now when this happens the affected thread(s) will be quietly stuck until
DDMS is resumed.  (We may want to fix that eventually.)

Bug 3101425.

Change-Id: Ide83c4622137e24c23ee85c006b497d84cf5006b
Open hprof files with O_TRUNC to avoid partial overwrites of existing files

Change-Id: I97a89071ad766005bb9f91661185dd901a35ae03
Export dvmIsValid card.

Change-Id: If92998de87db61cad75c7affa1500aed582f9687
Remove an obsolete debugging message.

Change-Id: Idb6af743bdd2e60a64d8ba8488d373f1724be3a2

Conflicts:
	vm/alloc/Verify.cpp
Fix a typo in the return type of dvmIsValidCard.

Change-Id: I518751b338e373d63a975c55320200348fa94b91
Improve the error report generated by the card table verifier.

With this change, when a gray object has been found on an unmarked
card all references are sent to the log stream.  This will usually
provide enough context to diagnose issues with the write barrier.

Change-Id: Ib6b7d98160e18393f54fc6ebc38c9ca9ca7dad2e
Fix build
Fix debug statements.

Shows up without NDEBUG.

Change-Id: I1270266369beb783242283af60ee268118c8fb3d

Conflicts:
	dexopt/OptMain.cpp
	vm/Sync.cpp
	vm/analysis/DexPrepare.cpp
Improve the card table scan.

Instead of scanning the table on card at a time, leverage a few
observations to make the scan somewhat more efficient.  First, fewer
than 1% of cards are dirtied during the concurrent mark.  We can scan
the card table by words instead of inspecting cards individually.
Second, dirtied cards tend to appear in clusters and are often
adjacent to one another.  Instead of starting scans at each dirty
card, we scan the objects on consecutive cards together by resuming
the scan at the lowest address visited.

I have not been able to get good profiling data from the VM so I am
not sure how much this helps.  This code may need some refining once
we get our hands on applications with larger heaps.

Change-Id: I30bc6bb14bc268fe404bc1629e44247f1ef8a6f2

Conflicts:
	vm/alloc/MarkSweep.cpp
Remove armv4t support.

This was never finished, and hasn't been maintained. And the hardware's
totally obsolete.

Change-Id: Icbf78e507de3b8be8a8f995b8423cc3c678ab0d3

Conflicts:
	vm/mterp/out/InterpAsm-armv4t.S
	vm/mterp/out/InterpC-armv4t.cpp