This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Functional Reactive Programming and have Stephen Blackheath and Anthony Jones on-line!
See this thread for details.
Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

two questions in Java performance

 
Arad Chear
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello .

1) how to know whats happen in the memory for specific program ?

2) where is method signature and behavior store (Heap ? Stack ? )


Thanks in Advance
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

how to know whats happen in the memory for specific program ?


Use some profiling tools. If you dont know about the profiling tools, just google for them.


where is method signature and behavior store (Heap ? Stack ? )


I think they are stored on Stack only, as Heap is used to deal with Objects. Local variables and the method signatures will be on stack.

Any ranchers please clarify if i m not on track.
 
Arad Chear
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks ,

but what about if the class multi thread ( new stack for every thread)

is the methods copied in every stack ?
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
obviously it would be on the Stack for every method call even if its recursive!
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Back on Planet Real...

The methods themselves (their signatures and their code) are not on any stack, nor in the heap. They are in the memory area reserved for loaded classes (*).

You do not end up with multiple copies of methods by doing recursive calls or multi-threading. The only way that you can end up with multiple copies of a method is if the class containing the method is loaded by separate ClassLoaders. If you are not using custom ClassLoaders, you will only ever have one copy of each class and of each method.

(*) If there's a special name for this area, I don't know it.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The byte code for a method (which includes its signature) is actually stored in a special area of the heap, called the permanent generation.

The stack only contains local variables and some administrative information for that specific method call - definitely not the byte code for the whole method.

Hope this helps.
 
Arad Chear
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks so much
its clear now
is there any useful links to deeply look at this issue
(where method store)
[ June 11, 2007: Message edited by: Eisa Ayed ]
 
steve souza
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eisa, do you have a problem you are trying to solve or is this more of an educational question?
 
Arad Chear
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
actually i want to compare between multi inheritance in c++ and multi interface in Java ,

someone sayed the disadvantage of multi interface is redefining the method , so its will copy 2 times in memory ( one in the interface two in the class implements that interface )

where in c++ its only one copy !

iam graduated and this is from my interesting .

Thanks Dear
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

The methods themselves (their signatures and their code) are not on any stack, nor in the heap. They are in the memory area reserved for loaded classes (*).


Thanks for the correction Peter Chase! (ouch..now i remember i have read it before but got confused a bit yesterday)


The byte code for a method (which includes its signature) is actually stored in a special area of the heap, called the permanent generation.


Thank you Ilja Preuss for providing the information.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter Chase:
The methods themselves (their signatures and their code) are not on any stack, nor in the heap. They are in the memory area reserved for loaded classes (*).

...snip...

(*) If there's a special name for this area, I don't know it.


Just to make this totally clear: the special area is called "permanent generation", and it *is* a special area of the heap.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When we use reflection in java then also permanent generation comes into picture for storing the java.lang.Class of that class.
 
Peter Chase
Ranch Hand
Posts: 1970
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Just to make this totally clear: the special area is called "permanent generation", and it *is* a special area of the heap.


So I was strictly wrong to say the method implementations are not on the heap. Shows why it's worth contributing to these forums even when one is reasonably experienced, as there is still plenty to learn!

Does the Permanent Generation occupy part of the heap whose area is controlled by -Xmx etc? Or is it an additional piece of memory? I vaguely seem to recall JVM command-line options for setting Permanent Generation size.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We will learn till the last day of our life.

I think the PermSpace is something apart form heap and it can be set also , like we set the JVM heap size.
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

We will learn till the last day of our life


Well said Rahul.. perfectly correct!


I think the customization option should be provided for setting Permanent Generation as well. But not sure! Any inputs Ilja?
 
Raghavan Muthu
Ranch Hand
Posts: 3381
Mac MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

I think its possible very much.

This article gives a very good and clearcut idea about how and why the permanent generation is important and the storage places of classes & objects!

