Bug in FieldsAllocationStyle=2 logic

David Dabbs dmdabbs at gmail.com
Wed Jun 22 11:29:30 PDT 2011



> -----Original Message-----
> From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-
> bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
> Sent: Wednesday, June 22, 2011 12:39 PM
> To: Krystal Mok
> Cc: hotspot-dev
> Subject: Re: Bug in FieldsAllocationStyle=2 logic
> 
> Thank you for such detail analysis and suggested fix.
> I filed bug and I will fix it in 7u2.
> 
> 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM
> 
> Thanks,
> Vladimir
> 
> PS: if possible, please, report problems to hotspot-
> dev at openjdk.java.net alias
> so all Hotspot developers can see it. I did original changes but I am
> in
> Compiler (JIT) group.
> 
> Krystal Mok wrote:
> > 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


What would be the use case/work load for choosing this option?


Thanks,

David




More information about the hotspot-dev mailing list