At this place the myInt is stored and the myString reference value (which is the reference to the real string value)
Let's make sure you're not going down bad paths here.
First off, it's unclear to me why you re-ordered the integer and the string in the diagram compared to the source code. It is implementation-defined how the string and the integer are packed, and in what order, and whether there are any padding bytes. If you care about these details, ask a more clear question.
Second, it is unclear what you mean by "the real string value". Strings are of reference type. The real value of the string is the reference. The values of the contents of the string are in the referenced location.
if obj.myString shall be accessed, are there two "lookups" necessary, e.g. first looking up obj, then following it and looking up myString
I assume that by "lookup" you mean dereference.
So for example, if we have:
var obj = whatever;
char c = obj.myString[1];
then yes, we have two dereferences. The .
dereferences obj
to get myString
, which is a reference. The [1]
dereferences myString
to get the char
.
Where is the reference value of obj stored?
obj
is a variable. A variable is a storage location. That storage location can be in a number of places:
If obj
is short lived, or even better, ephemeral, then it can be enregistered or put on the short term pool. (More commonly known as the stack, but it is a better habit in my opinion to think of the short term pool in terms of its semantics, namely, storage that lives not longer than activation. The stack is an implementation detail.)
If obj
is not known to be short lived then it goes on the long-term pool, also known as the managed heap.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…