Check out these links for fine-tuning the JVM wrt to PermGen! They may help you understand clearly..

  • Tuning the JRE (1.3.1)
  • Java and GC Tuning
  • Perf Tuning in Java 5.0



  • HtH.
    [ June 12, 2007: Message edited by: Raghavan Muthu ]
     
    Pj Murray
    Ranch Hand
    Posts: 194
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Eisa Ayed:
    hello .

    1) how to know whats happen in the memory for specific program ?

    2) where is method signature and behavior store (Heap ? Stack ? )


    Thanks in Advance


    Check out
    http://www.ej-technologies.com/products/jprofiler/overview.html

    We've been using it for a few years with good results.
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Peter Chase:

    Does the Permanent Generation occupy part of the heap whose area is controlled by -Xmx etc? Or is it an additional piece of memory? I vaguely seem to recall JVM command-line options for setting Permanent Generation size.


    Mhh, strangely the JConsole shows the permanent generation as not being part of the heap - which is strange, because things in the permgen can get garbage collected.

    The permanent generation has its own setting parameters - it is not affected by -Xmx and related settings.

    So perhaps it would be "more correct" to say that the permanent generation is "a heap outside the heap"?
     
    Jim Yingst
    Wanderer
    Sheriff
    Posts: 18671
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It seems to be kind of borderline. Various JVM parameters like -Xmx don't count the permanent generation in their total for heap allocation, while other references like Tuning Garbage Collection with the 5.0 Java Virtual Machine do clearly talk about the permanent generation as part of the heap. I don't suppose it really matters.
     
    Nik Arora
    Ranch Hand
    Posts: 652
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi All,
    Can anybody explain me the below lines from the Source provided by Raghavan

    The internal representation of a Java object and an internal representation of a Java class are very similar.

    Well, there is a philosophical reason and a technical reason. The philosophical reason is that the classes are part of our JVM implementation and we should not fill up the Java heap with our data structures. The application writer has a hard enough time understanding the amount of live data the application needs and we shouldn't confuse the issue with the JVM's needs.

    The technical reason comes in parts

    Originally there was no permanent generation. Objects and classes were just stored together.

    Back in those days classes were mostly static. Custom class loaders were not widely used and so it was observed that not much class unloading occurred. As a performance optimization the permanent generation was created and classes were put into it. The performance improvement was significant back then. With the amount of class unloading that occur with some applications, it's not clear that it's always a win today.

    It might be a nice simplification to not have a permanent generation, but the recent implementation of the parallel collector for the tenured generation (aka parallel old collector) has made a separate permanent generation again desirable. The issue with the parallel old collector has to do with the order in which objects and classes are moved


    Regards
    Nik
    [ June 22, 2007: Message edited by: nik arora ]
     
    Jim Yingst
    Wanderer
    Sheriff
    Posts: 18671
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It looks like just before "Well, there is a philosophical reason and a technical reason." you've eliminated the part of the text where he actually asks the question that he's subsequently answering. That might make things clearer for readers. Otherwise... I'm not sure what you're asking. I don't really want to try to rephrase that entire block of text. Especially not without understanding what you're asking. What part is unclear to you?
     
    Henry Wong
    author
    Marshal
    Pie
    Posts: 21514
    84
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It might be a nice simplification to not have a permanent generation, but the recent implementation of the parallel collector for the tenured generation (aka parallel old collector) has made a separate permanent generation again desirable. The issue with the parallel old collector has to do with the order in which objects and classes are moved


    Parallel Old Collector?? I didn't know that there is such a thing in the current JVMs.

    There is a Parallel Copy Garbage Collector, but that collector is for new generation objects. There is also a Concurrent Mark and Sweep collector, which is for old generation objects, but that collector is not parallel.

    Henry
     
    Nik Arora
    Ranch Hand
    Posts: 652
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Jim Yingst:
    What part is unclear to you?


    I am not understanding the meaning of the entire pharse.

    Regards
    Nik
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic