RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

[Vladimir Ivanov]

It's another attempt to fix JDK-8256368 (previous one was #1453). 

@coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 

After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.

Original description:

Method linkage of invokehandle instructions involve an upcall into Java
(MethodHandleNatives::linkMethod), but the result is not cached. Unless the
upcall behaves idempotently (which is highly desirable, but not guaranteed),
repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
switching to a higher tier involves call site re-resolution in generated code,
but re-resolution installs a fresh method which puts execution back into
interpreter.

(Another prerequisite is no inlining through a invokehandle which doesn't
normally happen in practice - relevant methods are marked w/ @ForceInline -
except some testing modes, -Xcomp in particular.)

Proposed fix is to inspect ConstantPoolCache first. Previous resolution
attempts from interpreter and C1 records their results there and it stabilises
the execution.

Testing: hs-tier1 - hs-tier4

-------------

Commit messages:
 - Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

Changes: https://git.openjdk.java.net/jdk/pull/7429/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7429&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256368
  Stats: 47 lines in 5 files changed: 22 ins; 12 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7429.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7429/head:pull/7429

PR: https://git.openjdk.java.net/jdk/pull/7429