While running test/compiler/jvmci/code/SimpleDebugInfoTest.java with -vmoptions:" -XX:+DeoptimizeALot -XX:CompileThreshold=100 -esa -XX:+VerifyStack" I got the following error.

Wrong number of expression stack elements during deoptimization
  Error occurred while verifying frame 0 (0..0, 0 is topmost)
  Fabricated interpreter frame had 2 expression stack elements
  Interpreter oop map had 3 expression stack elements
  try_next_mask = 1
  next_mask_expression_stack_size = 0
  callee_size_of_parameters = 0
  callee_max_locals = 0
  top_frame_expression_stack_adjustment = 1
  exec_mode = 0
  cur_invoke_parameter_size = 0
  Thread = 0x00007f57343ca000, thread ID = 9537
  Interpreted frames:
    sun.reflect.generics.parser.SignatureParser.parsePackageNameAndSimpleClassTypeSignature()Lsun/reflect/generics/tree/SimpleClassTypeSignature; (bci 95)
 - sp: 0x00007f56eddf84a0
 - thread: "MainThread" #12 prio=5 os_prio=0 tid=0x00007f57343ca000 nid=0x2541 runnable [0x00007f56eddf7000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_Java
Thread: 0x00007f57343ca000 [0x2541] State: _running _has_called_back 0 _at_poll_safepoint 0
   JavaThread state: _thread_in_Java
 - frame size: 34
 - interpreter_frame -> sp: 0x00007f56eddf8538
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/deoptimization.cpp:762
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/tkrodrig/ws/hs-comp/hotspot/src/share/vm/runtime/deoptimization.cpp:762), pid=9511, tid=9537
# guarantee(false) failed: wrong number of expression stack elements during deopt
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-02-01-191105.tkrodrig.hs-comp)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-02-01-191105.tkrodrig.hs-comp, mixed mode, tiered, jvmci, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/tkrodrig/ws/hs-comp/hotspot/test/JTwork/scratch/core.9511)
#
# An error report file with more information is saved as:
# /home/tkrodrig/ws/hs-comp/hotspot/test/JTwork/scratch/hs_err_pid9511.log
 Locks owned:
Mutex: [0x00007f5734015750/0x0000000000000001] tty_lock - owner: 0x00007f57343ca000
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 9537

Here is the scope desc from a failing run:
ScopeDesc(pc=0x00007f2fa167f23e offset=237e):
   sun.reflect.generics.parser.SignatureParser::parsePackageNameAndSimpleClassTypeSignature@95 (line 343)
   Locals
    - l0: stack[152],oop
    - l1: reg r8 [16],oop
    - l2: empty
   Expression stack
    - @0: reg r8 [16],oop
    - @1: 0

and the bytecode leading up to bci 95.

      92: aload_1
      93: iconst_0
      94: iconst_0
      95: anewarray #62 // class sun/reflect/generics/tree/TypeArgument

It certainly seems like it should have 3 elements on the stack. But maybe this is a case where the assertion needs to be adjusted.