[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Bug in FieldsAllocationStyle=2 logic
From:       rednaxelafx () gmail ! com (Krystal Mok)
Date:       2011-06-22 16:27:01
Message-ID: BANLkTi=pUG-urFkPUEh_14rcC226aKSycA () mail ! gmail ! com
[Download RAW message or body]

Hi all,

I think I've found a bug in ClassFileParser::parseClassFile() that deals
with FieldsAllocationStyle=2, which was introduced about a year ago:
http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743

int map_size = super_klass->nonstatic_oop_map_size();
OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps();
OopMapBlock* last_map = first_map + map_size - 1;

This code accidentally works on LP64 systems because it takes 1 word per
OopMapBlock, so nonstatic_oop_map_size() and nonstatic_oop_map_count() would
actually return the same value.

But on 32-bit systems, an OopMapBlock takes 2 words, which
makes nonstatic_oop_map_size() == nonstatic_oop_map_count() * 2, and breaks
the code above.

The code should really be:

int map_count = super_klass->nonstatic_oop_map_count();
OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps();
OopMapBlock* last_map = first_map + map_count - 1;

I found this because FieldsAllocationStyle=2 doesn't work for me on 32-bit
Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu JDK6u25. Here's a min
repro of my test: https://gist.github.com/1037866

Could anybody please verify this?
Just checked the current tip of hsx/hotspot-rt, and it still has this
behavior:
http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp
 line 3290

Regards,
Kris Mok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110623/17bf0a5b/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]