This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]