Allocation location of class parameters vs run logic..
4 answers - 1643 bytes -
In the following code, a realtime thread is created on the heap,
(the same question holds for creation in immortal mem)
with a scoped area passed in as the Memory object passed
to super(...). There are two member variables one created upon
creation of the thread, the other created inside the run logic.
Question:
Are both the reference to ObjectA and the object itself located on the heap?
Is the ObjectB reference on the heap and the actual object in scopedA?
class threadTest extends RealtimeThread {
Object A = new Object(); // both ref and object on heap
Object B;
threadTest(MemoryArea mem){
super(......mem....);
}
public void run(){
B = new Object(); // reference in heap, object in scopeA
Object C = new Object; // both ref and object in scopeA
}
}
class main {
LTMemory scopeA = new LTMemory(1024,1024);
ThreadTest threadA = new ThreadTest(scopeA);
......
No.1 | | 2192 bytes |
| 
>
> class threadTest extends RealtimeThread {
>Object A = new Object(); // both ref and object on heap
>Object B;
>threadTest(MemoryArea mem){
>super(......mem....);
>}
>
>public void run(){
>B = new Object(); // reference in heap, object in scopeA
>Object C = new Object; // both ref and object in scopeA
>}
>
> class main {
>LTMemory scopeA = new LTMemory(1024,1024);
>ThreadTest threadA = new ThreadTest(scopeA);
> ......
>
> Are both the reference to ObjectA and the object
> itself located on the heap?
The "reference" to ObjectA is a field of an instance of threadTest. In this case the instance of threadTest is created in the heap, according to what you describe.
The object assigned to ObjectA is allocated in the same allocation context as the constructor for threadTest is run in, so it too is allocated in the heap, for this particular instance.
> Is the ObjectB reference on the heap and the actual
> object in scopedA?
Again ObjectB is a field of an instance of threadTest and in this example that instance is in the heap.
The actual object that you try to assign to ObjectB is allocated in the initial memory allocation context of the thread, and in this case that is scopeA.
Because ObjectB belongs to a heap-allocated object, and the new object is scope-allocated, the assignment to be ObjectB will cause an IllegalAssignmentError.
No.2 | | 344 bytes |
| Ah I get it, so if the heap allocation in my example were to occur in immortal mem, the reference instance would be in immortal memory
with the object residing in scopeA memory, since the reference
in immortal, it does not break access rules, ie immortal holding
a reference to scoped memory..
Thanks again David.
No.3 | | 786 bytes |
| > Ah I get it, so if the heap allocation in my example
> were to occur in immortal mem, the reference instance
> would be in immortal memory with the object residing in scopeA
> memory,
Correct.
> since the reference in immortal, it does not break access rules, ie
> immortal holding a reference to scoped memory..
Er - No. Immortal can not hold a reference to scoped memory. An object within a given memory area can only hold references to objects in the same or longer-lived memory area. So immortal and heap can never hold references to any object in scope; and an outer scope can't hold a reference to any object in an inner scope. Of course a scoped object can hold references to heap, immortal or an outer scope.
No.4 | | 360 bytes |
| I understand the reference rules, immortal can not hold a ref
to anything that can go out of scope. My real question, which you answered was to make sure that I understood where instance vs run logic variable instantaitions were ending up. I wrote the original question lazily without taking into acount the access rules!! (late night..)
mcg