JDK-8080157 : assert(allocates2(pc)) failed: not in CodeBuffer memory
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-05-12
  • Updated: 2019-11-29
  • Resolved: 2015-06-20
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 8 JDK 9 Other
8u221Fixed 9 b72Fixed openjdk8u232Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Intel Xeon 2893 MHz, 32 cores, 256G, Win32 / Windows Server 2012 Standard:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\jprt\T\P1\224926.amurillo\s\hotspot\src\share\vm\asm/codeBuffer.hpp:176), pid=23724, tid=0x000000000000a4b4
#  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000009c16026b60 <= 0x0000009c1602c151 <= 0x0000009c1602c150
#
# JRE version:  (9.0) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-20150507224926.amurillo.jdk9-hs-2015-05--b00 compiled mode windows-amd64 compressed oops)
# Core dump will be written. C:\local\aurora\sandbox\results\workDir\closed\com\oracle\jfr\gc\DetailedEventTest\TestEvacuationFailedEvent\hs_err_pid23724.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x0000009c13ff2800):  JavaThread "Unknown thread" [_thread_in_vm, id=42164, stack(0x0000009c15b00000,0x0000009c15c00000)]

Stack: [0x0000009c15b00000,0x0000009c15c00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
0000009c`15bfea50 00000000`5459b067 jvm!os::abort+0x17f [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\os\windows\vm\os_windows.cpp @ 1082]
0000009c`15bfead0 00000000`5458b831 jvm!VMError::report_and_die+0x927 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\utilities\vmerror.cpp @ 1111]
0000009c`15bfed70 00000000`5423dea3 jvm!report_vm_error+0x71 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\utilities\debug.cpp @ 217]
0000009c`15bfee20 00000000`545da266 jvm!CodeSection::set_end+0x73 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\asm\codebuffer.hpp @ 176]
0000009c`15bfef80 00000000`545e177b jvm!Assembler::emit_operand+0x186 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\assembler_x86.cpp @ 298]
0000009c`15bff000 00000000`5463fd25 jvm!Assembler::movl+0x12b [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\assembler_x86.cpp @ 1826]
0000009c`15bff0d0 00000000`54640e43 jvm!MacroAssembler::multiply_128_x_128_loop+0x345 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\macroassembler_x86.cpp @ 7445]
0000009c`15bff2a0 00000000`54671f21 jvm!MacroAssembler::multiply_to_len+0x6d3 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\macroassembler_x86.cpp @ 7716]
0000009c`15bff4a0 00000000`54665b54 jvm!StubGenerator::generate_multiplyToLen+0x241 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\stubgenerator_x86_64.cpp @ 3762]
0000009c`15bff600 00000000`54661ffc jvm!StubGenerator::generate_all+0x544 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\stubgenerator_x86_64.cpp @ 4013]
0000009c`15bff6e0 00000000`54538d4b jvm!StubGenerator_generate+0x3c [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\cpu\x86\vm\stubgenerator_x86_64.cpp @ 4029]
0000009c`15bff740 00000000`544fc74a jvm!StubRoutines::initialize2+0x17b [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\runtime\stubroutines.cpp @ 258]
0000009c`15bffb30 00000000`5454436f jvm!init_globals+0xfa [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\runtime\init.cpp @ 144]
0000009c`15bffba0 00000000`544246c7 jvm!Threads::create_vm+0x1cf [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\runtime\thread.cpp @ 3380]
0000009c`15bffcf0 00000000`5442777f jvm!JNI_CreateJavaVM_inner+0xd7 [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\prims\jni.cpp @ 3984]
0000009c`15bffdd0 000007f7`3f2d2310 jvm!JNI_CreateJavaVM+0x1f [c:\jprt\t\p1\224926.amurillo\s\hotspot\src\share\vm\prims\jni.cpp @ 4056]

Comments
Fix Request (8u) Backporting this patch keeps more leeway for generated stubs, and keeps codebase in sync (I see 8u221, 8u241). Patch applies cleanly to 8u, passes tier1.
15-08-2019

verified by nightly testing
26-07-2017

The problem with generate_multiplyToLen size was fixed by 8081778 changes: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/578f086f3435#l6.1 But it looks like it could be not enough for GHASH intrinsic pushed after that and that what was hit by David's build: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ce0c612ea443
19-06-2015

ILW=Assert - not causing error, many tests, none=MHH=P2
18-05-2015

Looks like this stub routine was added as part of changeset: 6998:427de14928ab user: kvn date: Tue Sep 02 12:48:45 2014 -0700 summary: 8055494: Add C2 x86 intrinsic for BigInteger::multiplyToLen() method
12-05-2015