Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2190678 | 7 | Christian Thalinger | P3 | Closed | Fixed | b87 |
JDK-2197984 | 6u23 | Christian Thalinger | P3 | Resolved | Fixed | b01 |
JDK-2199934 | 6u22m | Christian Thalinger | P3 | Resolved | Fixed | b01 |
JDK-2193588 | 6u21p | Christian Thalinger | P3 | Resolved | Fixed | b03 |
Passing a null pointer to an InvokeDynamic function call, like:
MethodHandle mh = null;
InvokeDynamic.<void>funcall(mh);
should lead to a NullPointerException. But with current HotSpot we hit a guarantee:
# Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448
# Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)")
MethodHandle mh = null;
InvokeDynamic.<void>funcall(mh);
should lead to a NullPointerException. But with current HotSpot we hit a guarantee:
# Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448
# Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)")
- backported by
-
JDK-2193588 JSR 292 MethodHandles adapters should be generated into their own CodeBlob
- Resolved
-
JDK-2197984 JSR 292 MethodHandles adapters should be generated into their own CodeBlob
- Resolved
-
JDK-2199934 JSR 292 MethodHandles adapters should be generated into their own CodeBlob
- Resolved
-
JDK-2190678 JSR 292 MethodHandles adapters should be generated into their own CodeBlob
- Closed
- relates to
-
JDK-6939731 JSR 292 Zero build fix after 6934494
- Resolved