JDK-6557169 : inflated monitor enter path should check for integer overflow in recursion count field
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2007-05-14
  • Updated: 2017-04-03
  • Resolved: 2017-04-03
Description
See ObjectMonitor::enter() _recursions
Comments
Not a priority, closing as WNF.
03-04-2017
// - The _recursions field should be of type int, or int32_t but not // intptr_t. There's no reason to use a 64-bit type for this field // in a 64-bit JVM. and yet: volatile intptr_t _recursions; // recursion count, 0 for first entry I think uint would suffice. Though not clear is use of intptr_t relates to padding/layout. I don't think we really want to fix this. Using an assert is of little practical use. Adding an explicit check just penalizes all the code that would never go anywhere near overflowing the count. Given the maximum size of a method is constrained I wonder how many recursive locks you can actually fit in one method? And then how many nested method calls you'd need to actually overflow the count? I suspect StackOverflow would happen first. If we don't fix this then the "FIX ME" comment needs to be removed.
08-02-2017