Hello,

I have been searching for a way to allow the kernel to read processes' pages' contents so that it tells if there are pointers or not. If it finds pointers, it should 'trace' them or reference count their referent object.

I would appreciate it if anyone tells me if there is an existing method to do this in the kernel or gives me any hints.

The thing that gives me a headache is pointers representation in memory. If I use a similar way to that of Boehm-Demers-Weiser it would incur high penalties on both performance and responsiveness. But most importantly, misidentification of true pointers will be more of a subject to the running programmes and their programming languages.

I will be glad if someone can help me find pointers in memory based on their representation. I am working with an Intel Core 2 Duo and Pentium 4.

Thanks in advance

I'm not certain I understand your question, but if you're asking what I think you're asking then the answer is "it can't be done and it wouldn't be useful if you could." On x86 architectures, a pointer is implemented as an integer, so without knowing the context, if you just looked at the whole memory space it would be indistinguishable from an integer.

Every program has pointers. You would need to write something incredibly trivial not to use pointers. In C, every time you use a string of text, you use a pointer. Any given application, depending on how complex it is, could use anywhere from a few dozen to a few million pointers. These pointers may point to any data type.

Thanks. I get what you are saying. I was really asking out of despair . I was hoping that some good guy had found a way around, it doesn't seem so anyway.

To some extent, some integers may be ruled out depending on the installed amount of memory. Combined with address space limits of a process, other integers may be ruled out as well.

If it can be done, it will be of use to me at least. Because it will allow me to estimate and/or trace the heap graph without run-time system help.

Thanks again mate.

Do you know what the particular pointers are pointed at? You'll do better by just trying to search for the data structures pointed to. You can try to make some inferences from that. IE, ascii strings will be a sequence of bytes all with the same first bit and terminated with a zero byte, for example.

When program is loaded into the memory for execution, kernel translates addresses used in the program to the physical memory address. In majority of architectures, including Pentium, program and data are located in the same memory space. It will be extremely hard for you to find pointers. In general case, you would need to know starting point of your program, and then disassemble it to get rough idea what is going on. But on another hand, if you know map file of your program (it could be produces by giving special option to the linker), or event better - create layout of your own memory use, by using linker command file. Then the task becomes much easier, because now you know where to look.

It's important to remember that, while rsahok is correct that the map file will help you find pointers, it will only help you find *certain* pointers. That is, it will help you locate pointers declared on the stack, like this:
But it may not help if you have, say, an array of pointers dynamically allocated. Then you may get from the map file where the pointer to the array is, you have to dereference that pointer yourself every time and implement some way of knowing how large the array is, etc.

In short, if you don't have access to the source of the program in question, then this is effectively impossible. If you do, then there is almost certainly a better way to do what you're trying to. For instance, after every allocation of a pointer, do a printf("%u", ptr);

Thanks guys, unfortunately I am more interested in the heap rather than in the stack. What I am trying to do is to garbage collect the heap. This is not to be done from inside programmes or their run-time systems, it should be done in the kernel.

This is why I don't have a previous knowledge of the memory layout of programmes. So, I was searching for a way to distinguish pointers in memory. As you probably know, there is a conservative algorithm to do garbage collection in similar settings, but it has many limitations; objects cannot be moved because the algorithm can't be certain whether pointers are true pointers. More importantly, this algorithm is subject to programming styles and memory allocation manners.

The algorithm operates on a garbage collected heap leaving objects allocated on the normal heap untouched.

In short, what I am trying to do is use some kernel data structures to store references and operate on them. But the problem as you know is pointer identification itself.

A pointer is a pointer because of its assignment, this is what I was thinking last night. If I make the run-time inform the kernel, or any other process, of pointers' locations and updates, the whole idea will be blown by the intensive overhead - unless someone has a better idea which I don't know about of course.

Thanks again guys.

I hate to be the bringer of bad news, but garbage-collecting an application from the kernel without the program helping is impossible. That said, there are any number of workarounds to do something like this. I'd recommend reference-counting smart-pointers. There are any number of implementations of this, just look around. But if you had your heart set on garbage collecting non-cooperating code, it's just not going to happen, sorry.

No bad news Patrick, It happened that I had the time to spend on some 'bogus' ideas . So I decided to go on. I am actually more into AI, but the idea was appealing, you know.

Thanks mate.