Re: Best Ref-counting algorithms?

=?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com>
Sun, 2 Aug 2009 07:54:06 -0700 (PDT)

          From comp.compilers

Related articles
[31 earlier articles]
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-18)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-07-21)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-22)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-07-25)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-07-27)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-07-30)
Re: Best Ref-counting algorithms? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2009-08-02)
Re: Best Ref-counting algorithms? gneuner2@comcast.net (George Neuner) (2009-08-03)
Re: Best Ref-counting algorithms? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-08-07)
| List of all articles for this month |

From: =?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com>
Newsgroups: comp.compilers
Date: Sun, 2 Aug 2009 07:54:06 -0700 (PDT)
Organization: Compilers Central
References: 09-07-018 09-07-039 09-07-043 09-07-054 09-07-060 09-07-066 09-07-071 09-07-073 09-07-082 09-07-090 09-07-101 09-07-116
Keywords: GC
Posted-Date: 02 Aug 2009 15:04:24 EDT

On Jul 30, 6:28 am, George Neuner <gneun...@comcast.net> wrote:
> On Mon, 27 Jul 2009 11:18:56 -0700 (PDT), Christoffer Lernv
> <le...@dragonascendant.com> wrote:
>> In the case of an OO language with dynamic dispatch, then if I'm not
>> mistaken it's not really possible to tell what happens to any of the
>> arguments of a method invocation (including the object itself) at
>> compile time.
>
>> It's only post-fact (when returning from the current scope) one is in
>> a position to determine is the object will outlive the current scope
>> or not.
>
> Even though the control path is not determined until run time, it is
> still statically specified (even in Lisp where you can add/subtract
> methods at run time). Although you don't know which control path will
> be taken, you still know that (depending on what the language allows)
> only actual OO objects, local structures or pointers to them can
> possibly escape. The analysis considers the set of potential escapees
> passed to the static method call. The actual types involved don't
> matter, the analysis is only concerned with names.


If I borrow an example from some Objective-C sample code:


- (void)awakeFromNib {
        NSArray *aspects = [self aspects];
        NSUInteger i, c = [aspects count];


        NSString *path;
        NSData *rtfData = nil;


        // Create the NSTextStorage and load the default text file
        path = [[NSBundle bundleForClass:[self class]]
pathForResource:@"README" ofType:@"rtf"];
        rtfData = [NSData dataWithContentsOfFile:path];
        _textStorage = [[NSTextStorage allocWithZone:[self zone]]
initWithRTF:rtfData documentAttributes:NULL];


        // Load the popup.
        [aspectPopUpButton removeAllItems];
        for (i=0; i<c; i++) {
                [aspectPopUpButton addItemWithTitle:[[aspects objectAtIndex:i]
aspectName]];
        }


        // Set up an initial aspect to view
        if (c > 0) {
                [self swapInAspectAtIndex:0];
        } else {
                // No aspects!
                [aspectPopUpButton addItemWithTitle:NSLocalizedString(@"No
Aspect", @"Item title for aspect popup if no aspects exist.")];
        }
}


Can we say anything at all about the non-primitives here?


We create the objects NSString path and NSData rtfData, but both of
those are argment for methods that has implementations that are
determined at runtime, which means we cannot determine if the extent
of these objects need to outlive the current scope.


In fact, I cannot think of any non-trivial object usage where we can
assert that escape is impossible, since even


SomeObject *someObject = [[SomeObject alloc] init];


could possibly already cause "someObject" to be registered to an
object outside the scope of the current function.


That's why I meant that there is an issue with dynamic dispatch.




/Christoffer


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.