«

Hi Friends,

I am new to Java Memory Model. I read that when I instantiate an
object the memory for the object will be allocated in Heap and the
identifier will be allocated in Stack.

For example:

Object myObj = new Object();

The memory for the myObj will be allocated in Heap.

and the reference memory address will be stored in Stack.

Is my understanding correct? can anybody suggest some tools that
visulises all these memory modeling concepts.

Thanks and Regards,
Dinesh.V

I guess you looking out for this:
http://java.sun.com/j2se/1.5.0/docs/...ex.html#manage

On Feb 26, 2:31 am, jakarta....@gmail.com wrote:
> Hi Friends,
>
> I am new to Java Memory Model. I read that when I instantiate an
> object the memory for the object will be allocated in Heap and the
> identifier will be allocated in Stack.
>
> For example:
>
> Object myObj = new Object();
>
> The memory for the myObj will be allocated in Heap.
>
> and the reference memory address will be stored in Stack.
>
> Is my understanding correct? can anybody suggest some tools that
> visulises all these memory modeling concepts.
>
> Thanks and Regards,
> Dinesh.V

jakarta....@gmail.com wrote:
>> I am new to Java Memory Model. I read that when I instantiate an
>> object the memory for the object will be allocated in Heap and the
>> identifier will be allocated in Stack.
>>
>> For example:
>>
>> Object myObj = new Object();
>>
>> The memory for the myObj will be allocated in Heap.
>>
>> and the reference memory address will be stored in Stack.

That's sort-of true but not really.

First, one use of the term "Java memory model" has nothing to do with heap vs.
stack - it refers to how multiple threads make memory activity visible to each
other. Bear that in mind while Googling. It is a very important topic, just
not what you are asking.

Now, Java does not make any promises about heap vs. stack - the JVM is free to
optimize certain allocations to the stack, or even out of existence altogether.

Conceptually all object instances live on the heap, and references from
objects, i.e., class and instance variables, will also live on the heap
because they are part of the class or object. However, there is no semantic
impact to that, and the physical reality can shift and change.

Automatic variables, those of method or block scope, are more likely to live
on the stack, but might in practice live their entire lives in registers. Or
both, depending on run-time circumstances at the point of invocation.
Conceptually one might as well think of automatic variables, return values,
arguments and such as living on the stack.

So the conceptual, and generally useful picture is similar to your guess, but
not quite the same. Not all references live on the "stack" - allocated memory
lives on the "heap", and may include references as class or instance
variables. Method arguments, return values and block-scoped variables live on
the "stack".

Much more important than phantasms of "stack" and "heap" are the Java
realities of "references" and "instances". References keep instances alive,
and immune to garbage collection (except for weak references and weaker - a
separate topic). The ideas of reference and instance will solve a lot more
bugs than the ideas of stack and heap.

--
Lew

On Tue, 26 Feb 2008 02:31:20 -0800 (PST), wrote,
quoted or indirectly quoted someone who said :

>I am new to Java Memory Model. I read that when I instantiate an
>object the memory for the object will be allocated in Heap and the
>identifier will be allocated in Stack.

Conceptually yes, but Jet for example sometimes allocated objects on
the Stack. This is an optimisation. The code behaves identically.

primitive local variables go on the stack. Local references and
parameters go on the stack. Objects go in the heap.

see http://mindprod.com/jgloss/reference.html
http://mindprod.com/jgloss/stack.html
http://mindprod.com/jgloss/heap.html
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

> Much more important than phantasms of "stack" and "heap" are the Java
> realities of "references" and "instances". References keep instances alive,
> and immune to garbage collection (except for weak references and weaker - a
> separate topic). The ideas of reference and instance will solve a lot more
> bugs than the ideas of stack and heap.
>
> --
> Lew

Great, looks good,
but I am confused about the term weak and weaker references.
Could you please brief these terms in reference to memory model.

--Deepak

On 27.02.2008 16:28, Deepak Srivastava wrote:
>> Much more important than phantasms of "stack" and "heap" are the Java
>> realities of "references" and "instances". References keep instances alive,
>> and immune to garbage collection (except for weak references and weaker - a
>> separate topic). The ideas of reference and instance will solve a lot more
>> bugs than the ideas of stack and heap.

> Great, looks good,
> but I am confused about the term weak and weaker references.
> Could you please brief these terms in reference to memory model.

http://www.pawlan.com/Monica/refobjs/

http://java.sun.com/developer/Books/.../appendixa.pdf

http://www.ibm.com/developerworks/li...-jtp01274.html

http://www.ibm.com/developerworks/ja...-jtp09275.html

Cheers

robert

In article
<05b54bab-99b2-4605-a742->,
Deepak Srivastava <> wrote:

> > Much more important than phantasms of "stack" and "heap" are the Java
> > realities of "references" and "instances". References keep instances alive,
> > and immune to garbage collection (except for weak references and weaker - a
> > separate topic). The ideas of reference and instance will solve a lot more
> > bugs than the ideas of stack and heap.
> >
> > --
> > Lew
>
> Great, looks good,
> but I am confused about the term weak and weaker references.
> Could you please brief these terms in reference to memory model.
>
> --Deepak

There are no "weaker" references.

Normal - Referenced object can not be GCed

SoftReference - Referenced object can not be GCed at the JVM's
discretion. For Sun's, it's the bonehead XX:SoftRefLRUPolicyMSPerMB
setting or several consecutive GCs. The object referred by the
SoftReference becomes null upon GC. You can be notified when the
referenced object has been GCed. These are often used for caches.

WeakReference - Referenced object will be GCed nearly immediately after
stronger references are gone. The object referred by the WeakReference
becomes null upon GC. You can be notified when the referenced object
has been GCed. These are often used to associate metadata with another
object.

PhantomReference - There is no reference available but you are notified
when the reference has been GCed. This might be used to free system
resources that were associated with a Java object.

SoftReference, WeakReference, and PhantomReference should be extended so
that they still contain useful data after the reference is purged. For
example, a SoftReference of cached data may hold a cache key, a
WeakReference some metadata, or a PhantomReference may hold a JNI
pointer allocated by the object it refers to.

--
I don't read Google's spam. Reply with another service.