Question about Element's ARC

I’m not sure the explanation will be that simple, because it’s the same test result if I add the ((objc_precise_lifetime)) attribute for variable a in objc.

I think this “returned value” optimization is indeed important for ARC, otherwise Apple won’t make those two related runtime methods for objc at the beginning.
So if this optimization does not work as expected in Elements’ ARC, it’s worthy to be investigated.

bugs://73551 got closed with status testcaseerr.

So, what’s happening here is a codegen related issue. the calls used by objc (specifically objc_autoreleaseReturnValue) scan the caller address and look for objc_retainAutoreleasedReturnValue immediately following the call. Depending on the location it would or would not immediately follow it.

(like if you were to insert an NSLog before your createObject call it would probably do what you want)

I’m going to see if i can force llvm generate things in exactly this order.

bugs://73551 got reopened.

bugs://73551 got closed with status fixed.

I do have to note 1 thing. All of this ONLY works in optimized mode (same goes for objc when enabling matching options: -O0 -fobjc-arc-exceptions -fobjc-arc)

OK thanks!
I’m not so familiar with objc compile options yet. Is “-O0 -fobjc-arc-exceptions -fobjc-arc” the default options for a new XCode iOS objc project in debug mode? “-O0” seems the loweast optimize level.

Wel O0 is default. Arc too i think for new projects. Arc exceptions not

Hi carlo, is this fix included in 8.2.88.1887?
I’ve tried the test project (Elements_MemoryLeakTest.zip) in 8.2.88.1887 with Release build ( “Optimize code” option is checked ), and it’s the same result as before (returned object won’t be deallocated until the end of an ARP).

I don’t believe so, no. This probably was fixed for the 8.3 branch. was tis listed in the change log?

indeed it was 8.3

Looking forward to 8.3 beta, thanks :+1:

Probably next week ;). For now we want peopl focused on testing the game for 8.2 so we can find any last issues, before RTM (planned for Friday).

bugs://73551 got reopened.

bugs://73551 got closed with status fixed.

I found it. There’s 1 thing that has to changed in your testcase to make it work: CreateObj should be protected/public really anything but private. If it’s private it will get inlined and the llvm inliner doesn’t currently collapse these two.

Unfortunately I can still reproduce the issue on VS2015 + Elements 8.3.92.1915…

I’ve double checked and ensured following things:

  1. Make createObject public instead of private
  2. Compile in Release mode with “Optmize code” option
  3. Run on iPhone 5s iOS 9.2 simulator
  4. Since the NSLog output sequence may not be completely reliable as I know (http://talk.remobjects.com/t/multiline-log-output-is-out-of-order-or-incomplete-on-ios/7413), I also set a breakpoint on the line “NSLog(“BigObject dealloc!!”);” to see if the BigObject is deallocated by app default ARP instead of compiler optimization.

Right; this was fixed yesterday. It’s fixed in a build you don’t have yet. What I’ve tested:

  • arm64: Works
  • arm: Doesn’t work due to how exception handling works on ios/arm
  • x86_64: Confirmed earlier: Works

atm I can’t test sim (local issue) but it’s likely sim x86_64 works too.

Great! I just misunderstood what you said “I found it” :slight_smile:
I will do more tests when that build is available.

My test results of 8.3.92.1917:

  • arm64(iPhone 6s plus device): Works
  • sim x86_64(iPhone 6s plus sim): Doesn’t work
  1. Hope it can works on sim.
  2. Hope the “private inline” issue can be fixed too, otherwise it will leave a pitfall to make trouble in the future. I’m wondering how Swift solve this problem, because it also supports private access control and this ARC test case works fine there.