[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

[Geir Nøklebye]

> Cinder Roxley said:

> The viewer has never used the garbage collector so it?s not an issue.



Why is it that in llopenglview-objc.mm, as en example, we have statement like:

NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] 
initWithAttributes:attrs] autorelease];

or 

- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
[super dealloc];
}

while Apples ARC migration guidelines states:

You cannot explicitly invoke dealloc, or implement or invoke retain, release, 
retainCount, or autorelease.

You can’t invoke dealloc.

Custom dealloc methods in ARC do not require a call to [super dealloc] (it 
actually results in a compiler error). The chaining to super is automated and 
enforced by the compiler.


Or in llwindowmacosx-objc.mm we have code such as:

bool copyToPBoard(const unsigned short *str, unsigned int len)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
NSPasteboard *pboard = [NSPasteboard generalPasteboard];
[pboard clearContents];


NSArray *contentsToPaste = [[NSArray alloc] initWithObjects:[NSString 
stringWithCharacters:str length:len], nil];
[pool release];
return [pboard writeObjects:contentsToPaste];
}

Apple’s documentation specifically says how to rewrite this construct for ARC. 

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/cl/NSAutoreleasePool


So all this code needs to be rewritten to support ARC or it will not run or 
fail on 10.12. 


Geir Nøklebye,___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

[Cinder Roxley]

None of the examples you pasted have anything to do with Apple’s garbage 
collector, hun. They’re just examples of advanced MRR. 

As I already stated, the viewer has never used Apple’s garbage collector. It 
uses a combination of autorelease pools and MRR which is perfectly fine to do, 
especially in Objective-C++ where we are not only managing objective-c objects, 
but C++ objects as well.
 
 
-- 
Cinder Roxley
Sent with Airmail
 

On July 8, 2016 at 1:47:16 PM, Geir Nøklebye (geir.nokle...@dayturn.com 
 ) wrote:

 
Cinder Roxley said:
The viewer has never used the garbage collector so it?s not an issue.


Why is it that in llopenglview-objc.mm, as en example, we have statement like:

NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] 
initWithAttributes:attrs] autorelease];

or 

- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
[super dealloc];
}

while Apples ARC migration guidelines states:

You cannot explicitly invoke dealloc, or implement or invoke retain, release, 
retainCount, or autorelease.

You can’t invoke dealloc.

Custom dealloc methods in ARC do not require a call to [super dealloc] (it 
actually results in a compiler error). The chaining to super is automated and 
enforced by the compiler.


Or in llwindowmacosx-objc.mm we have code such as:

bool copyToPBoard(const unsigned short *str, unsigned int len)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
NSPasteboard *pboard = [NSPasteboard generalPasteboard];
[pboard clearContents];

NSArray *contentsToPaste = [[NSArray alloc] initWithObjects:[NSString 
stringWithCharacters:str length:len], nil];
[pool release];
return [pboard writeObjects:contentsToPaste];
}

Apple’s documentation specifically says how to rewrite this construct for ARC. 

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/cl/NSAutoreleasePool


So all this code needs to be rewritten to support ARC or it will not run or 
fail on 10.12. 


Geir Nøklebye,

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

[Geir Nøklebye]

I cannot see there is anything “advanced”  MRR (manual retain-release) going on 
in:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];

insert your viewer code here

[pool release];


That can’t be handled with @autoreleasepool, if you even need to handle it 
outside the main thread autoreleasepool 


In fact the above is a classic example of the old garbage collector in action. 


Geir, 


