how jvm stores objects inside the jvm memory

Question

As a result of classloading by the ClassLoader, a Class object (an object of class java.lang.Class) is going to be created on the heap. This is what consists of the plan of the class as its state. Every object created from a class is going to be linked to its Class object (obtainable from the getClass() method available in the Object class - that is available in every object). Also as a result of class loading, the bytecode of the methods defined in a class is going to read into the MethodArea of the internal memory of JVM (Remember that JVM is a program which is given some memory by the OS when it is executed - this memory is compartmentalized to Stack, Heap, Method Area). The Class object contains linkages to the method bytecode of the class in the MethodArea as well.

This all the process will happen when the class has been loaded I want to know How JVM will store all the objects by using Hastable and how is our equels() and hashcode() will work with that.

I have no idea how all the stuff you said in the first paragraph is supposed to relate to `equals`, `hashcode`, or `Hashtable`. Those are just methods and classes like any other. They have nothing to do with memory management. — user2357112, Feb 13 '14 at 06:23
finally our all objects will load in to hash table right by using key value pair as Class — user3214269, Feb 13 '14 at 06:28
Nope. Hashtable has nothing to do with the JVM's object management. — user2357112, Feb 13 '14 at 06:30
Something I know that is hashCode() method is used to get the hashCode of the particular object (Don't know how they will calculate), and HashTable is used to index the object according to there hashCode value. — user3214269, Feb 13 '14 at 06:36

score 0 · Answer 1 · answered Feb 13 '14 at 06:29

0

To store an object, JVM reserves enough space for its fields and service information. Service info includes reference to the class object and bits for synchronization.

All accesses to objects, including class objects, is done via memory addresses. Hashcode and equals are not used by JVM during object lifecycle.

answered Feb 13 '14 at 06:29

Alexei Kaigorodov

13,189
1
21
38

Then How JVM will get know about whether that object that class has been loaded or not – user3214269 Feb 13 '14 at 06:32
classes are loaded by classloaders. It is a classloader who is asked to load a class or return an already loaded class object. To track the list of loaded classes, classloader may use a hash table, but the key type is String, and only hashcode and equals of String class are used. Since String is final, user cannot override that methods and affect JVM functionality. – Alexei Kaigorodov Feb 13 '14 at 06:41
"How JVM will get know about whether that object ... has been loaded" - the question is incorrect. Objects are not loaded. They are created and garbage collected. – Alexei Kaigorodov Feb 13 '14 at 06:44
When we create an object for the class that .class file will be loaded into the jvm heap. And that object reference will be stored in the stack memory.If I create new object for the same class once again that How the jvm will get know about the that .class file already there in jvm heap. – user3214269 Feb 13 '14 at 06:54
@user3214269 References to loaded classes are stored in classloaders. It is a classloader who knows which classes are loaded. See my previous comment. – Alexei Kaigorodov Feb 13 '14 at 07:19
If I override the equels() and hashcode() in my class. What is the use? – user3214269 Feb 13 '14 at 07:26
@user3214269 I don't understand "What is the use". I am not a native English speaker. – Alexei Kaigorodov Feb 13 '14 at 07:45
why should we need to override the hashcode() and equels() in JavaClasses – user3214269 Feb 13 '14 at 08:48
http://stackoverflow.com/questions/2265503/why-do-i-need-to-override-the-equals-and-hashcode-methods-in-java – Alexei Kaigorodov Feb 13 '14 at 09:35

Peter Lawrey · Answer 2 · 2014-02-13T07:20:59.990

There is no global hashtable which allows you to look up all objects. Your program can run with objects where hashCode just throws an error because it is only ever called on particular objects.

Note: Object.hashCode() has nothing to do with the actual address of the object and it doesn't change as the object gets moved around. When object is first created, it doesn't have a default hashCode(), this is only generated if called. This hashCode() is stored in the object header for OpenJDK/Hotspot JVM.

Then How JVM will get know about whether that object that class has been loaded or not

It hash a list of root objects, e.g. Threads. From those threads it can work out all the object it refers to and all those objects etc, until it has found all the reachable objects.

How the jvm will get know about the that .class file already there in jvm heap.

The JVM keep a table of classes in the PermGen (not the heap) and it can look up these classes when it loads the byte code. It doesn't have to do this when the code is running.

BTW PermGen is going away in Java 8.

HashTable is used to index the object according to there hashCode value.

This HashTable only exists if you write code like

Hashtable<String, Long> ht = new Hashtable<>();
ht.put("Hello", 1);

When put is called, it will call String.hashCode() which generates a hashCode based on the contents of the string, note this doesn't call Object.hashCode()

If you want to know how String.hashCode() works, you can read the code in your IDE, or googling for it.

BTW Use HashMap is you can, Hashtable is a legacy class.

how jvm stores objects inside the jvm memory

2 Answers2