Stuck... again (Conserative GC)
the Win32 API simply does not allow getting the base stack address of a thread, because: 1. not stable.. Windows *WILL* and *DOES* move that base address at will. 2. Its exclusively chosen and managed by Windows itself.. no ands, buts, or ors about it. In fact, the only way to get it is via the *IoGetInitialStack(*); function, which isn't calleable by user space functions (its a kernel driver function, only defined in ntddk.h, and last time i checked, we don't want a browser running in kernel-space. What would be an alternative way to implement a conservative GC that I can use?
On Jun 11, 2005, at 3:16 PM, Justin Haygood wrote:
the Win32 API simply does not allow getting the base stack address of a thread, because:
1. not stable.. Windows WILL and DOES move that base address at will. 2. Its exclusively chosen and managed by Windows itself.. no ands, buts, or ors about it.
In fact, the only way to get it is via the IoGetInitialStack(); function, which isn't calleable by user space functions (its a kernel driver function, only defined in ntddk.h, and last time i checked, we don't want a browser running in kernel-space.
What would be an alternative way to implement a conservative GC that I can use?
To do the garbage collection we need to be able to walk all the addresses on the stack at one particular point in time. The base address moving should not be an obstacle; it doesn't matter what it was in the past or what it will be in the future. All that matters is what the base is right at the moment garbage collection is occurring. On the other hand, I'm not even sure what it means to move the stack's base address. The base address being chosen and managed by Windows doesn't sound like an obstacle either. That's equally true on the Mac OS X platform and other Unix platforms. Of course the OS chooses the base address for the stack -- that's normal. Walking the stack is definitely possible on Windows. Keep trying and I'm sure you can find out how. I'm sorry this is proving so difficult to research. -- Darin
On Jun 11, 2005, at 3:16 PM, Justin Haygood wrote:
the Win32 API simply does not allow getting the base stack address of a thread, because:
1. not stable.. Windows WILL and DOES move that base address at will.
This part seems unlikely - I could imagine moving the physical address of the stack, but what would be the point of moving the virtual address? Further, this would break any code that kept a pointer to anything on the stack. But as Darin pointed out, it doesn't matter, because you only need to get it at one particular point in time, it does not need to be stable for all time.
2. Its exclusively chosen and managed by Windows itself.. no ands, buts, or ors about it.
It's ok that Windows chooses it - it's chosen by the OS on pretty much all platforms. We don't need to change the stack base, just to get it.
What would be an alternative way to implement a conservative GC that I can use?
My suggestion for how to research this would be to look at the code for the Boehm garbage collector. This is a portable conservative GC implementation for C++, so they must have some way of getting the range of the stack on windows. I'm not sure if the Boehm GC is threadsafe, but as I pointed out it should be sufficient to just get the stack base for the current thread or for the main thread, and to disable marking of other threads. http://www.hpl.hp.com/personal/Hans_Boehm/gc/ I took a quick peek in the source and it does appear to have a way to get the stack base on win32. Regards, Maciej
Thank you, I got it fixed. At least the license of the Boehm GC allows blatent copy/pasting into LGPLed sources ;-) . If it works, expect a patch by the end of the week. Maciej Stachowiak wrote:
On Jun 11, 2005, at 3:16 PM, Justin Haygood wrote:
the Win32 API simply does not allow getting the base stack address of a thread, because:
1. not stable.. Windows *WILL* and *DOES* move that base address at will.
This part seems unlikely - I could imagine moving the physical address of the stack, but what would be the point of moving the virtual address? Further, this would break any code that kept a pointer to anything on the stack.
But as Darin pointed out, it doesn't matter, because you only need to get it at one particular point in time, it does not need to be stable for all time.
2. Its exclusively chosen and managed by Windows itself.. no ands, buts, or ors about it.
It's ok that Windows chooses it - it's chosen by the OS on pretty much all platforms. We don't need to change the stack base, just to get it.
What would be an alternative way to implement a conservative GC that I can use?
My suggestion for how to research this would be to look at the code for the Boehm garbage collector. This is a portable conservative GC implementation for C++, so they must have some way of getting the range of the stack on windows. I'm not sure if the Boehm GC is threadsafe, but as I pointed out it should be sufficient to just get the stack base for the current thread or for the main thread, and to disable marking of other threads.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
I took a quick peek in the source and it does appear to have a way to get the stack base on win32.
Regards, Maciej
Ouch, crash in markStackObjectsConservatively() The following two lines essentially cause the crash: char **p = (char **)start; char **e = (char **)end; start and end work, and according to the debugger have the correct values. p and e also have correct values, BUT also the debugger has this to say about them: p: expression can't be evaluated e: Bad Ptr Maybe a Windows only quirk?
On Jun 12, 2005, at 9:33 AM, Justin Haygood wrote:
Ouch, crash in markStackObjectsConservatively()
The following two lines essentially cause the crash:
char **p = (char **)start; char **e = (char **)end;
start and end work, and according to the debugger have the correct values.
p and e also have correct values, BUT also the debugger has this to say about them:
p: expression can't be evaluated e: Bad Ptr
That's really weird. Are you still having this problem? I don't have access to a Windows box at the moment so I have no idea what would be wrong. Perhaps windows doesn't like the cast to a doubly indirect pointer for some reason. Or maybe it is trying to implicitly double- deference them in the debugger, which of course would not work since they point to spots on the stack that likely are not themselves valid pointers. Regards, Maciej
participants (3)
-
Darin Adler
-
Justin Haygood
-
Maciej Stachowiak