> On 8. jul. 2016, at 21.47, Geir Nøklebye  wrote:
> 
>> Cinder Roxley said:
> 
>> The viewer has never used the garbage collector so it?s not an issue.
> 
> 
> 
> Why is it that in llopenglview-objc.mm, as en example, we have statement like:
> 
> NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] 
> initWithAttributes:attrs] autorelease];
> 
> or 
> 
> - (void)dealloc
> {
>   [[NSNotificationCenter defaultCenter] removeObserver:self];
>   [super dealloc];
> }
> 
> while Apples ARC migration guidelines states:
> 
> You cannot explicitly invoke dealloc, or implement or invoke retain, release, 
> retainCount, or autorelease.
> 
> You can’t invoke dealloc.
> 
> Custom dealloc methods in ARC do not require a call to [super dealloc] (it 
> actually results in a compiler error). The chaining to super is automated and 
> enforced by the compiler.
> 
> 
> Or in llwindowmacosx-objc.mm we have code such as:
> 
> bool copyToPBoard(const unsigned short *str, unsigned int len)
> {
>   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
>   NSPasteboard *pboard = [NSPasteboard generalPasteboard];
>   [pboard clearContents];
>   
> 
>   NSArray *contentsToPaste = [[NSArray alloc] initWithObjects:[NSString 
> stringWithCharacters:str length:len], nil];
>   [pool release];
>   return [pboard writeObjects:contentsToPaste];
> }
> 
> Apple’s documentation specifically says how to rewrite this construct for 
> ARC. 
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/cl/NSAutoreleasePool
>  
> 
> 
> 
> So all this code needs to be rewritten to support ARC or it will not run or 
> fail on 10.12. 
> 
> 
> Geir Nøklebye,

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

[Cinder Roxley]

Since it’s clear you just want to argue and have no interest in understanding 
memory management, we’ll leave it at that then. I really doubt the other 
hundred people subscribed to this list are interested.
 
 
-- 
Cinder Roxley
Sent with Airmail
 

On July 8, 2016 at 3:13:44 PM, Geir Nøklebye (geir.nokle...@dayturn.com 
 ) wrote:

 
I cannot see there is anything “advanced”  MRR (manual retain-release) going on 
in:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];


insert your viewer code here

[pool release];


That can’t be handled with @autoreleasepool, if you even need to handle it 
outside the main thread autoreleasepool


In fact the above is a classic example of the old garbage collector in action. 


Geir, 


On 8. jul. 2016, at 21.47, Geir Nøklebye mailto:geir.nokle...@dayturn.com> > wrote:

Cinder Roxley said:
The viewer has never used the garbage collector so it?s not an issue.



Why is it that in llopenglview-objc.mm, as en example, we have statement like:

NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] 
initWithAttributes:attrs] autorelease];

or 

- (void)dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
[super dealloc];
}

while Apples ARC migration guidelines states:

You cannot explicitly invoke dealloc, or implement or invoke retain, release, 
retainCount, or autorelease.

You can’t invoke dealloc.

Custom dealloc methods in ARC do not require a call to [super dealloc] (it 
actually results in a compiler error). The chaining to super is automated and 
enforced by the compiler.


Or in llwindowmacosx-objc.mm we have code such as:

bool copyToPBoard(const unsigned short *str, unsigned int len)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
NSPasteboard *pboard = [NSPasteboard generalPasteboard];
[pboard clearContents];

NSArray *contentsToPaste = [[NSArray alloc] initWithObjects:[NSString 
stringWithCharacters:str length:len], nil];
[pool release];
return [pboard writeObjects:contentsToPaste];
}

Apple’s documentation specifically says how to rewrite this construct for ARC. 

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/cl/NSAutoreleasePool


So all this code needs to be rewritten to support ARC or it will not run or 
fail on 10.12. 


Geir Nøklebye,


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

[Geenz Spad]

https://xkcd.com/386/ 

With that out of the way, autorelease pools don't have much to do with garbage 
collection - in fact the document that you've linked to specifically outlines 
the following with regards to autorelease pools and GC:
> In a garbage-collected environment, there is no need for autorelease pools. 
> You may, however, write a framework that is designed to work in both a 
> garbage-collected and reference-counted environment. In this case, you can 
> use autorelease pools to hint to the collector that collection may be 
> appropriate.


