• Post Reply Bookmark Topic Watch Topic
  • New Topic

Do objects have their own copies of non-static methods as well?  RSS feed

 
Eshan Kapoor
Ranch Hand
Posts: 39
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
On multiple websites, it is stated that when objects of a class are created, they have their own copy of instance methods and variables.
But what I have read is that methods, both static and non-static, are created on stack----perform the work----and are popped out of the stack.
And we know that static methods are per class and not per object.
So, what I want to know is if static methods are not per object but per class, where do instance methods really go/created?
Question may seem silly, even was asked earlier too in a different manner, but I was not satisfied with the answers provided.
Please help.

Thanks
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eshan Kapoor wrote:And we know that static methods are per class and not per object.
So, what I want to know is if static methods are not per object but per class, where do instance methods really go/created?

Actually, almost certainly, both are per class. In the case of instance methods, an extra parameter is added behind the scenes which, when it's called, contains a reference to this.

I wouldn't stake my life on it; but it's certainly how I would design it.

Winston
 
Jayesh A Lalwani
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, where and how the functions are stored is JVM dependent. Most likely they stay in perm gen, and internally the objects have some sort of reference that allow the JVM to find the functions in the permgen efficiently. Again, this is conjecture, and you don't really know how the JVM works, nor you should

In C++, class methods were compiled by the compiler into function pointers. It is likely that the original creators of Java used the same mechanism, although now after so many years, it's hard to say without actually talking to someone who has implemented the JVM. C has native support for pointers to function (yes yes C was a functional language before people knew what functional languages were... we tend to come full circles in this industry) The way it works in C++ is, the compiler generates the machine code for the class functions separate from the machine code for the class definition. When it generates the machine code for the class function, it generates the machine code just like it is a normal function, except that it adds a parameter called this. When it generated the machine code for class definitions, the functions inside the class were replaced by function pointers to the functions. When it saw a function call, it generated machine code that will look the function by it's pointer and call that function. For the compiler, static functions and non-static functions were not much differrent. The only differrence was that there was no this parameter

Anyhoo, not saying that Java does this, but it makes sense that it would do something similar.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eshan Kapoor wrote:But what I have read is that methods, both static and non-static, are created on stack----perform the work----and are popped out of the stack.

What do you mean with methods are created on the stack? I think this is sloppy use of terminology that makes it hard to understand what's really happening.

A method just consists of byte code. There's only one copy of the byte code. It's not copied on the stack or anything like that. Especially, there's not a separate copy of the byte code for each instance of a class. That is totally unnecessary, since the byte code never changes - there's no reason at all for there to be more than one copy of the byte code.

Local variables that are declared inside a method are allocated on the stack. Each time a method is called, new copies of the local variables are created on the stack. Not per object, but per method call. There is no difference between static and non-static methods.
 
Eshan Kapoor
Ranch Hand
Posts: 39
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Jesper - Oh, my apologies. I should have written methods are stacked.
And by byte code, do you mean that the instructions inside a method are compiled into byte code?

@Winston - So why some books and websites state that objects have their own copy of instance methods? Also, is it correct to say "instance" methods or should it be "non-static" methods?
 
Jayesh A Lalwani
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The books are mainly talking from a programming perspective, not from how the JVM implements it. Your original question made it sound like you were asking from the perspective of the JVM

Logically, non-static members belong to instance of the class. The JVM does optimization behind the scenes so it doesn't have to make copies of the method. However, how the JVM does it for real, and how you think about it from a programmer's perspective are 2 differrent things
 
James Boswell
Bartender
Posts: 1051
5
Chrome Eclipse IDE Hibernate
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, is it correct to say "instance" methods or should it be "non-static" methods?

I prefer instance methods and class methods to infer what the method belongs to.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eshan Kapoor wrote:@Jesper - Oh, my apologies. I should have written methods are stacked.

"Methods are stacked"? What does that mean?

Eshan Kapoor wrote:And by byte code, do you mean that the instructions inside a method are compiled into byte code?

Yes, that is what the Java compiler does, it translates source code into byte code which can be executed by the Java virtual machine.
 
Eshan Kapoor
Ranch Hand
Posts: 39
Eclipse IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Jesper - It means that a method is placed/added in the stack when it is called. I read "Methods are stacked" in head first java.
 
Ivan Jozsef Balazs
Rancher
Posts: 999
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eshan Kapoor wrote:It means that a method is placed/added in the stack when it is called. I read "Methods are stacked" in head first java.


It is an unfortunate wording. Not methods are put on the stack but activation records: parameters values etc., not the methods themselves.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!