RFR: 8261585: Restore HandleArea used in Deoptimization::uncommon_trap

[Hui Shi]

Add HandleMark in Deoptimization::uncommon_trap before Deoptimization::fetch_unroll_info_helper, avoid reference hold in HandleArea increase object lifetime. Then object lifetime will be consistent with/without uncommon trap.

For test case in commit, WeakReference is expected cleared after GC, but it fails with option "-XX:-Inline -XX:-TieredCompilation -XX:CompileCommand=compileonly,UncommonTrapLeak.foo -XX:CompileThreshold=100 -XX:-BackgroundCompilation". Reference's referent object is still alive after "foo" finish, because with uncommon trap, oops are recorded in HandleArea and HandleArea is not poped when uncommon trap process finish.

When Deoptimization::fetch_unroll_info_helper return, all oops in deoptimized frames are saved in Deoptimization::UnrollBlock or Thread data structure, HandleArea can be poped safely.
1. local and expression oops raw address is stored in vframeArrayElement _locals/_expressions as intptr
2. return value restore, raw oop recoreded in frame // (oop *)map->location(rax->as_VMReg());
3. exception object, raw oop recorded on Thread._exception_oop

In deoptimize blob entry, JRT_BLOCK_ENTRY(Deoptimization::fetch_unroll_info) has HandleMarkCleaner, HandleArea is restored after Deoptimization::fetch_unroll_info_helper finish. So it's also safe to add HandleMark in Deoptimization::uncommon_trap before fetch_unroll_info_helper.

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

Commit messages:
 - 8261585: Restore HandleArea used in Deoptimization::uncommon_trap

Changes: https://git.openjdk.java.net/jdk/pull/2526/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2526&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261585
  Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2526/head:pull/2526

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