www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is there an object on given memory address?

reply "tcak" <tcak gmail.com> writes:
Is there any "reliable" way to determine whether there is a 
certain type of object in memory at a given address?

I am going to send the memory address of an object to another 
program over pipes. Then after a while, other program will send 
that memory address, and main program will try to address the 
object. (Please do not concern about security). What I am worried 
about is whether the object is still there, or garbage collector 
has already removed it, or another object has come on same 
address.
Feb 12 2015
parent reply "tcak" <tcak gmail.com> writes:
On Thursday, 12 February 2015 at 10:03:18 UTC, tcak wrote:

 Is there any "reliable" way to determine whether there is a 
 certain type of object in memory at a given address?

 I am going to send the memory address of an object to another 
 program over pipes. Then after a while, other program will send 
 that memory address, and main program will try to address the 
 object. (Please do not concern about security). What I am 
 worried about is whether the object is still there, or garbage 
 collector has already removed it, or another object has come on 
 same address.


BTW, I have already got the address of object into a "size_t" 
type variable and sent it. That is not the problem part.
Feb 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 12 February 2015 at 10:04:29 UTC, tcak wrote:

 BTW, I have already got the address of object into a "size_t" 
 type variable and sent it. That is not the problem part.


How reliable do you want? You would have to either "pin the 
object" by registering a root to it to prevent it from being 
moved or freed.



Or send a hash of the object along with the memory address, then 
query the GC wether the memory is still allocated.
Feb 12 2015
next sibling parent reply "tcak" <tcak gmail.com> writes:
 Or send a hash of the object along with the memory address, 
 then query the GC wether the memory is still allocated.


This part sounds interesnting. How does that GC querying thing
works exactly?
Feb 12 2015
parent "Baz" <bb.temp gmx.com> writes:
On Thursday, 12 February 2015 at 11:14:05 UTC, tcak wrote:

 Or send a hash of the object along with the memory address, 
 then query the GC wether the memory is still allocated.


 This part sounds interesnting. How does that GC querying thing
 works exactly?


std [doc][1] is your friend but if you need guidance.
---
import core.memory : GC;
bool is_gc_allocated = addrOf(ptd) != null;
---
Feb 12 2015
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim 
Grøstad wrote:

 then query the GC wether the memory is still allocated.


This is racy, though. Someone (or the GC) could have freed the 
object in the meantime, and a new object of potentially different 
type could have taken its place. You won't get around pinning it.
Feb 12 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz wrote:

 On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim 
 Grøstad wrote:

 then query the GC wether the memory is still allocated.


 This is racy, though. Someone (or the GC) could have freed the 
 object in the meantime, and a new object of potentially 
 different type could have taken its place. You won't get around 
 pinning it.


It will statistically work for objects that are large and have 
high entropy. Just hash the fields you want to be the same. If 
entropy is a problem add a unique instance id that is a large 
random bit string and make sure it is cleared when the object is 
released.

It's the same technique used for IDs in distributed systems under 
the assumption that the probability of hardware failure is larger 
than the probability of a ID collision... but you have to do the 
math to be sure that the probability of failure is acceptable.
Feb 12 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 12 February 2015 at 16:27:21 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 12 February 2015 at 15:53:07 UTC, Marc Schütz 
 wrote:

 On Thursday, 12 February 2015 at 10:16:49 UTC, Ola Fosheim 
 Grøstad wrote:

 then query the GC wether the memory is still allocated.


 This is racy, though. Someone (or the GC) could have freed the 
 object in the meantime, and a new object of potentially 
 different type could have taken its place. You won't get 
 around pinning it.


 It will statistically work for objects that are large and have 
 high entropy. Just hash the fields you want to be the same. If 
 entropy is a problem add a unique instance id that is a large 
 random bit string and make sure it is cleared when the object 
 is released.

 It's the same technique used for IDs in distributed systems 
 under the assumption that the probability of hardware failure 
 is larger than the probability of a ID collision... but you 
 have to do the math to be sure that the probability of failure 
 is acceptable.


Whoaa, that's just horrible! *shudder*
Feb 12 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 12 February 2015 at 16:56:24 UTC, Marc Schütz wrote:

 Whoaa, that's just horrible! *shudder*


I know, but it works.
Feb 12 2015