The positions of static stubs / trampolines should be like:

```
[Verified Entry Point]
    ...
    ...
    ...
[Stub Code]
    <static stubs and trampolines>
[Exception Handler]
    ...
    ...
[Deopt Handler Code]
    ...
    ...
```

Currently after we have the shared static stubs/trampolines in JDK-8280481 and JDK-8280152 :

```
[Verified Entry Point]
    ...
    ...
    ...
[Stub Code]
    <static stubs and trampolines>
[Exception Handler]
    ...
    ...
[Deopt Handler Code]
    ...
    ...
    <shared static stubs and trampolines> // they are presented in the Deopt range, though do not have correctness issues.
```

For example on x86:

```
[Verified Entry Point]
  ...
[Stub Code]
  0x00007fac68ef4908: nopl 0x0(%rax,%rax,1) ; {no_reloc}
  0x00007fac68ef490d: mov $0x0,%rbx ; {static_stub}
  0x00007fac68ef4917: jmpq 0x00007fac68ef4917 ; {runtime_call}
  0x00007fac68ef491c: nop
  0x00007fac68ef491d: mov $0x0,%rbx ; {static_stub}
  0x00007fac68ef4927: jmpq 0x00007fac68ef4927 ; {runtime_call}
[Exception Handler]
  0x00007fac68ef492c: callq 0x00007fac703da280 ; {runtime_call handle_exception_from_callee Runtime1 stub}
  0x00007fac68ef4931: mov $0x7fac885d8067,%rdi ; {external_word}
  0x00007fac68ef493b: and $0xfffffffffffffff0,%rsp
  0x00007fac68ef493f: callq 0x00007fac881e9900 ; {runtime_call MacroAssembler::debug64(char*, long, long*)}
  0x00007fac68ef4944: hlt
[Deopt Handler Code]
  0x00007fac68ef4945: mov $0x7fac68ef4945,%r10 ; {section_word}
  0x00007fac68ef494f: push %r10
  0x00007fac68ef4951: jmpq 0x00007fac70326520 ; {runtime_call DeoptimizationBlob}
  0x00007fac68ef4956: mov $0x0,%rbx ; {static_stub} // <---------- here
  0x00007fac68ef4960: jmpq 0x00007fac68ef4960 ; {runtime_call}
  0x00007fac68ef4965: mov $0x0,%rbx ; {static_stub} // <---------- here
  0x00007fac68ef496f: jmpq 0x00007fac68ef496f ; {runtime_call}
  0x00007fac68ef4974: mov $0x0,%rbx ; {static_stub} // <---------- here
  0x00007fac68ef497e: jmpq 0x00007fac68ef497e ; {runtime_call}
  0x00007fac68ef4983: hlt
  0x00007fac68ef4984: hlt
  0x00007fac68ef4985: hlt
  0x00007fac68ef4986: hlt
  0x00007fac68ef4987: hlt
--------------------------------------------------------------------------------
[/Disassembly]

```

It can be simply reproduced and dumped by `-XX:+PrintAssembly`.

Though the correctness doesn't get affected in the current case, we may need to move them to a better place, back into the `[Stub Code]`, which might be more reasonable. Also for the performance's sake, `ciEnv::register_method()`, where `code_buffer->finalize_stubs()` locates currently, has two locks `Compile_lock` and `MethodCompileQueue_lock`. So I think it may be better to move `code_buffer->finalize_stubs()` out to C1 and C2 code generation phases, separately.

BTW, this is the "direct cause" of [JDK-8302384](https://bugs.openjdk.org/browse/JDK-8302384) because shared trampolines and there data are at the end of compiled code. Though for that issue, the root cause is still from the Binutils. Please see [JDK-8302384](https://bugs.openjdk.org/browse/JDK-8302384) for more details.