From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18787 invoked by alias); 29 Aug 2010 16:58:19 -0000 Received: (qmail 18770 invoked by uid 22791); 29 Aug 2010 16:58:18 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp1.iitb.ac.in (HELO smtp1.iitb.ac.in) (203.78.217.149) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sun, 29 Aug 2010 16:58:10 +0000 Received: (qmail 559 invoked from network); 29 Aug 2010 22:28:06 +0530 Received: from unknown (HELO ldns2.iitb.ac.in) (10.200.12.2) by smtp1.iitb.ac.in with SMTP; 29 Aug 2010 22:28:06 +0530 Received: (qmail 28538 invoked by uid 510); 29 Aug 2010 22:28:06 +0530 Received: from 10.200.12.201 by ldns2 (envelope-from , uid 501) with qmail-scanner-2.08 ({clamdscan: 0.96.1-exp-debug/11730} spamassassin: 3.3.1. Clear:RC:1(10.200.12.201):SA:0(0.0/7.0):. Processed in 5.317217 secs); 29 Aug 2010 16:58:06 -0000 X-Envelope-From: uday@cse.iitb.ac.in Received: from unknown (HELO smtp-auth.iitb.ac.in) (10.200.12.201) by ldns2.iitb.ac.in with SMTP; 29 Aug 2010 22:28:00 +0530 Received: from [192.168.1.101] (unknown [10.161.25.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-auth.iitb.ac.in (Postfix) with ESMTP id 5AD3F13900; Sun, 29 Aug 2010 22:27:53 +0530 (IST) Message-ID: <4C7A918F.2010101@cse.iitb.ac.in> Date: Sun, 29 Aug 2010 19:49:00 -0000 From: "Uday P. Khedker" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: gcc@gcc.gnu.org CC: J Decker Subject: Re: Guidance needed: hi-level steps to track an object until its destruction References: <543240.70359.qm@web88108.mail.re2.yahoo.com> <1283015110.3067.37.camel@glinka> <4C7A47C5.8060700@cse.iitb.ac.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00439.txt.bz2 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 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. >>