Test

Fri Sep 18 11:08:00 GMT 1998

>> Godmar> My question is more concerned with what you do when your
> Godmar> compiler creates type maps (information that says what machine
> Godmar> state, including stack state refers to which objects). Then,
> Godmar> it is often so that this information is not available for
> Godmar> every instruction, but only a subset of instructions.
>> Ok, I didn't understand your question originally.
>> Our use of the Boehm collector is not fully conservative. We use the
> compiler-generated type info to do precise marking of the heap. So if
> I understand you correctly, we could see this problem if we use a
> preemptive thread system.
>> As I understand it (which is perhaps less than I should), the Boehm
> collector has an allocation lock that it acquires when allocating new
> objects. This lock prevents GC from running during these critical
> sections. So one solution is to modify the allocator to always
> initialize the vtbl of a new object to NULL, and then have the mark
> function recognize this as a special case. This works because we know
> that an object without a vtbl hasn't yet been initialized and
> therefore can't hold any pointers.
>> Right now, we just ignore this problem. Dealing with it is on my list
> of things to do.
>> Does this answer your question? Or am I still misunderstanding?
>
I think we might still misunderstand each other.
It is great that you use precise marking of the heap (better than
Kaffe currently), but the problems I was pointing to have only to do
with the marking of the (Java) stack, whose values are stored in
machine registers and on the (machine) stack.
Memory allocation, as you point out, has to be protected from gc:
an allocation lock is usually used for that. Again, this has nothing
to do with my question.
The problem I was referring to only occurs if you stop conservatively 
scanning the (machine) stack and instead rely on compiler-generated 
knowledge that says which (machine) registers and which (machine) stack 
locations contain which (Java) stack and (Java) local registers values.
This information is commonly called a type or stack map.
Here's an example:
Suppose you have three threads: thread 1 and thread 2 do computation,
thread 3 is the gc thread. Now suppose thread 1 executes code. 
Further, suppose it executes a loop that is between pc value 20 and 30.
Suppose the compiler has prepared stack maps for the pc value 20 and 31,
but not for any pc value greater than 20 and less than 31.
Now suppose thread 1 is preempted at pc 25. Now suppose thread 2
runs, thread 2 wants to allocate memory, but a gc is triggered.
The gc threads needs to obtain root information from both thread 1
and thread 2. Thread 2 is not a problem, because the compiler will
have created type information (read: set a gc point) for the pc value at
which thread 2 tries to allocate memory.
Thread 1, however, is stuck between two gc points: no precise information
is available to map machine state to Java state. What do you do?
If the threading were non-preemptive, then you could have made sure that
thread 1 wasn't preempted at pc 25: maybe it could only be preempted at
pc 20, where type information was available.
I really recommend reading Diwan's paper, he does a better job at explaining
the issue.
	- Godmar