This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Performance and the fly likes two questions in Java performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "two questions in Java performance " Watch "two questions in Java performance " New topic
Author

two questions in Java performance

Arad Chear
Ranch Hand

Joined: Jan 05, 2007
Posts: 98
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

Joined: Apr 20, 2006
Posts: 3344


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.


Everything has got its own deadline including one's EGO!
[CodeBarn] [Java Concepts-easily] [Corey's articles] [SCJP-SUN] [Servlet Examples] [Java Beginners FAQ] [Sun-Java Tutorials] [Java Coding Guidelines]
Arad Chear
Ranch Hand

Joined: Jan 05, 2007
Posts: 98
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

Joined: Apr 20, 2006
Posts: 3344

obviously it would be on the Stack for every method call even if its recursive!
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
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.


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Arad Chear
Ranch Hand

Joined: Jan 05, 2007
Posts: 98
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

Joined: Jun 26, 2002
Posts: 852
Eisa, do you have a problem you are trying to solve or is this more of an educational question?


http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
Arad Chear
Ranch Hand

Joined: Jan 05, 2007
Posts: 98
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

Joined: Apr 20, 2006
Posts: 3344


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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Nov 29, 2005
Posts: 2308
When we use reflection in java then also permanent generation comes into picture for storing the java.lang.Class of that class.


Rahul Bhattacharjee
LinkedIn - Blog
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
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

Joined: Nov 29, 2005
Posts: 2308
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

Joined: Apr 20, 2006
Posts: 3344


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

Joined: Apr 20, 2006
Posts: 3344

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

    Joined: Sep 24, 2004
    Posts: 194
    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.


    PJ Murray -
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    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

    Joined: Jan 30, 2000
    Posts: 18671
    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.


    "I'm not back." - Bill Harding, Twister
    Nik Arora
    Ranch Hand

    Joined: Apr 26, 2007
    Posts: 652
    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

    Joined: Jan 30, 2000
    Posts: 18671
    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
    Sheriff

    Joined: Sep 28, 2004
    Posts: 18101
        
      39

    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


    Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
    Nik Arora
    Ranch Hand

    Joined: Apr 26, 2007
    Posts: 652
    Originally posted by Jim Yingst:
    What part is unclear to you?


    I am not understanding the meaning of the entire pharse.

    Regards
    Nik
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: two questions in Java performance