Re: Guidance needed: hi-level steps to track an object until its destruction

["Uday P. Khedker" <uday@cse.iitb.ac.in>]

Unfortunately I am not aware of C# implementation so can't respond to this...

Uday.

J Decker wrote, On Sunday 29 August 2010 05:32 PM:
> Just out of curiosity - isn't this what C# does with objects?  would
> it perhaps be something like that in how mcs (mono) builds objects and
> tracks their lifespan?
>
> On Sun, Aug 29, 2010 at 4:43 AM, Uday P. Khedker<uday@cse.iitb.ac.in>  wrote:
>>
>>> I am not sure that is easily feasible. I would believe it is impossible.
>>>
>>> Within the compiler (or inside a GCC plugin, or inside a GCC extension
>>> coded in MELT), you probably are able change/inspect C++ classes&    every
>>> other declaration any compiler is tracking. You are also able to find
>>> every occurrence of variables containing a pointer to such classes.
>>
>>>
>>> However, you are apparently willing to track a single *instance* of such
>>> a class, and this instance is in the execution of the compiled program
>>> [not inside the compiler]. This means that you are able to deal with all
>>
>>
>> To put it in other words: Here the issue is seeking runtime information at
>> compile time. An object is a run time entity. At compile time, we only see
>> the class. However, we also see the statements that create an object and
>> manipulate it. Although it is not possible to track each object distinctly,
>> a compile time approximation is certainly possible. And that is where
>> creativity
>> in compiler research lies. The better the approximations, the better the
>> gains.
>> For example, all objects that get created by a given statement can be
>> treated
>> alike. There is no way of distinguishing between them at compile time, but
>> perhaps
>> there is no need to do so because all of them are likely to be treated alike
>> at run time. if an object O1 and O2 are created by the same statement,
>> asking
>> the question whether a method m1 is invoked for O1 does not need us to
>> distinguish
>> between O1 and O2.
>>
>> To summarize, a good approximation is indeed possible at compile time.
>>
>>
>>> the aliasing&    pointer equivalence issues (a task known to be
>>> impossible). How can the compiler surely know that pointer p in [a
>>> particular instruction of] method YourClass::foo() is never (or
>>> sometimes, or always) pointing to the same instance -in the running
>>> process of the compiled program- as pointer q in method yourclass::bar()
>>
>> Basile, you keep mentioning that English is not your first language and I
>> appreciate your politeness for reminding the reader for that (English is not
>> the first language for me too). It is in that light that I would like to
>> point
>> out that your use of word "impossible" is a little too strong. Perhaps you
>> mean
>> difficult. It is impossible if you want exact information. However, if
>> imprecisions can be tolerated for some gains, excellent approximations are
>> possible _within_ a procedure body which is what Jeff asked for, to begin
>> with.
>>
>> We have been working on this problem (pointer analysis) for a while but
>> are quite far from production implementation. Our ideas now seem to mature
>> a bit and whenever we have a conference paper, I will be happy to share it
>> with the gcc folks.
>>
>>> Or maybe you want to instrument your compiler so that for every code
>>> emitted for method yourclass::gee() you add a first block which checks
>>> that the this reciever is not a given pointer.
>>>
>>> In other words&    C++ parlance, you could (this is doable, but not
>>> trivial) hack the compiler so that at the start of every method (i.e.
>>> member function in C++) the equivalent of the following C++ code has
>>> been magically added
>>>
>>>    extern "C" YourClass* hunted_yourclass_pointer;
>>>    extern "C" void some_error_routine(void);
>>>
>>>    if (this == hunted_yourclass_pointer)
>>>      some_error_routine();
>>
>> This is a very good way of paraphrasing the "ideal" requirement.
>>
>> Regards,
>>
>> Uday.
>>