How many objects can you create in JVM with very large RAM.

[Ravi Gupt]

Hello Guys,

is there a limit on how many objects can be created on the heap? Assume heap size is set to very large (more than 2^31)

If there is no limit then how we get unique hashcode for each object. Remember hashcode from Object class returns an int.

Consider a hypothetical powerful computer with RAM size extremely large. If there is a limit then, Wil same limit holds true for such computer as well ?

Regards,
Ravi

[Campbell Ritchie]

I think the default size for the heap is 25% of available RAM, but I am not certain.
You don’t have to return unique hash codes from different objects; indeed in some circumstances (equals() returns true) you must return the same hash code, so number of hash codes does not restrict the possible number of objects. So I think there is no rule restricting the number of possible objects, if you can make the heap memory large enough to fit them all in.

[Ravi Gupt]

Hi Campbell,

thanks for the response. But i think you didn't get the question right.

Assume a class which does not override hashcode method (from Object class). Now if you create several objects out of this class, each would have a unique hash code value. (this is calculated by jvm using it's memory address etc.). So basically each object will have a unique hash code value in case the programmer does not chose to override hashcode method in that class.

Now assume you have virtually unlimited memory(heap size) at your disposal and you create zillion such objects, so they have to share some hash code values.

Following is quote from Java docs of Object class:
" As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.) "


I want to understand the meaning of text highlighted in red. Which is that impractical scenario which forces jvm to return non-unique hash code values for objects.

Regards,
Ravi

[Campbell Ritchie]

You should try to give different hash codes to different objects. Should you have 4294967297 objects, and there are 4294967296 potential different hash codes, you are absolutely guaranteed to have a duplication. What it means is that you must try to have different hash codes. If among those 4294967297 objects, you have 4294967294 different hash codes, you are doing quite well. Only 3 collisions. If, however, you have 12 hash codes among 4294967297 objects, you are doing really badly.
I have written about how to find out about hash code methods before: look here, and in the link I gave to Bloch’s book.

[Paul Clapham]

Ravi Gupt wrote:I want to understand the meaning of text highlighted in red.

It looks perfectly understandable to me. However it appears you're going beyond that, and you want to know why the original designers considered some undescribed actions to be reasonably practical and other undescribed actions to be unreasonable or impractical.

This seems rather pointless to me, especially since it's impossible to answer the question. But since it isn't absolutely necessary for unequal objects to have different hashcodes anyway, it's perfectly reasonable for a class's hashcode method to produce equal hashcodes for unequal objects sometimes. And the documentation says that might happen. Which is perfectly reasonable.

[Ravi Gupt]

Hi Paul,

thanks for reply.

As you said, "it isn't absolutely necessary for unequal objects to have different hashcodes anyway". I want to know in which all cases different objects would have same hash code value. What are those "sometimes" cases when that happens.

I understand one has to dig into the algorithm that Designers used for implementing hashcode for which memory address is one of the several parameters. We are just guessing several possibilities here.

one possible case is - when jvm runs out of available unique hash code values.

Is there any other case ?

Thanks
Ravi

[Paul Clapham]

I still don't understand what value you expect to get from examining the details of a decision from 15 years ago along with documentation which was clearly put there just to allow programmers to do something reasonable, rather than to document specific features.

And your approach of guessing what those details might have been is useless, if your goal is to find out the actual details.

However if you want to speculate in general about why people might write a hashcode algorithm which might produce duplicate hashcodes for unequal objects, you could certainly do that. Just bear in mind that such an algorithm is never designed so that it produces duplicate hashcodes under certain well-defined conditions; the actual situation is that they are designed so that they might sometimes produce duplicates because it's unavoidable. Nobody cares exactly what duplicates it might produce or when it might produce them because -- as you know -- it doesn't matter.

[Paul Clapham]

Here's an example: the String class. Each String object has a hashcode, of course. There are 2^32 possible hashcodes, as you know, but there are far more than 2^32 distinct possible Strings. And by far more I mean unimaginably more. Not just 2^1000 or even 2^1000000, but unimaginably more than even that.

And so it follows that an unbelievably huge number of distinct Strings all have the same hashcode.

But it doesn't matter. It might be possible to look at the hashcode algorithm for String and bring in the heavy-duty mathematics to explain exactly in what case two different Strings would have the same hashcode, but that would be a complete waste of time because it doesn't matter.

[Jesper de Jong]

Ravi Gupt wrote:one possible case is - when jvm runs out of available unique hash code values.

The JVM cannot "run out of available unique hash codes". The JVM isn't generating or handing out hash codes to objects; the idea that "the JVM runs out of hash codes" isn't a valid idea at all. What the hash code of an object is, entirely depends on the implementation of the hashCode() method of the class of the object. You could implement your own hashCode() method that always returns the same value:

public class Example {
    @Override
    public int hashCode() {
        return 4;
    }
}

That would be perfectly valid.

The only problem is this is that it would not be very efficient if you store this in a collection class that uses hash codes, such as HashSet or as a key in a HashMap.

The number of objects that you can create does not have anything at all to do with hash codes.

[Winston Gutkowski]

Ravi Gupt wrote:I want to know in which all cases different objects would have same hash code value.

Simply put: you can't. And the reason you can't is that the implementation for Object.hashCode() is (a) not specified, and (b) is JVM-specific.
That means that if, after poring for weeks over reams of JVM code, you finally discovered what the actual hashcode algorithm was, it might change completely when you get the next version (or indeed, possibly even after a patch).

However, one possible scenario for two objects having the same Object.hashCode():
1. The method returns the last 32 bits of the object's memory address.
2. You request hashcodes for two objects that are exactly 4Gb apart in memory.

Unlikely, but possible.

Winston

[Ravi Gupt]

@Jesper,

We are not talking about overridden hashcode method here. We are talking about Object.hashCode() Please read the question again.


@Winston,

This exactly the answer i was looking for. You rock.

Thanks,
Ravi