From: Panayotis K. <pan...@pa...> - 2010-03-23 15:28:14
|
I am wondering for a long time, how to have weak references under xmlvm. You know that already, but just for reference I say that weak references are sometimes needed, to avoid cyclic dependencies. An example with those are with delegates, which need to have a weak reference to the actual object. If they simply have a strong reference, then there will be a cycle and everything will stay onto memory. Thus I have created a patch which actually deals with the problem. First of all it gives access to the retain/release mechanism, just in case, although I am not sure that this is something that should be exposed in Java, but anyway. It also gives access to dealloc, which is a vital location to clean up weak references. And at the end it provides an utility object, which will perform the actual weak binding between the two objects, but which will also avoid cyclic dependencies. This could be mostly used for delegates, but it can also be used for any other case someone wants to break cyclic dependencies in Java. What do you think? PS: I am not sending the patch right now, only because it depends on my previous memory management approach. I could, though, send the "unofficially" the patch even in this list to have a look and gather opinions. |
From: Tor L. <tm...@ik...> - 2010-03-23 16:15:05
|
> although I am not sure that this is something that should be > exposed in Java, but anyway. Java is supposed to have weak references, isn't it? http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html So if you expose them to Java as the spec describes, it should just be a good thing and make even more Java code work with XMLVM. --tml |
From: Panayotis K. <pan...@pa...> - 2010-03-23 17:29:22
|
Java will never stop surprise me! I really didn't know that it supported weak references! Your idea is very good, I'll follow this path, then! -- Panayotis 23 Μαρ 2010, 5:47 μ.μ., ο/η Tor Lillqvist <tm...@ik...> έγραψε: >> although I am not sure that this is something that should be >> exposed in Java, but anyway. > > Java is supposed to have weak references, isn't it? > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html > So if you expose them to Java as the spec describes, it should just > be a good thing and make even more Java code work with XMLVM. > > --tml |
From: Panayotis K. <pan...@pa...> - 2010-03-23 23:12:22
|
On 23 Μαρ 2010, at 7:29 μ.μ., Panayotis Katsaloulis wrote: > Java will never stop surprise me! > I really didn't know that it supported weak references! > > Your idea is very good, I'll follow this path, then! > > -- > Panayotis > > 23 Μαρ 2010, 5:47 μ.μ., ο/η Tor Lillqvist <tm...@ik...> έγραψε: > >>> although I am not sure that this is something that should be >>> exposed in Java, but anyway. >> >> Java is supposed to have weak references, isn't it? >> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html >> So if you expose them to Java as the spec describes, it should just >> be a good thing and make even more Java code work with XMLVM. >> >> --tml It seems that this was much easier than what I originally thought. In parallel I have created a mechanism to store variables of category objects (or any other object anyway), since by definition in a category you won't be able to store other variables. This is useful to clean up a bit with retained delegates that nobody releases them (and yes, I believe this code has less memory leaks than ever!) Probably I should take down my old patch and release a new patch, with this improved memory management issues. What others (i.e. the xmlvm team) think? :D |
From: Arno P. <ar...@pu...> - 2010-03-25 13:45:23
|
>>> Java is supposed to have weak references, isn't it? >>> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html >>> So if you expose them to Java as the spec describes, it should just >>> be a good thing and make even more Java code work with XMLVM. >>> >>> --tml > > > It seems that this was much easier than what I originally thought. > In parallel I have created a mechanism to store variables of category objects (or any other object anyway), since by definition in a category you won't be able to store other variables. > This is useful to clean up a bit with retained delegates that nobody releases them (and yes, I believe this code has less memory leaks than ever!) > > Probably I should take down my old patch and release a new patch, with this improved memory management issues. > > What others (i.e. the xmlvm team) think? gimme, gimme! :-) These are two different things: support for weak references and allowing additional state information for categories. Both would be extremely useful! Arno |
From: Panayotis K. <pan...@pa...> - 2010-03-25 14:31:39
|
On 25 Μαρ 2010, at 3:44 μ.μ., Arno Puder wrote: > > gimme, gimme! :-) > > These are two different things: support for weak references and allowing > additional state information for categories. Both would be extremely useful! > > Arno Yes, they are really two different things, with "memory management" being the only common area. I believe I have successfully addressed both of them. I will check the new autorelease-less mechanism and if everything will be fine, I will re-submit a new patch with all my changes, to the HEAD xmlvm code. |
From: Gergely K. <ger...@ma...> - 2010-03-26 18:14:49
|
Hi, Actually we did something very similar with the "synchronized" implementation. We needed to store locks for each method somewhere, and created something called "XMLVMRegistry" which stores the locks for each object that uses them. You can take a look at our approach in our patch, xmlvm.m and xmlvm.h. It was not a generalized object store, but it can certainly be extended in that direction. Best Regards, Gergely 2010/3/25 Panayotis Katsaloulis <pan...@pa...> > > On 25 Μαρ 2010, at 3:44 μ.μ., Arno Puder wrote: > > > > > gimme, gimme! :-) > > > > These are two different things: support for weak references and allowing > > additional state information for categories. Both would be extremely > useful! > > > > Arno > > > -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |
From: Arno P. <ar...@pu...> - 2010-03-27 08:56:21
|
I like the idea of a general mechanism to add state to categories. This would be beneficial in different parts of XMLVM as well. I hope we can consolidate Gergely's and Panayotis' approach. @Panayotis: would you mind taking a look at Gergely's approach in the patch he submitted and report how your approach differs from his? I think we really need to move to smaller patches, otherwise these double effort situations will occur more often. Arno On 3/26/10 11:07 AM, Gergely Kis wrote: > Hi, > > Actually we did something very similar with the "synchronized" > implementation. > We needed to store locks for each method somewhere, and created > something called "XMLVMRegistry" which stores the locks for each object > that uses them. > > You can take a look at our approach in our patch, xmlvm.m and xmlvm.h. > It was not a generalized object store, but it can certainly be extended > in that direction. > > > Best Regards, > Gergely > > 2010/3/25 Panayotis Katsaloulis <pan...@pa... > <mailto:pan...@pa...>> > > > On 25 Μαρ 2010, at 3:44 μ.μ., Arno Puder wrote: > > > > > gimme, gimme! :-) > > > > These are two different things: support for weak references and > allowing > > additional state information for categories. Both would be > extremely useful! > > > > Arno > > > > > -- > Kis Gergely > MattaKis Consulting > Email: ger...@ma... <mailto:ger...@ma...> > Web: http://www.mattakis.com > Phone: +36 70 408 1723 > Fax: +36 27 998 622 > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
From: Panayotis K. <pan...@pa...> - 2010-03-27 11:00:48
|
On 27 Μαρ 2010, at 10:56 π.μ., Arno Puder wrote: > > I like the idea of a general mechanism to add state to categories. This > would be beneficial in different parts of XMLVM as well. I hope we can > consolidate Gergely's and Panayotis' approach. > > @Panayotis: would you mind taking a look at Gergely's approach in the > patch he submitted and report how your approach differs from his? > Of course! > I think we really need to move to smaller patches, otherwise these > double effort situations will occur more often. > To say the truth, I find it difficult to send small patches with the current mechanism. Perhaps I am missing something there. Usually I have my private repository with many many changes, which have accumulated due to the usage of the library. If I use the upload tool, it tries to upload everything (and thus creating a huge patch). If I diff and send the patch, the online system does not accept it. How can I send then a patch with only a subset of my changes in my local copy? What are the expected diff structure. to manually define changes with diff? |
From: Panayotis K. <pan...@pa...> - 2010-03-27 15:04:02
|
On 26 Μαρ 2010, at 8:07 μ.μ., Gergely Kis wrote: > Actually we did something very similar with the "synchronized" implementation. > We needed to store locks for each method somewhere, and created something called "XMLVMRegistry" which stores the locks for each object that uses them. I am trying to have a look at it, but I can't find it. Is it possible to tell me where it is? From what you describe though, it looks like we have implemented the same thing. Still, I think I found a better and more elegant solution: the use of associations, which are new in 10.6 and in iPhone SDK 3.1 (this shouldn't be a problem, right?) Documentation can be found here: http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html The only problem is that this framework is missing from the emulator! Since we are going to use it only in one specific location (retaining an object when is given as a delegate for example), and since emulator does not suffer from strict memory problems, I believe up to the day this bug will be fixed in the simulation (there is already a bug report for that) we can "ignore" this memory leak under simulator, since it works fine in iPhone. What do you think? |
From: Gergely K. <ger...@ma...> - 2010-03-29 06:48:54
|
Hi, 2010/3/27 Panayotis Katsaloulis <pan...@pa...> > > On 26 Μαρ 2010, at 8:07 μ.μ., Gergely Kis wrote: > > > Actually we did something very similar with the "synchronized" > implementation. > > We needed to store locks for each method somewhere, and created something > called "XMLVMRegistry" which stores the locks for each object that uses > them. > > > I am trying to have a look at it, but I can't find it. > Is it possible to tell me where it is? > From what you describe though, it looks like we have implemented the same > thing. > http://xmlvm-reviews.appspot.com/18002/patch/1/33 > > Still, I think I found a better and more elegant solution: the use of > associations, which are new in 10.6 and in iPhone SDK 3.1 > (this shouldn't be a problem, right?) > > Documentation can be found here: > > http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html I think this is a nice, elegant solution, and we should migrate to it. Personally I don't see a problem with only supporting iPhone 3.1+, with 3.2 around the corner. > > > The only problem is that this framework is missing from the emulator! > So the code does not even compile for the emulator? Maybe then we should create a very simple dummy implementation. Did you check with the 3.2 beta SDK? Maybe this will all go away when we upgrade to it. > Since we are going to use it only in one specific location (retaining an > object when is given as a delegate for example), and since emulator does > not suffer from strict memory problems, I believe up to the day this bug > will be fixed in the simulation (there is already a bug report for that) we > can "ignore" this memory leak under simulator, since it works fine in > iPhone. > > What do you think? > I think we should not reinvent wheels, which are already in the platform. Maybe we could introduce a few generic macros to make the code more readable. The use of macros also enables those who have to support older SDKs to replace it with their own implementations. Best Regards, Gergely -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |
From: Arno P. <ar...@pu...> - 2010-03-29 09:33:19
|
On 3/28/10 11:48 PM, Gergely Kis wrote: > Still, I think I found a better and more elegant solution: the use > of associations, which are new in 10.6 and in iPhone SDK 3.1 > (this shouldn't be a problem, right?) > > Documentation can be found here: > http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html > > > I think this is a nice, elegant solution, and we should migrate to it. > Personally I don't see a problem with only supporting iPhone 3.1+, with > 3.2 around the corner. I agree with Gergely: this is a nice and elegant solution. I think it is OK to have a dependence to the iPhone SDK 3.2. Let's just hope it will work properly in the final release of 3.2. Arno |
From: Panayotis K. <pan...@pa...> - 2010-03-30 05:26:02
|
The patch I have sent already intergrates this technology :) On Monday, March 29, 2010, Arno Puder <ar...@pu...> wrote: > > > On 3/28/10 11:48 PM, Gergely Kis wrote: >> Still, I think I found a better and more elegant solution: the use >> of associations, which are new in 10.6 and in iPhone SDK 3.1 >> (this shouldn't be a problem, right?) >> >> Documentation can be found here: >> http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html >> >> >> I think this is a nice, elegant solution, and we should migrate to it. >> Personally I don't see a problem with only supporting iPhone 3.1+, with >> 3.2 around the corner. > > I agree with Gergely: this is a nice and elegant solution. I think it is > OK to have a dependence to the iPhone SDK 3.2. Let's just hope it will > work properly in the final release of 3.2. > > Arno > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > -- Panayotis Katsaloulis |