I would like to return a ByteArray from my ANE. The bytes will be allocated from the native side (in C). Is this possible? If so, does the AS side become responsible for deallocating the memory, using the normal garbage collector, or should the native side?
I haven't tried the ByteArray, but I couldn't think of any reasons that you can't.
You can clean up your C side code at least in two ways:
1: put clean up code in contextFinalizer, it would be called after Flex side calls dispose(), but only triggers when garbarge collection runs, which means not controlled by you
2: write another method to clean up as you do for your other functions.
Thanks for the answer. Do you mean then that the newly allocated memory is "owned" by the native side of the ANE? My biggest doubt was if, when the ByteArray on the AS side gets garbage collected, it disposes the memory allocated by the native side. If such was the case, then it should not be disposed of on the native side.
it's owned by the ANE, but the ANE is owned by your main application. So, they should have the application id, (not 100% sure). But what I have tried it. use exit 0; in Objective-C side, it would exit the whole application.
I didn't get your second part. Generally, after you call the context.dispose(), it will wait for the garbarge collection run, when gc runs, the objective-c side will trigger the finalizer method, some cleaning up code should be addressed there, or it will stuck in the memory until you application dies.
Please give some details about your concerns.
Thank you, Matthew. Assuming things will happen in this order:
1- My ANE gets initialized in AS
2- My ANE gets initialized in C
3- The AS side creates an empty ByteArray in the stackframe of a function call
4- The AS side calls the ANE to perform some calculation. It passes the ByteArray of step 3, for the result to be stored there
5- The C side performs the calculation
6- The C side allocates memory (malloc) for storing the result and gives it to the ByteArray of step 3
7- The AS side uses the result
8- The function in step 3 returns, making the ByteArray available for garbage collection
9- The ByteArray gets garbage collected and its memory is released
10- My program will exit and the destructor for the C side of the ANE is called
11- The C side of the ANE releases (free) the memory that it previously allocated
12- ... etc.
My doubt is: What does "gives" really mean in step 6: does it mean redirecting a pointer of the AS ByteArray, or does it mean copying the memory to a buffer owned by the ByteArray?
- If it means redirecting a pointer, then step 11 could be wrong, since the memory could have been released earlier in step 9 (I assume that is what will happen but not 100% sure)
- If it means copying the memory, then there is no need to wait till step 11. Better to release that memory as step 6.5
I am not sure if you can redirecting a pointer from C to Flex. My understanding is you have two byteArray memory chuck, one in C, the other in Flex.
Basically, I agree with your second approach. Once you get the ByteArray value from C, you can just dipose the ExtensionContext.
That's what I am doing for my application, it works fine, at least. Maybe redirecting a pointer can save some memories, but I have no idea how to achieve that.
Thanks for the help Matthew.It would be ideal if this mechanism was more extensively documented by Adobe, since seeing what the garbage collector does or does not do is hard (impossible?). But knowing that someone has learnt from experience that a certain pattern works certainly helps.
I haven't found a way to track the application memory when including ANE since obviously we cannot use profile.
Instead of calling disposing and waiting for the Flex to do the gc, I currently prefer maunally cleaning up all the memory in the Objective-C side. Specially when you calling some visual container or component from Objective-C side, if you just call dispose method, and the Flex doesn't do the gc, everything will be stuck there sometimes......
I just did an ANE to enable WebGL content from Flex and that's painful when you can dispose, the WebGL page remains sitting there.
Europe, Middle East and Africa