The motivation usually given for GC.KeepAlive in .NET is the following
scenario:
class File{
IntPtr handle;
[DllImport(...)]
extern void NativeWrite(IntPtr handle, byte b);
[DllImport(...)]
extern void NativeFree(IntPtr handle);
public void Write(byte b){
NativeWrite(this.handle, b);
GC.KeepAlive(this);
}
~File(){
NativeFree(handle);
}
}
Without the KeepAlive call, the object might be considered unreachable at
the start of the NativeWrite call, which might cause the handle to be freed
concurrently with the NativeWrite call.
It's not always recognized, but I think this is just a special case of what
this list talks about.
Bart
-----Original Message-----
From: owner-javamemorymodel@cs.umd.edu
[mailto:owner-javamemorymodel@cs.umd.edu] On Behalf Of Boehm, Hans
Sent: Tuesday, May 03, 2005 11:00 AM
To: Thomas Hawtin; javaMemoryModel@cs.umd.edu
Subject: RE: JavaMemoryModel: Finalization idioms
I think we really need keepAlive in the library. Perhaps java.lang.ref
is a good place to put it. If you implement in the standard
library, with suitable VM cooperation, it should be nearly free.
.NET has GC.KeepAlive which I believe can be used for this purpose,
though the primary motivation there seems to be different.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:10 EDT