There isn't anything functionally wrong with the code that you have specified, 
unless you count not letting the compiler decide what should be done there as 
being a functional problem (that's how ARC actually works - it's just telling 
the compiler to generate the necessary pools, retains, releases, deallocs, and 
so on as it finds cases where it's needed).  It wouldn't even work under a GC 
or otherwise trigger the GC to do much of anything unless I drained the pool - 
at best it would provide a hint to the GC, and at worst it would no-op.  Even 
then, the viewer still doesn't use GC.  Instead I had it manually allocate and 
deallocate objects as needed, with the exception of the occasional autorelease 
pool.  To my knowledge, manual memory management is still supported under OS X 
10.12, and ARC is still opt-in (or opt-out, depending on what version of Xcode 
you created the project with).  A few tests on my end still show that 
NSAutoreleasePool is still valid, as is autorelease and autorelease blocks, 
when using the latest beta of macOS 10.12 and Xcode.

Now!  That being said, at the time that the code was written ARC wasn't well 
supported under OS X 10.6, which was the viewer's minimum target at the time.  
Of course as time has went on, the viewer's minimum requirements have changed.  
It wouldn't be the worst idea to revisit it, especially since my own coding 
style and skills have improved since I wrote the original code for the Obj-C 
port of the viewer's frontend, but at the same time it doesn't really add much 
value given that you're basically talking about making the compiler do 
something that's already being done manually.  You won't see any massive 
performance gains.  You won't see the viewer magically shed tens of megabytes 
off of its memory footprint.  Sure you could argue that if Apple decides to 
make ARC the law of the land with no MRR being permitted in sight there could 
be some value there, but there's no indication of that happening.  You would be 
doing it literally to future proof something where there's no indication of 
there being a need to do so, and only for any Objective-C objects - C++ objects 
are untouched by ARC.

If you'd like to continue debating how memory management works under 
Objective-C, and NSAutoreleasePool, release, retain, and dealloc's place in it, 
by all means!  Feel free to email me directly, though I'd recommend reading 
this first 
.
  Though I doubt there's much interest on this list in watching such a thing.
> On July 8, 2016 at 3:13:44 PM, Geir Nøklebye (geir.nokle...@dayturn.com 
> ) wrote:
> 
>> I cannot see there is anything “advanced”  MRR (manual retain-release) going 
>> on in:
>> 
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
>> 
>> insert your viewer code here
>> 
>> [pool release];
>> 
>> 
>> That can’t be handled with @autoreleasepool,
>> if you even need to handle it outside the main thread
>> autoreleasepool
>> 
>> 
>> In fact the above is a classic example of the old garbage collector in 
>> action. 
>> 
>> 
>> Geir, 
>> 
>> 
>>> On 8. jul. 2016, at 21.47, Geir Nøklebye >> > wrote:
>>> 
 Cinder Roxley said:
>>> 
 The viewer has never used the garbage collector so it?s not an issue.
>>> 
>>> 
>>> 
>>> Why is it that in llopenglview-objc.mm, as en example, we have statement 
>>> like:
>>> 
>>> NSOpenGLPixelFormat *pixelFormat = [[[NSOpenGLPixelFormat alloc] 
>>> initWithAttributes:attrs] autorelease];
>>> 
>>> or 
>>> 
>>> - (void)dealloc
>>> {
>>> [[NSNotificationCenter defaultCenter] removeObserver:self];
>>> [super dealloc];
>>> }
>>> 
>>> while Apples ARC migration guidelines states:
>>> 
>>> You cannot explicitly invoke dealloc, or implement or invoke retain, 
>>> release, retainCount, or autorelease.
>>> 
>>> You can’t invoke dealloc.
>>> 
>>> Custom dealloc methods in ARC do not require a call to [super dealloc] (it 
>>> actually results in a compiler error). The chaining to super is automated 
>>> and enforced by the compiler.
>>> 
>>> 
>>> Or in llwindowmacosx-objc.mm we have code such as:
>>> 
>>> bool copyToPBoard(const unsigned short *str, unsigned int len)
>>> {
>>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc]init];
>>> NSPasteboard *pboard = [

Re: [opensource-dev] About memory management on macOS 10.12 (Sierra) potentially affecting all viewers

[Cinder Roxley]

On July 8, 2016 at 4:36:39 PM, Geenz Spad (ge...@exodusviewer.com 
 ) wrote:
 
To my knowledge, manual memory management is still supported under OS X 10.12,
It would take an incredible amount of effort to deprecate since you’d need to 
fundamentally change NSObject, and as a result, obsolete everything that has 
ever used the Foundation classes.

and ARC is still opt-in (or opt-out, depending on what version of Xcode you 
created the project with).  A few tests on my end still show that 
NSAutoreleasePool is still valid, as is autorelease and autorelease blocks, 
when using the latest beta of macOS 10.12 and Xcode.
This is correct. It stops working when enabling -fobjc-arc, but that’s more of 
a rule change to force strict ARC compliance than runtime breakage. They just 
no-op those methods under the hood if it sneaks by static analysis.

-- 
Cinder Roxley
Sent with Airmail

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges