JDK-6949298 : The return type of MemoryPool::max_size() should be signed
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs18
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2010-05-03
  • Updated: 2017-04-14
  • Resolved: 2017-04-14
Related Reports
Relates :  
JDK-6941275 - G1: The MemoryPools are incorrectly supported for G1
Description
Right now, the max_size() method of the MemoryPool class (and subclasses) returns size_t. However, according to the specification, -1 is a valid value (it means: undefined). From the javadoc of MemoryUsage.getMax() method:

----------

getMax

public long getMax()

    Returns the maximum amount of memory in bytes that can be used for memory management. This method returns -1 if the maximum memory size is undefined. 

...

----------

And the getMax() method is eventually mapped to MemoryPool::max_size().

Changing the return type of max_size() from size_t to ssize_t would be more reasonable when returning -1 from max_size().
Comments
Not a priority, closing as WNF.
14-04-2017
PUBLIC COMMENTS Thanks to John Coomes for this note: "Using ssize_t will limit you to 2G in 32-bit, which doesn't seem workable. The java apis use long, so I'd use int64_t in the M&M vm code (keep the rest of the vm unsigned!). Signed overflow is theoretically possible, but remote (8 million terabytes)." Unfortunately, changing the type from size_t to int64_t might not be straightforward, here's my reply: "You are of course right and thanks for bringing this up. The problem is that the signature of this method is also replicated in the JDK. So, changing size_t -> ssize_t will probably work without changing the JDK, but changing size_t -> int64_t will most likely not work. Mandy said that we could change JDK 7, but we probably won't be able to change JDK 6. And we'll need the same HotSpot to go into both JDKs. Maybe we have to put up with (size_t) -1 for the time being."
04-05-2010