Re: Implementation of CFBridgingRelease() on GNUstep
Hi Daniel, As everything currently stands, the answer to your question is, yes, CFBridgingRelease is eyewitness to CFRelease. We had a discussion about it either early this morning or last month. That said, since you are the second person to ask about these functions, I believe the safest route is to implement it. I'm going to be out of town until Monday, but I can look at into it then. Based on David's previous comments, I believe the best approach is to make it an alias to objc_release(), if that function exists, and an alias to CFRelease, otherwise. David, can you confirm that is the smartest approach? I apologize for any typos, I'm on my phone. Stefan On May 31, 2017 19:16, "Daniel Ferreira (theiostream)" wrote: Hi there! I'm Daniel Ferreira, and I'm the student who will be contributing to GNUstep through Google Summer of Code for the next three months. I'll be working on getting WebKit to run on top of GS. That being said, one of the first things I stumbled upon when building WebKit against GS was the absence of a GS implementation of CFBridgingRelease (https://developer.apple.com/reference/foundation/1587932-cfbridgingrelease ). I asked Ivan about how to deal with this and he was under the impression that in GNUstep, CFBridgingRelease() should be equivalent to CFRelease(), but he couldn't state that with absolute certainty. So this is the question: are they somehow equivalent in CoreBase's understanding of ARC? And if not, how would you suggest this be implemented? I didn't see transferring memory ownership to ARC being dealt with on threads like this[1] about supporting ARC on CoreBase. Also, only GS thread I could find that addresses the function in particular is this one[2], and it doesn't look like much help either. Thanks, -- Daniel. [1]: http://lists.gnu.org/archive/html/discuss-gnustep/2015-02/msg00021.html [2]: http://lists.gnu.org/archive/html/gnustep-dev/2015-12/msg00020.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
Can you point me to where these discussions happened? I'd love to understand in more detail why this is so. -- Daniel Sent from my iPhone On Wed, May 31, 2017 at 9:05 PM -0300, "Stefan Bidigaray" wrote: Hi Daniel,As everything currently stands, the answer to your question is, yes, CFBridgingRelease is eyewitness to CFRelease. We had a discussion about it either early this morning or last month. That said, since you are the second person to ask about these functions, I believe the safest route is to implement it. I'm going to be out of town until Monday, but I can look at into it then. Based on David's previous comments, I believe the best approach is to make it an alias to objc_release(), if that function exists, and an alias to CFRelease, otherwise. David, can you confirm that is the smartest approach? I apologize for any typos, I'm on my phone. Stefan On May 31, 2017 19:16, "Daniel Ferreira (theiostream)" wrote: Hi there! I'm Daniel Ferreira, and I'm the student who will be contributing to GNUstep through Google Summer of Code for the next three months. I'll be working on getting WebKit to run on top of GS. That being said, one of the first things I stumbled upon when building WebKit against GS was the absence of a GS implementation of CFBridgingRelease (https://developer.apple.com/reference/foundation/1587932-cfbridgingrelease). I asked Ivan about how to deal with this and he was under the impression that in GNUstep, CFBridgingRelease() should be equivalent to CFRelease(), but he couldn't state that with absolute certainty. So this is the question: are they somehow equivalent in CoreBase's understanding of ARC? And if not, how would you suggest this be implemented? I didn't see transferring memory ownership to ARC being dealt with on threads like this[1] about supporting ARC on CoreBase. Also, only GS thread I could find that addresses the function in particular is this one[2], and it doesn't look like much help either. Thanks, -- Daniel. [1]: http://lists.gnu.org/archive/html/discuss-gnustep/2015-02/msg00021.html [2]: http://lists.gnu.org/archive/html/gnustep-dev/2015-12/msg00020.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
See: http://lists.gnu.org/archive/html/discuss-gnustep/2017-04/msg00041.html Germán El jue, 01-06-2017 a las 00:07 +, Daniel Ferreira escribió: > Can you point me to where these discussions happened? I'd love to > understand in more detail why this is so. > > -- Daniel > Sent from my iPhone > > > > On Wed, May 31, 2017 at 9:05 PM -0300, "Stefan Bidigaray" < > stefanb...@gmail.com> wrote: > > > Hi Daniel, > > As everything currently stands, the answer to your question is, > > yes, CFBridgingRelease is eyewitness to CFRelease. We had a > > discussion about it either early this morning or last month. > > > > That said, since you are the second person to ask about these > > functions, I believe the safest route is to implement it. I'm going > > to be out of town until Monday, but I can look at into it then. > > > > Based on David's previous comments, I believe the best approach is > > to make it an alias to objc_release(), if that function exists, and > > an alias to CFRelease, otherwise. David, can you confirm that is > > the smartest approach? > > > > I apologize for any typos, I'm on my phone. > > > > Stefan > > > > > > On May 31, 2017 19:16, "Daniel Ferreira (theiostream)" < > > bnm...@gmail.com> wrote: > > Hi there! I'm Daniel Ferreira, and I'm the student who will be > > contributing to GNUstep through Google Summer of Code for the next > > three months. I'll be working on getting WebKit to run on top of > > GS. > > > > That being said, one of the first things I stumbled upon when > > building > > WebKit against GS was the absence of a GS implementation of > > CFBridgingRelease > > (https://developer.apple.com/reference/foundation/1587932-cfbridgin > > grelease). > > I asked Ivan about how to deal with this and he was under the > > impression that in GNUstep, CFBridgingRelease() should be > > equivalent > > to CFRelease(), but he couldn't state that with absolute certainty. > > > > So this is the question: are they somehow equivalent in CoreBase's > > understanding of ARC? And if not, how would you suggest this be > > implemented? I didn't see transferring memory ownership to ARC > > being > > dealt with on threads like this[1] about supporting ARC on > > CoreBase. > > Also, only GS thread I could find that addresses the function in > > particular is this one[2], and it doesn't look like much help > > either. > > > > Thanks, > > -- Daniel. > > > > [1]: http://lists.gnu.org/archive/html/discuss-gnustep/2015-02/msg0 > > 0021.html > > [2]: > > http://lists.gnu.org/archive/html/gnustep-dev/2015-12/msg00020.html > > > > ___ > > Gnustep-dev mailing list > > Gnustep-dev@gnu.org > > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
Hm, I get how this works for y = CFBridgingRetain(x) being equivalent to CFRetain(): add +1 to x's reference count, let the ARC runtime get rid of all the references to x, we've still got a 1 that can be later CFRelease()d. However, this is still not quite clear to me when it comes to CFBridgingRelease() being equivalent to CFRelease(). If I do something like `s = CFRelease(CFStringCreate(...))`, s would reach reference count 0 and be deallocated, thus rendering it unusable as an Objective-C object. Or am I wrong here? -- Daniel. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
Hmm, good point. What exactly does CFBridgingRelease do? I thought it would just undo a previous CFBridgingRetain, but what you're saying is that it could be used on any CF object, not just objc objects that had been "converted" to CF. I'll have a look at the documentation in more detail tomorrow and get back to you. On May 31, 2017 23:07, "Daniel Ferreira (theiostream)" wrote: > Hm, I get how this works for y = CFBridgingRetain(x) being equivalent > to CFRetain(): add +1 to x's reference count, let the ARC runtime get > rid of all the references to x, we've still got a 1 that can be later > CFRelease()d. > > However, this is still not quite clear to me when it comes to > CFBridgingRelease() being equivalent to CFRelease(). If I do something > like `s = CFRelease(CFStringCreate(...))`, s would reach reference > count 0 and be deallocated, thus rendering it unusable as an > Objective-C object. Or am I wrong here? > > -- Daniel. > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
CFBridgingRetain() and CFBridgingRelease() should to exactly what the
__bridge_retained and __bridge_transfer compiler directives do, so an
insight on how the libobjc2 ARC runtime handles this case will
probably give us an answer.
However, according to Mike Ash[1] in an article from 2011 on the dawn of ARC,
> CFStringRef valueCF = CFPreferencesCopyAppValue(CFSTR("someKey"),
> CFSTR("com.company.someapp"));
> NSString *value = (__bridge NSString *)valueCF;
> CFRelease(valueCF);
> [self useValue: value];
is functionally equivalent to:
> NSString *value =
> CFBridgingRelease(CFPreferencesCopyAppValue(CFSTR("someKey"),
> CFSTR("com.company.someapp")));
> [self useValue: value];
So it seems to me logically that the behavior of CFBridgingRelease()
should be that of reducing the reference count of the object but not
deallocate it if it reaches zero, assuming ARC will immediately add
one to the reference count when the CF type becomes an Objective-C
object.
As for CFBridgingRetain(), the same effect will be attained anyway if
we CFRetain() when ARC releases everything on ObjC-land, but I wonder
if it should do anything else.
[1]:
https://www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
On 1 Jun 2017, at 17:49, Daniel Ferreira (theiostream) wrote:
>
> CFBridgingRetain() and CFBridgingRelease() should to exactly what the
> __bridge_retained and __bridge_transfer compiler directives do, so an
> insight on how the libobjc2 ARC runtime handles this case will
> probably give us an answer.
>
> However, according to Mike Ash[1] in an article from 2011 on the dawn of ARC,
>
>> CFStringRef valueCF = CFPreferencesCopyAppValue(CFSTR("someKey"),
>> CFSTR("com.company.someapp"));
>> NSString *value = (__bridge NSString *)valueCF;
>> CFRelease(valueCF);
>> [self useValue: value];
>
> is functionally equivalent to:
>
>> NSString *value =
>> CFBridgingRelease(CFPreferencesCopyAppValue(CFSTR("someKey"),
>> CFSTR("com.company.someapp")));
>> [self useValue: value];
>
> So it seems to me logically that the behavior of CFBridgingRelease()
> should be that of reducing the reference count of the object but not
> deallocate it if it reaches zero, assuming ARC will immediately add
> one to the reference count when the CF type becomes an Objective-C
> object.
>
> As for CFBridgingRetain(), the same effect will be attained anyway if
> we CFRetain() when ARC releases everything on ObjC-land, but I wonder
> if it should do anything else.
>
> [1]:
> https://www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html
You can see what any of these do by looking at the LLVM IR generated by clang:
$ cat arc.m
void* bridge(id x)
{
return (__bridge void*)x;
}
id bridge_back(void *x)
{
return (__bridge id)x;
}
void* bridge_retained(id x)
{
return (__bridge_retained void*)x;
}
id bridge_retained_back(void *x)
{
return (__bridge_transfer id)x;
}
$ clang -S -emit-llvm -fobjc-arc -o - arc.m -O2
define i8* @bridge(i8*) local_unnamed_addr #0 {
ret i8* %0
}
define i8* @bridge_back(i8*) local_unnamed_addr #0 {
%2 = tail call i8* @objc_retain(i8* %0) #2
%3 = tail call i8* @objc_autoreleaseReturnValue(i8* %0) #2
ret i8* %0
}
define i8* @bridge_retained(i8*) local_unnamed_addr #0 {
%2 = tail call i8* @objc_retain(i8* %0) #2
ret i8* %0
}
define i8* @bridge_retained_back(i8*) local_unnamed_addr #0 {
%2 = tail call i8* @objc_autoreleaseReturnValue(i8* %0) #2
ret i8* %0
}
As you can see, __bridge_retained becomes an objc_retain call, but __bridge is
a no-op, which exists solely for the compiler and static analysers to use to
understand that the programmer didn’t intend an ownership transfer.
In contrast, a __bridge_retained cast does transfer ownership. The recipient
of the void* is responsible for releasing the object. A __bridge_transfer in
the other direction does precisely this. As I understand it,
CFBridgingRelease() is equivalent to __bridge_transfer, and so wants to become
a call to objc_autorelease() (in this example, the transfer happens on the
return value and so the call becomes objc_autoreleaseReturnValue() -
CFBridgingRelease should probably call that directly if it’s a function,
because that will allow the caller to pop it off the autorelease stack if
required). The ownership of the reference is transferred to ARC, but the
reference remains valid.
It absolutely should *NOT* decrement the reference count but not deallocate the
object if it reaches zero!
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
On Thu, Jun 1, 2017 at 2:29 PM, David Chisnall wrote: > On 1 Jun 2017, at 17:49, Daniel Ferreira (theiostream) > wrote: > It absolutely should *NOT* decrement the reference count but not deallocate > the object if it reaches zero! Makes perfect sense. I think deep in my subconscious I meant "reduce-refcount-to-zero-but-do-not-deallocate" as an autorelease (we're releasing! and deallocating later! Although we are certainly not playing with the refcount yet). Anyway, I'll leave this matter to psychology and move on to implementing these functions on CoreBase. Thank you for the explanation! :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
Hi Daniel, I would just like to mention a few things... CoreBase officially supports both GNUstep and GNU runtimes, so it is important that we do not break that. Additionally, clang/llvm and GCC are supported. A configure test will be required for objc_release/_retain/_autoreleaseReturnValue, and we need to make sure GCC and the GNU runtime are still working. Ideally, we also need tests added to the test suite. Are these two functions only supposed to work when ARC is available? Or can they be used with GCC/GNU-runtime and manual ref. counting? If they have to work with GCC and manual ref. count, I assume CFBridgingRelease would be a no-op when the object is a CF-type and a ref. decrement when it is a objc object. Does that sound about right? I had some time to think about this a little today, so I think I understand what the purpose of these functions and how to implement them. I won't have a chance to even look at it until Monday, though. And even then, I will need to learn how to use git (which completely ignorant about). Stefan On Thu, Jun 1, 2017 at 9:46 PM, Daniel Ferreira (theiostream) < bnm...@gmail.com> wrote: > On Thu, Jun 1, 2017 at 2:29 PM, David Chisnall wrote: > > On 1 Jun 2017, at 17:49, Daniel Ferreira (theiostream) > wrote: > > It absolutely should *NOT* decrement the reference count but not > deallocate the object if it reaches zero! > > Makes perfect sense. I think deep in my subconscious I meant > "reduce-refcount-to-zero-but-do-not-deallocate" as an autorelease > (we're releasing! and deallocating later! Although we are certainly > not playing with the refcount yet). Anyway, I'll leave this matter to > psychology and move on to implementing these functions on CoreBase. > > Thank you for the explanation! :) > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
On Fri, Jun 2, 2017 at 12:20 AM, Stefan Bidigaray wrote: > Are these two functions only supposed to work when ARC is available? Or can > they be used with GCC/GNU-runtime and manual ref. counting? If they have to > work with GCC and manual ref. count, I assume CFBridgingRelease would be a > no-op when the object is a CF-type and a ref. decrement when it is a objc > object. Does that sound about right? These functions have "ARC" stamped in their description, however they seem to work (i.e. not throw any sort of exception or crash) if they are called outside an ARC context in my Mac, but I'm really not sure what their behavior looks like in this case. Tomorrow I can try to investigate if they affect the object's retain count and see if we get some knowledge out of that. Nevertheless, the calls to objc_retain()/objc_autoreleaseReturnValue() will *only* happen in an ARC context, and since that's only the case when we have the libobjc2 + Clang combination (correct me if I'm wrong), we can wrap calls to these functions around a __has_feature() macro and a GCC build wouldn't be affected by this implementation. Then we can configure a test for this that also does the same __has_feature() check and skips if we're not arc-able. As for tests, I agree they are totally necessary, although I'm not quite sure how to write them. I really appreciate suggestions. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
On 2 Jun 2017, at 04:20, Stefan Bidigaray wrote: > > CoreBase officially supports both GNUstep and GNU runtimes, so it is > important that we do not break that. Additionally, clang/llvm and GCC are > supported. A configure test will be required for > objc_release/_retain/_autoreleaseReturnValue, and we need to make sure GCC > and the GNU runtime are still working. Ideally, we also need tests added to > the test suite. The correct solution here would probably be to implement the ARC functions in ObjectiveC2.framework, which provides compat for the GCC runtime. A working implementation would simply call the relevant -retain, -release, and -autorelease methods (similarly, the push and pop autorelease pool functions should create an autorelease pool and drain the top autorelease pool. The weak ones are a bit harder to implement, and are probably not worth the bother. > Are these two functions only supposed to work when ARC is available? Or can > they be used with GCC/GNU-runtime and manual ref. counting? If they have to > work with GCC and manual ref. count, I assume CFBridgingRelease would be a > no-op when the object is a CF-type and a ref. decrement when it is a objc > object. Does that sound about right? Yes, they’re just functions. You can use them in Objective-C++ with a pre-ARC compiler to implement ARC via some templates, for example. There’s a pretty noticeable code-size win from calling objc_retain / objc_release rather than -retain / -release too (as well as a performance win if you’re using the GNUstep runtime). I vaguely remember changing the GNUstep RETAIN and RELEASE macros to use these calls if they’re available, but I don’t remember if I committed it. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Implementation of CFBridgingRelease() on GNUstep
On 2 Jun 2017, at 04:37, Daniel Ferreira (theiostream) wrote: > > These functions have "ARC" stamped in their description, however they > seem to work (i.e. not throw any sort of exception or crash) if they > are called outside an ARC context in my Mac, but I'm really not sure > what their behavior looks like in this case. Tomorrow I can try to > investigate if they affect the object's retain count and see if we get > some knowledge out of that. ARC is specifically designed for incremental deployment. Unlike the abortive attempt to add GC to Objective-C, there is no clear distinction between ARC programs and non-ARC programs. Most use ARC in some compilation units and manual RR in others. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
