[OpenSmalltalk/opensmalltalk-v
Locked
[OpenSmalltalk/opensmalltalk-v
 
|
original issue exposed in what is happening is the call out is creating autorelease objects, but when do they get released. Other call out should be audited for the same issue. Some routines might not need a wrapper? — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
We also have a "global" autorelease in the main app, that should catch most thing, but we might no get there "in time"… — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
Instead of the PR #373, maybe we should solve this issue. Below is the trace to the leak in #373, — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
Most of the callbacks to platform code are documented here .... Sent from ProtonMail Mobile
|
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
I took the list of VM APIs at https://isqueak.org/PlatformVMAPI and created a regex that searches for definitions of them: Here are the locations that define these methods in A few questions remain for me:
platforms/iOS/vm/Common/Classes/sqSqueakAttributesAPI.m#L49 attributeSize — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
The issue is calling out to swift or OBJ-C code could make autoreleased object which exist both in ARC and non-arc. At camp smalltalk I'll go thru the list and see which require wrapping. Some do not. — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
But it is important to note that any wrapping can be done in the iOS code and should not be e.g. pushed further out to the VM code. Why isn't it possible to wrap ye entire VM execution in an appropriate autorelease context in the iOS startup code before invoking the VM itself? iOS is "in charge" of the launch process. If the code needs to be refactored to invoke the VM through a function that can apply wrapping before we invoke VM code I am all for that. — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
This already happens:
But I think this is not enough. If I understand ARC correctly, leaving the autoreleasepool-ed region triggeres the cleanup etc. Hence, this would would only trigger after the respecive code leaves. Which is, not during normal operation… (@johnmci please correct me if I'm wrong) — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
An example is. ioSetCursorARGB in interp.c calls the C interface ioSetCursorARGB in sqSqueakCursorAPI.m However this is fine grained as the sqSqueakOSXApplication+cursor.m code could change and introduce a autorelease object before the guard clauses, etc. This is what happened in So a safer choice would be to wrap ioSetCursorARGB in sqSqueakCursorAPI.m to ensure mistakes don't happen as the actual implementation code is changed. In general I originally wrote the code to call from interp.c to an exposed C routine, to the obj-c logic, so I am hoping this change will be 'simple'. There is more of an issue for plugins, as they are of course C routines, but could call Obj-C. For those it might just fall back to the authors to ensure they don't leak. — |
Re: [OpenSmalltalk/opensmalltalk-v
|
|
In reply to this post by David T Lewis
In these cases the called routine only terminates when Squeak terminates. It's a programming style pattern, but doesn't of course cleanup memory as the interpreter is running. In some variations of the VM (like for a browser plugin) we wrote the code so that after N byte codes interpreted, we would save the state, and exit the interpreter loop, and return back to the caller. Later the caller would call back into the interp.c and resume. At that point we could unwind the autorelease pool. However I don't recommend that as a solution due to overhead. We have tools to check for memory leaking, just need to run them from time to time to ensure a os-x or iOS platform change hasn't introduced a leak by forgetting a auto-release pool. — |
| Free forum by Nabble | Edit this page |