Bug ID: JDK-8282295 SymbolPropertyEntry::set_method

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 17	JDK 18	JDK 19
17.0.4-oracleFixed	18.0.2Fixed	19 b13Fixed

Running tools/jpackage/share/jdk/jpackage/tests/AppVersionTest.java with -XX:+FullGCALot on macOS aarch64 triggers the following assert:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/Users/tohartma/jdk/open/src/hotspot/share/oops/oopHandle.hpp:53), pid=27741, tid=14343
#  assert(is_empty() || copy.is_empty()) failed: can only copy if empty

Stack: [0x0000000172384000,0x0000000172587000],  sp=0x00000001725857d0,  free space=2053k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x10c41f8]  VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5d8
V  [libjvm.dylib+0x10c4930]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40
V  [libjvm.dylib+0x5b5414]  report_vm_error(char const*, int, char const*, char const*, ...)+0x80
V  [libjvm.dylib+0x664630]  SymbolPropertyEntry::set_method_type(oop)+0xb4
V  [libjvm.dylib+0xfe1274]  SystemDictionary::find_method_handle_type(Symbol*, Klass*, JavaThread*)+0x1074
V  [libjvm.dylib+0x59fa58]  ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, int, bool*, JavaThread*)+0xdfc
V  [libjvm.dylib+0x5a0d6c]  ConstantPool::copy_bootstrap_arguments_at_impl(constantPoolHandle const&, int, int, int, objArrayHandle, int, bool, Handle, JavaThread*)+0x3f8
V  [libjvm.dylib+0x36bd18]  BootstrapInfo::resolve_args(JavaThread*)+0x6c8
V  [libjvm.dylib+0x36b4cc]  BootstrapInfo::resolve_bsm(JavaThread*)+0x520
V  [libjvm.dylib+0xfe2538]  SystemDictionary::invoke_bootstrap_method(BootstrapInfo&, JavaThread*)+0x3c
V  [libjvm.dylib+0xbdf5c0]  LinkResolver::resolve_dynamic_call(CallInfo&, BootstrapInfo&, JavaThread*)+0x34
V  [libjvm.dylib+0xbdea84]  LinkResolver::resolve_invokedynamic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0xb8
V  [libjvm.dylib+0x89837c]  InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x1d4
V  [libjvm.dylib+0x898674]  InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x268

Code/Assert was introduced by JDK-8249822.

[~dlong] found this.

Fix request [17u] I backport this for parity with 17.0.4-oracle. Simple change, low risk. Clean backport. SAP nightly testing passed.
22-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/271 Date: 2022-03-21 14:21:21 +0000
21-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk18u/pull/49 Date: 2022-03-15 16:40:11 +0000
15-03-2022
Fix Request (18u) This small fix prevents the intermittent failure described above. The risk is low because it just nulls out a handle whose oop was freed. The patch applied cleanly and was tested by running Mach5 tiers 1-2.
10-03-2022
Changeset: 3e4dfc63 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2022-03-08 16:10:26 +0000 URL: https://git.openjdk.java.net/jdk/commit/3e4dfc63e75db7e8ccbb21a831d8d86fb7c1ac4e
08-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7730 Date: 2022-03-07 16:53:38 +0000
07-03-2022
ILW = HLM = P3 (full GC is not a production option)
01-03-2022
The problem seems to be in Universe::release_fullgc_alot_dummy(): // No more dummies to release, release entire array instead _fullgc_alot_dummy_array.release(Universe::vm_global()); return false; OopHandle::release() doesn't zero out the handle, so what can happen is the next time we ask for an OopHandle, we can get the same one as _fullgc_alot_dummy_array. It looks like we can actually end up with multiple OopHandles using the same slot, because release_fullgc_alot_dummy() will continue to release the same handle over and over if resolve() does not return NULL.
24-02-2022
I can also reproduce this on x86_64 with a gcc build (see attached hs_err_pid1765123.log).
23-02-2022
Reproducible on linux aarch64 and linux x64 with clang versions clang version 12.0.1 (Red Hat 12.0.1-4.0.1.module+el8.5.0+20428+2b4ecd47) and Ubuntu clang version 12.0.0-3ubuntu1~20.04.4 respectively.
23-02-2022