JDK-6401952 : assert(field_index <= 0xFFFF,"field index does not fit in low flag bits") occurs in java_g (5.0u6)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0u6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-03-22
  • Updated: 2012-10-08
  • Resolved: 2006-05-11
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.
Other JDK 6
5.0u10Fixed 6 b84Fixed
Description
The following assert occurs in 5.0u6 with Java_g.

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=\cpCacheOop.cpp:97]
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (C:/BUILD_AREA/jdk1.5.0_06/hotspot\src\share\vm\oops\cpCacheOo
p.cpp, 97), pid=1696, tid=3160
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05-debug mixed mode)
#
# Error: assert(field_index <= 0xFFFF,"field index does not fit in low flag bits
")
# An error report file with more information is saved as hs_err_pid1696.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

CONFIGURATION:
  OS :WindowsXP(SP1, Japanese)
  JRE : 5.0u6

REPRODUCE:
 1) compile the attached  bigoom.java and big.java. 
 2) Invoke "java_g bigoom"
Comments
SUGGESTED FIX Webrev: http://jruntime.east/~coleenp/webrev/6401952
28-04-2006
EVALUATION Fixed 6401952: assert(field_index <= 0xFFFF,"field index does not fit in low flag bits") occurs in java_g (5.0u6) The space in the cpCache that holds the index in instanceKlass::fields wasn't big enough for large classes. The field is a short because the constant pool can only have 2^16 entries, but the index in the instanceKlass has 7 entries per field, so 7 times that. Fixed so that we do the 7x math on access to the field (both setting and getting). There is space in the cpCache to store 7x 0xffff entries but if instanceKlass::next_offset ever changed this would break. This holder index is used by jvm/ti to get to the access flags to determine whether the field access/modification is being watched. Fix verified (y/n): y Verified by: bigoom test case (regression test added) Webrev: http://jruntime.east/~coleenp/webrev/6401952 Other testing: nsk vm.full.testlist minus dedicated/diehard tests Reviewed by: Tom R, Robert F, Paul H Approved by: Dave Therkelsen (gatekeeper) Risk: low
28-04-2006
SUGGESTED FIX I'll wait till it's reviewed first...
21-04-2006
EVALUATION The field in the constant pool cache for field_holder assumed that the number couldn't exceed the number of fields in an class. This is a ushort as defined by the classfile format length field. In fact, the information stored in the instance klass holder for that field is a set of 7 shorts and the index points into these. enum FieldOffset { access_flags_offset = 0, name_index_offset = 1, signature_index_offset = 2, initval_index_offset = 3, low_offset = 4, high_offset = 5, generic_signature_offset = 6, next_offset = 7 so the index can be 0xffff * 7 and the cpCache field wasn't large enough, causing the assertion. Luckily there's 7 unused bits above the field which is enough space so we use that for this field. This seems to only be used by jvmti. The compiler interface uses the constant pool.
21-04-2006