xmlvm-users

[xmlvm-users] No dependence on NSAutoreleasePool

[Arno P. <ar...@pu...>]

Guys,

I have just committed a patch submitted by Joshua Melcon. His patch 
removes the dependency on NSAutoreleasePool during code generation. 
NSAutoreleasePool is a convenience class for Objective-C programmers to 
defer releases on object references to a later time. So far we have made 
heavy use of NSAutoreleasePool (every method had its own 
NSAutoreleasePool). Unfortunately, NSAutoreleasePool is very runtime 
inefficient. Joshua's patch removes this dependency by computing where 
release and retains need to be inserted. This should dramatically 
improve runtime performance of the code generated by XMLVM.

Please update your copies of XMLVM and try your applications. If there 
are problems, please report back on the mailing list. Joshua will 
continue with some further optimizations (currently there are some 
redundant retain/release in the generated code).

Note: this change has *no* impact on the ownership rules when passing 
object references as input arguments or when returning an object 
reference as a result. Newly created instances should not be added to a 
NSAutoreleasePool.

Arno

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Panayotis K. <pan...@pa...>]

On 25 Μαρ 2010, at 1:36 μ.μ., Arno Puder wrote:

> 
> Guys,
> 
> I have just committed a patch submitted by Joshua Melcon. His patch 
> removes the dependency on NSAutoreleasePool during code generation. 

I have a question here:
What if a selector is called from a separated thread?
AFAIK, when a new thread is fired, there is no autorelease pool for that.

In the new code, I can see inside java_lang_Thread.m that in selector threadCallback, there is a new autorelease pool.
I haven't deeply had a look at the code, but I am wondering if this will cover this problem.

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Panayotis K. <pan...@pa...>]

On xml...@li...25 Μαρ 2010, at 6:27 μ.μ., Joshua Melcon wrote:

> Last time I was digging through the OBJ-C documentation about AutoReleasePools I recall seeing something that indicated that the runtime generally creates one before it invokes a thread.  That said, I do have the following code in java_lang_Thread.m for a reason:
> 
> - (void) threadCallback: (id) arg
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> 	[runnable run__];
> 	[self release];
> 	[pool release];
> }
> Because apparently, at least in certain cases, you are responsible for creating the pool...
> 
> The above pattern, plus the assumption that the runtime creates pools as necessary should prevent any problems.
> 
> Let me know if you have any issues… 


Not really, have a look here:

http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html

If you are making Cocoa calls outside of the Application Kit’s main thread—for example if you create a Foundation-only application or if you detach a thread—you need to create your own autorelease pool.


That's why I am asking that.
But in any case, I have seen this code and it seems that it should work. I did some preliminary tests and I didn't experience any problems.
I just want to make sure that you are aware of this situation.

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Panayotis K. <pan...@pa...>]

I have another question:

At the produced code, I can see something like:

    [_r0.o release]; _r0.o = [NSNull null];
    [_r1.o release]; _r1.o = [NSNull null];
    [_r2.o release]; _r2.o = [NSNull null];
…

for all variables.
Is this necessary?
Of course it is not something that will harm, but maybe even these few cpu cycles might be important :)

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

Yes it is necssacry, though in some cases it may be possible to avoid it.

Basically, if you don't null them out after release, other code paths *may*
try to release them again (which would be bad).  In some cases, the nulling
out isn't necessary -- this is one of the optimizations I intend to add in
the future.

Additionally,  consider that setting a register to [NsNull null] is in
general going to be a great deal more efficient than adding an object to an
auto release pool.  So even with unnecessary nulling, we are still faster
than autorelease.  We will be even faster in the future when I trim out some
of this extra stuff..

-- Joshua Melcon


2010/3/25 Panayotis Katsaloulis <pan...@pa...>

> I have another question:
>
> At the produced code, I can see something like:
>
>    [_r0.o release]; _r0.o = [NSNull null];
>    [_r1.o release]; _r1.o = [NSNull null];
>    [_r2.o release]; _r2.o = [NSNull null];
> …
>
> for all variables.
> Is this necessary?
> Of course it is not something that will harm, but maybe even these few cpu
> cycles might be important :)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Panayotis K. <pan...@pa...>]

On 25 Μαρ 2010, at 7:18 μ.μ., Joshua Melcon wrote:

> Yes it is necssacry, though in some cases it may be possible to avoid it. 
> 
> Basically, if you don't null them out after release, other code paths *may* try to release them again (which would be bad).  In some cases, the nulling out isn't necessary -- this is one of the optimizations I intend to add in the future.  
> 
> Additionally,  consider that setting a register to [NsNull null] is in general going to be a great deal more efficient than adding an object to an auto release pool.  So even with unnecessary nulling, we are still faster than autorelease.  We will be even faster in the future when I trim out some of this extra stuff..

Of course!
 I really respect this effort.

Still, I think I found a bug :(
------------------------------------

Here is a small example, I was able to make.

Consider adding this code to applicationDidFinishLaunching (in java)
        UIView view = new UIView();
        float z = view.getFrame().size.width;


This produces (among others) the following code
    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__];
    _rtmp.o =  _r2.o;
    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_CGSize;
    [_rtmp.o release]; _rtmp.o = [NSNull null];
    [_r2.o retain];

This retain message breaks the code.
Actually I believe it is something with the _rtmp.o variable, which was released and just later on retained (since _rtmp.o =  _r2.o )

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Panayotis K. <pan...@pa...>]

On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:

>    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes back ref count += 1 because its a get function
>    _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we need to free our +1 afterwords
>    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_ 
> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>    [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from the first line
>    [_r2.o retain]; // retaining the value from _r2, presumably because we will be returning soon (can't tell without the rest of the code).
> 
> But, based on this code sequence, everything looks correct?  How does _r2.o retain break things? 


It says that it tries to retain am already fee'd object.

Try it for yourself and see ;)

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

> Last time I was digging through the OBJ-C documentation about
> AutoReleasePools I recall seeing something that indicated that the runtime
> generally creates one before it invokes a thread.  That said, I do have the
> following code in java_lang_Thread.m for a reason:
>
> - (void) threadCallback: (id) arg
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> [runnable run__];
>  [self release];
> [pool release];
> }
> Because apparently, at least in certain cases, you are responsible for
> creating the pool...
>
> The above pattern, plus the assumption that the runtime creates pools
> as necessary should prevent any problems.
>
> Let me know if you have any issues...
>
>
> -- Joshua Melcon
>
>
> 2010/3/25 Panayotis Katsaloulis <pan...@pa...>
>
>
>> On 25 Μαρ 2010, at 1:36 μ.μ., Arno Puder wrote:
>>
>> >
>> > Guys,
>> >
>> > I have just committed a patch submitted by Joshua Melcon. His patch
>> > removes the dependency on NSAutoreleasePool during code generation.
>>
>> I have a question here:
>> What if a selector is called from a separated thread?
>> AFAIK, when a new thread is fired, there is no autorelease pool for that.
>>
>> In the new code, I can see inside java_lang_Thread.m that in selector
>> threadCallback, there is a new autorelease pool.
>> I haven't deeply had a look at the code, but I am wondering if this will
>> cover this problem.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>>
>
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

If the last retain is failing it indicates that there is an issue related to
the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.

I have run Xokoban, Afireworks, and another CCed program and not encountered
any problems.  It is possible that you have found a case which we do not
handle correctly that doesn't show up in those programs.  Later tonight I
can attempt to reproduce this error using one of our demo apps --

Could you confirm that the Xokoban and Afireworks demo apps are working for
you?

Thanks,


-- Joshua Melcon


2010/3/25 Panayotis Katsaloulis <pan...@pa...>

>
> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>
> >    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes
> back ref count += 1 because its a get function
> >    _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
> need to free our +1 afterwords
> >    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
> > CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
> >    [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from the
> first line
> >    [_r2.o retain]; // retaining the value from _r2, presumably because we
> will be returning soon (can't tell without the rest of the code).
> >
> > But, based on this code sequence, everything looks correct?  How does
> _r2.o retain break things?
>
>
> It says that it tries to retain am already fee'd object.
>
> Try it for yourself and see ;)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

Ok, I understand now.  Yes that is a bug -- and an interesting one.
Basically, its doing:


R1 = object;  // R1 has one retain
Temp = R1; /
R1 = object.subobject
Release Temp (causing an implicit release of the object now in R1)
retain R1 (so we don't lose it).

Basically, the fix is to just emit the retain instruction before the
rtmp release.  In the future, we will notice that the back to back
retain/release is not necessacry.

http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to
the trunk after the review completes.

Panayotis: Thanks for finding the bug! I appreciate the feedback, as
well as your clear description of the issue and how to reproduce it.
Please let me know if you find anything else.

all :)
-- Joshua Melcon



On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
<pan...@pa...> wrote:
> Yes these applications work.
>
> If you just try to convert the java source code I gave to you though, you
> will see the error :)
> Just try ;)
> To be fair, I've also checked a lot of code, from my own appplications and
> test cases and this was the only problem found :)
>
> Still, it is a bug ;)
>
>
>
> --
> Panayotis
> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon <xm...@me...> έγραψε:
>
> If the last retain is failing it indicates that there is an issue related to
> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>
> I have run Xokoban, Afireworks, and another CCed program and not encountered
> any problems.  It is possible that you have found a case which we do not
> handle correctly that doesn't show up in those programs.  Later tonight I
> can attempt to reproduce this error using one of our demo apps --
>
> Could you confirm that the Xokoban and Afireworks demo apps are working for
> you?
>
> Thanks,
>
>
> -- Joshua Melcon
>
>
> 2010/3/25 Panayotis Katsaloulis <pan...@pa...>
>>
>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>>
>> >    _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes
>> > back ref count += 1 because its a get function
>> >    _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
>> > need to free our +1 afterwords
>> >    _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
>> > CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>> >    [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from
>> > the first line
>> >    [_r2.o retain]; // retaining the value from _r2, presumably because
>> > we will be returning soon (can't tell without the rest of the code).
>> >
>> > But, based on this code sequence, everything looks correct?  How does
>> > _r2.o retain break things?
>>
>>
>> It says that it tries to retain am already fee'd object.
>>
>> Try it for yourself and see ;)
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Gergely K. <ger...@ma...>]

Hi,

Since the generated code AFAIK does not call any Cocoa methods directly, my
suggestion is that in the compat-lib we should create autorelease pools in
the wrapper methods to make sure that if such Cocoa methods are called, the
objects get into an autorelease pool in the same method. Then of course one
needs to do a [x retain] on return, as usual.  This way the compat-lib will
conform to both the Cocoa Memory Management guidelines and the XMLVM calling
convention.

I planned to do this even when the generated code still used autorelease
pools.
The reason:
If you call a wrapper method in a tight loop, which implicitly puts objects
on the nearest autorelease pool in the call stack, you could end up with
many objects in the pool that should have been freed already, before your
application's Java method has the chance to free them.

Of course I think it is advisable to use the [[alloc] init*]  sequence
everywhere, if you can, because of the performance benefits. However, I
already ran into places where the Cocoa API only provides you autoreleased
objects, and you have no way to request otherwise.

I think the strategy should be to minimize the deviations from the JVM based
Java platforms, and making the programmers call System.gc() is in my opinion
a step in the wrong direction.

Best Regards,
Gergely

2010/3/28 Arno Puder <ar...@pu...>

>
> it is actually interesting to note that Cocoa places quite a few objects
> in the autorelease pool. If you comment out the creation of the one
> autorelease pool in XMLVM's main() method, you will get a lot of
> warnings of leaking objects. Since XMLVM no longer places objects in the
> autorelease pool, these must come from Cocoa. As a matter of fact, all
> so-called convenience methods where the object is not created via the
> usual alloc/init (e.g., [NSString string*]), are placed by convention in
> an autorelease pool. So the question is how to deal with that in XMLVM.
> One suggestion would be to implement System.gc() so that it calls [pool
> drain]. It would be the programmers responsibility to call System.gc()
> from time to time.
>
> In case of the enumerator, since we know it is placed in the autorelease
> pool, one could do a [pool drain] in the wrapper.
>
> Any other ideas?
>
> Arno
>
>
> On 3/28/10 1:21 AM, Joshua Melcon wrote:
> > Thanks for the project -- it was very easy to get running.  After some
> > investigation, it looks like the call to NSMutableArray
> > objectEnumerator causes an object to be allocated in the auto release
> > pool.  I verified it by experiment, but it also looks to be how the
> > NSCollection classes work:
> >
> >
> http://svn.opengroupware.org/SOPE/trunk/libFoundation/Foundation/NSDictionary.m
> >
> > - (NSEnumerator*)objectEnumerator
> > {
> >      return AUTORELEASE([[_NSDictionaryObjectEnumerator alloc]
> >                             initWithDictionary:self]);
> > }
> >
> > The reference code is doing its job perfectly.  The NsMutableArray is
> > also OK. Eventually, if the thread terminated it would cause all the
> > itereators that were added to the autorelease pool to be freed.
> > Basically the call stack is:
> >
> > run thread // creates an auto release pool, releases after its callees
> > come back.
> > ...
> > loop forever creating iterators in the auto release pool, effectively
> > never freeing the memory the iterators used.
> >
> > I am too tired to think of a clever solution at the moment, but I will
> > look at it tomorrow.  If you want a workaround, just use a for loop
> > rather than an iterator in that thread :/
> >
> > It seems somewhat weird that the enumerators work this way in obj c,
> > because it creates this probably in normal objective c... Course its
> > nice to not have to worry about freeing enumerators....
> >
> > -- Joshua Melcon
> >
> >
> >
> > 2010/3/27 Paul Poley<bay...@gm...>:
> >> Sure thing.  I've attached an Eclipse project.  It starts the UI&  then
> runs
> >> a background thread, which infinitely loops.  Inside the loop, a method
> is
> >> called so that anything allocated can be released, which wouldn't
> otherwise
> >> happen until the loop ended (that fact is unrelated to our discussion).
> >> Inside the method, an ArrayList is allocated&  iterated.  Nothing is
> >> actually added to it.
> >> When compiling against revision 977, memory usage remains consistent.
>  When
> >> compiling against revision 981, memory usage is quickly increased.  I
> use
> >> the OSX "Activity Monitor" to check memory usage.
> >> Thanks Josh!
> >> Paul Poley
> >>
> >>
> >> 2010/3/27 Joshua Melcon<xm...@me...>
> >>>
> >>> Hi Paul,
> >>>
> >>> I attempted to produce a leak with the array list iterator today using
> >>> a few variations of code similar to:
> >>>
> >>> ArrayList<InternalClass>  a = new ArrayList<InternalClass>();
> >>>                 for(int x=0;x<10000;x++)
> >>>                 {
> >>>                 a.add(new InternalClass());
> >>>                 }
> >>>                 for(InternalClass x:a)
> >>>                 {
> >>>                         x.toString();
> >>>                 }
> >>>
> >>> I am unable to see any leaking objects.
> >>>
> >>> Additionally, I inspected the array list iterator code -- it seems
> >>> work when I step through it.
> >>>
> >>> In order to debug this issue I think that I need some help from you.
> >>> If you could create a self contained example that causes a memory leak
> >>> I would be more than happy to figure out what is going on.
> >>>
> >>> Thanks,
> >>>
> >>> -- Joshua Melcon
> >>>
> >>>
> >>>
> >>> 2010/3/27 Paul Poley<bay...@gm...>:
> >>>> Hi All,
> >>>> I was just making some suggested modifications to a couple of my
> >>>> patches.
> >>>>   After I was done, I was testing to make sure I didn't introduce any
> >>>> memory
> >>>> leaks.
> >>>> Unfortunately, the code seemed to have a lot of leaks.  Upon digging
> in,
> >>>> the
> >>>> first leak I found was in ArrayList's iterator(), which didn't leak
> >>>> before&
> >>>> nothing had changed (side note: that existed before my patches).  When
> I
> >>>> first tested&  submitted my patches, they were using the auto-release
> >>>> pool.
> >>>>   So I reverted to revision 977 before the auto-release pool was
> removed
> >>>> &
> >>>> all the leaks went away.
> >>>> Has anyone else observed a similar effect?  For now I will need to
> >>>> continue
> >>>> using the old version.
> >>>> Perhaps we can set up a branch separate from trunk that removes the
> >>>> auto-release pool until it's been fully baked?
> >>>> Thanks a bunch!  I appreciate the effort!
> >>>> Paul Poley
> >>>>
> >>>> 2010/3/26 Arno Puder<ar...@pu...>
> >>>>>
> >>>>> I just committed Joshua's fix.
> >>>>>
> >>>>> Arno
> >>>>>
> >>>>>
> >>>>> On 3/25/10 10:49 PM, Joshua Melcon wrote:
> >>>>>> Ok, I understand now.  Yes that is a bug -- and an interesting one.
> >>>>>> Basically, its doing:
> >>>>>>
> >>>>>>
> >>>>>> R1 = object;  // R1 has one retain
> >>>>>> Temp = R1; /
> >>>>>> R1 = object.subobject
> >>>>>> Release Temp (causing an implicit release of the object now in R1)
> >>>>>> retain R1 (so we don't lose it).
> >>>>>>
> >>>>>> Basically, the fix is to just emit the retain instruction before the
> >>>>>> rtmp release.  In the future, we will notice that the back to back
> >>>>>> retain/release is not necessacry.
> >>>>>>
> >>>>>> http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it
> >>>>>> to
> >>>>>> the trunk after the review completes.
> >>>>>>
> >>>>>> Panayotis: Thanks for finding the bug! I appreciate the feedback, as
> >>>>>> well as your clear description of the issue and how to reproduce it.
> >>>>>> Please let me know if you find anything else.
> >>>>>>
> >>>>>> all :)
> >>>>>> -- Joshua Melcon
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
> >>>>>> <pan...@pa...>    wrote:
> >>>>>>> Yes these applications work.
> >>>>>>>
> >>>>>>> If you just try to convert the java source code I gave to you
> >>>>>>> though,
> >>>>>>> you
> >>>>>>> will see the error :)
> >>>>>>> Just try ;)
> >>>>>>> To be fair, I've also checked a lot of code, from my own
> >>>>>>> appplications
> >>>>>>> and
> >>>>>>> test cases and this was the only problem found :)
> >>>>>>>
> >>>>>>> Still, it is a bug ;)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Panayotis
> >>>>>>> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>
>  έγραψε:
> >>>>>>>
> >>>>>>> If the last retain is failing it indicates that there is an issue
> >>>>>>> related to
> >>>>>>> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
> >>>>>>>
> >>>>>>> I have run Xokoban, Afireworks, and another CCed program and not
> >>>>>>> encountered
> >>>>>>> any problems.  It is possible that you have found a case which we
> do
> >>>>>>> not
> >>>>>>> handle correctly that doesn't show up in those programs.  Later
> >>>>>>> tonight
> >>>>>>> I
> >>>>>>> can attempt to reproduce this error using one of our demo apps --
> >>>>>>>
> >>>>>>> Could you confirm that the Xokoban and Afireworks demo apps are
> >>>>>>> working
> >>>>>>> for
> >>>>>>> you?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>>
> >>>>>>> -- Joshua Melcon
> >>>>>>>
> >>>>>>>
> >>>>>>> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
> >>>>>>>>
> >>>>>>>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
> >>>>>>>>
> >>>>>>>>>      _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; //
> R2
> >>>>>>>>> comes
> >>>>>>>>> back ref count += 1 because its a get function
> >>>>>>>>>      _rtmp.o =  _r2.o; // We are overwriting R2 on the next line,
> >>>>>>>>> so
> >>>>>>>>> we
> >>>>>>>>> need to free our +1 afterwords
> >>>>>>>>>      _r2.o = ((org_xmlvm_iphone_CGRect*)
> >>>>>>>>> _r2.o)->size_org_xmlvm_iphone_
> >>>>>>>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
> >>>>>>>>>      [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the
> +=
> >>>>>>>>> from
> >>>>>>>>> the first line
> >>>>>>>>>      [_r2.o retain]; // retaining the value from _r2, presumably
> >>>>>>>>> because
> >>>>>>>>> we will be returning soon (can't tell without the rest of the
> >>>>>>>>> code).
> >>>>>>>>>
> >>>>>>>>> But, based on this code sequence, everything looks correct?  How
> >>>>>>>>> does
> >>>>>>>>> _r2.o retain break things?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> It says that it tries to retain am already fee'd object.
> >>>>>>>>
> >>>>>>>> Try it for yourself and see ;)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>> Download Intel&#174; 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
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ------------------------------------------------------------------------------
> >>>>>> Download Intel&#174; 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> ------------------------------------------------------------------------------
> >>>>> Download Intel&#174; 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
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------------
> >>>> Download Intel&#174; 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
> >>>>
> >>>>
> >>
> >>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>



-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Arno P. <ar...@pu...>]

I just committed Joshua's fix.

Arno


On 3/25/10 10:49 PM, Joshua Melcon wrote:
> Ok, I understand now.  Yes that is a bug -- and an interesting one.
> Basically, its doing:
>
>
> R1 = object;  // R1 has one retain
> Temp = R1; /
> R1 = object.subobject
> Release Temp (causing an implicit release of the object now in R1)
> retain R1 (so we don't lose it).
>
> Basically, the fix is to just emit the retain instruction before the
> rtmp release.  In the future, we will notice that the back to back
> retain/release is not necessacry.
>
> http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to
> the trunk after the review completes.
>
> Panayotis: Thanks for finding the bug! I appreciate the feedback, as
> well as your clear description of the issue and how to reproduce it.
> Please let me know if you find anything else.
>
> all :)
> -- Joshua Melcon
>
>
>
> On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
> <pan...@pa...>  wrote:
>> Yes these applications work.
>>
>> If you just try to convert the java source code I gave to you though, you
>> will see the error :)
>> Just try ;)
>> To be fair, I've also checked a lot of code, from my own appplications and
>> test cases and this was the only problem found :)
>>
>> Still, it is a bug ;)
>>
>>
>>
>> --
>> Panayotis
>> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>  έγραψε:
>>
>> If the last retain is failing it indicates that there is an issue related to
>> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>>
>> I have run Xokoban, Afireworks, and another CCed program and not encountered
>> any problems.  It is possible that you have found a case which we do not
>> handle correctly that doesn't show up in those programs.  Later tonight I
>> can attempt to reproduce this error using one of our demo apps --
>>
>> Could you confirm that the Xokoban and Afireworks demo apps are working for
>> you?
>>
>> Thanks,
>>
>>
>> -- Joshua Melcon
>>
>>
>> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
>>>
>>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>>>
>>>>     _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 comes
>>>> back ref count += 1 because its a get function
>>>>     _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
>>>> need to free our +1 afterwords
>>>>     _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
>>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>>>>     [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from
>>>> the first line
>>>>     [_r2.o retain]; // retaining the value from _r2, presumably because
>>>> we will be returning soon (can't tell without the rest of the code).
>>>>
>>>> But, based on this code sequence, everything looks correct?  How does
>>>> _r2.o retain break things?
>>>
>>>
>>> It says that it tries to retain am already fee'd object.
>>>
>>> Try it for yourself and see ;)
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; 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
>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Gergely K. <ger...@ma...>]

Hi,

If NSAutoReleasePool is threadsafe, we could add a background thread /
timer, which drains the autoreleasepool periodically. Different applications
may require different draining strategies, so this should be manageable from
the Java side using e.g. an XMLVM specific API, like:
XMLVMSettings.setGCProvider().

In any case, we can do best of both worlds: only declare the autorelease
pools in the wrapper, where necessary, and drain the central one using the
background thread approach.

What do you think?

Best Regards,
Gergely

2010/3/29 Arno Puder <ar...@pu...>

>
> I do agree that it is generally preferable to retain the semantics of
> the JVM. Having to call explicitly System.gc() periodically would be a
> deviation of this. However, merely instantiating NSAutoreleasePool
> causes *huge* performance hit (NSAutoreleasePool is a pretty complicated
> data structure when you think about it). Instead of instantiating a new
> NSAutoreleasePool in the wrappers as Gergely suggested, I propose to
> simply drain the one NSAutoreleasePool we need to create anyways.
>
> Arno
>
>
> On 3/28/10 11:34 PM, Gergely Kis wrote:
> > Hi,
> >
> > Since the generated code AFAIK does not call any Cocoa methods directly,
> > my suggestion is that in the compat-lib we should create autorelease
> > pools in the wrapper methods to make sure that if such Cocoa methods are
> > called, the objects get into an autorelease pool in the same method.
> > Then of course one needs to do a [x retain] on return, as usual.  This
> > way the compat-lib will conform to both the Cocoa Memory Management
> > guidelines and the XMLVM calling convention.
> >
> > I planned to do this even when the generated code still used autorelease
> > pools.
> > The reason:
> > If you call a wrapper method in a tight loop, which implicitly puts
> > objects on the nearest autorelease pool in the call stack, you could end
> > up with many objects in the pool that should have been freed already,
> > before your application's Java method has the chance to free them.
> >
> > Of course I think it is advisable to use the [[alloc] init*]  sequence
> > everywhere, if you can, because of the performance benefits. However, I
> > already ran into places where the Cocoa API only provides you
> > autoreleased objects, and you have no way to request otherwise.
> >
> > I think the strategy should be to minimize the deviations from the JVM
> > based Java platforms, and making the programmers call System.gc() is in
> > my opinion a step in the wrong direction.
> >
> > 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

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Paul P. <bay...@gm...>]

I have two concerns:
1) Having to worry about garbage collection at all
2) If garbage collection is based solely on time, it'd be quite difficult to
determine when to run it.  If I have an application that has usage ups &
down, I have to tune the garbage collector to run quickly enough for the
"ups".  So even during down time, I'm going to be running the garbage
collector too frequently.  Either way, the performance will still be
lackluster.  It'd be hard to write a garbage collector as smart as Java's.

What if we had a cross-compile-time option which defaults to using
NSAutoReleasePool?  If the option is overridden, it would use the solution
we're working on now.  If that's possible, it makes it easy to polish the
new solution, and gives options.

Another less ideal solution would be to discontinue using native standard
libraries such as NSMutableArray.  That would give us control to never use
"autorelease", but doesn't seem like the best idea & this would of course
cause extra work.

I would love to see XMLVM reach a maturity where we it can take any back-end
Java code (and much of front-end UI code), convert it flawlessly without
modifying the original source & not look back (especially for Android apps).

What does everyone think about the cross-compile-time option for memory
management type?

Thanks,
Paul Poley


On Mon, Mar 29, 2010 at 6:06 AM, Gergely Kis <ger...@ma...>wrote:

> Hi,
>
> If NSAutoReleasePool is threadsafe, we could add a background thread /
> timer, which drains the autoreleasepool periodically. Different applications
> may require different draining strategies, so this should be manageable from
> the Java side using e.g. an XMLVM specific API, like:
> XMLVMSettings.setGCProvider().
>
> In any case, we can do best of both worlds: only declare the autorelease
> pools in the wrapper, where necessary, and drain the central one using the
> background thread approach.
>
> What do you think?
>
> Best Regards,
> Gergely
>
> 2010/3/29 Arno Puder <ar...@pu...>
>
>
>> I do agree that it is generally preferable to retain the semantics of
>> the JVM. Having to call explicitly System.gc() periodically would be a
>> deviation of this. However, merely instantiating NSAutoreleasePool
>> causes *huge* performance hit (NSAutoreleasePool is a pretty complicated
>> data structure when you think about it). Instead of instantiating a new
>> NSAutoreleasePool in the wrappers as Gergely suggested, I propose to
>> simply drain the one NSAutoreleasePool we need to create anyways.
>>
>> Arno
>>
>>
>> On 3/28/10 11:34 PM, Gergely Kis wrote:
>> > Hi,
>> >
>> > Since the generated code AFAIK does not call any Cocoa methods directly,
>> > my suggestion is that in the compat-lib we should create autorelease
>> > pools in the wrapper methods to make sure that if such Cocoa methods are
>> > called, the objects get into an autorelease pool in the same method.
>> > Then of course one needs to do a [x retain] on return, as usual.  This
>> > way the compat-lib will conform to both the Cocoa Memory Management
>> > guidelines and the XMLVM calling convention.
>> >
>> > I planned to do this even when the generated code still used autorelease
>> > pools.
>> > The reason:
>> > If you call a wrapper method in a tight loop, which implicitly puts
>> > objects on the nearest autorelease pool in the call stack, you could end
>> > up with many objects in the pool that should have been freed already,
>> > before your application's Java method has the chance to free them.
>> >
>> > Of course I think it is advisable to use the [[alloc] init*]  sequence
>> > everywhere, if you can, because of the performance benefits. However, I
>> > already ran into places where the Cocoa API only provides you
>> > autoreleased objects, and you have no way to request otherwise.
>> >
>> > I think the strategy should be to minimize the deviations from the JVM
>> > based Java platforms, and making the programmers call System.gc() is in
>> > my opinion a step in the wrong direction.
>> >
>> > 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
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Paul P. <bay...@gm...>]

Hi All,
I was just making some suggested modifications to a couple of my patches.
 After I was done, I was testing to make sure I didn't introduce any memory
leaks.

Unfortunately, the code seemed to have a lot of leaks.  Upon digging in, the
first leak I found was in ArrayList's iterator(), which didn't leak before &
nothing had changed (side note: that existed before my patches).  When I
first tested & submitted my patches, they were using the auto-release pool.
 So I reverted to revision 977 before the auto-release pool was removed &
all the leaks went away.

Has anyone else observed a similar effect?  For now I will need to continue
using the old version.
Perhaps we can set up a branch separate from trunk that removes the
auto-release pool until it's been fully baked?

Thanks a bunch!  I appreciate the effort!
Paul Poley


2010/3/26 Arno Puder <ar...@pu...>

>
> I just committed Joshua's fix.
>
> Arno
>
>
> On 3/25/10 10:49 PM, Joshua Melcon wrote:
> > Ok, I understand now.  Yes that is a bug -- and an interesting one.
> > Basically, its doing:
> >
> >
> > R1 = object;  // R1 has one retain
> > Temp = R1; /
> > R1 = object.subobject
> > Release Temp (causing an implicit release of the object now in R1)
> > retain R1 (so we don't lose it).
> >
> > Basically, the fix is to just emit the retain instruction before the
> > rtmp release.  In the future, we will notice that the back to back
> > retain/release is not necessacry.
> >
> > http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to
> > the trunk after the review completes.
> >
> > Panayotis: Thanks for finding the bug! I appreciate the feedback, as
> > well as your clear description of the issue and how to reproduce it.
> > Please let me know if you find anything else.
> >
> > all :)
> > -- Joshua Melcon
> >
> >
> >
> > On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
> > <pan...@pa...>  wrote:
> >> Yes these applications work.
> >>
> >> If you just try to convert the java source code I gave to you though,
> you
> >> will see the error :)
> >> Just try ;)
> >> To be fair, I've also checked a lot of code, from my own appplications
> and
> >> test cases and this was the only problem found :)
> >>
> >> Still, it is a bug ;)
> >>
> >>
> >>
> >> --
> >> Panayotis
> >> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>  έγραψε:
> >>
> >> If the last retain is failing it indicates that there is an issue
> related to
> >> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
> >>
> >> I have run Xokoban, Afireworks, and another CCed program and not
> encountered
> >> any problems.  It is possible that you have found a case which we do not
> >> handle correctly that doesn't show up in those programs.  Later tonight
> I
> >> can attempt to reproduce this error using one of our demo apps --
> >>
> >> Could you confirm that the Xokoban and Afireworks demo apps are working
> for
> >> you?
> >>
> >> Thanks,
> >>
> >>
> >> -- Joshua Melcon
> >>
> >>
> >> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
> >>>
> >>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
> >>>
> >>>>     _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2
> comes
> >>>> back ref count += 1 because its a get function
> >>>>     _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so we
> >>>> need to free our +1 afterwords
> >>>>     _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_
> >>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
> >>>>     [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from
> >>>> the first line
> >>>>     [_r2.o retain]; // retaining the value from _r2, presumably
> because
> >>>> we will be returning soon (can't tell without the rest of the code).
> >>>>
> >>>> But, based on this code sequence, everything looks correct?  How does
> >>>> _r2.o retain break things?
> >>>
> >>>
> >>> It says that it tries to retain am already fee'd object.
> >>>
> >>> Try it for yourself and see ;)
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Download Intel&#174; 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
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel&#174; 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
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

Hi Paul,

I attempted to produce a leak with the array list iterator today using
a few variations of code similar to:

ArrayList<InternalClass> a = new ArrayList<InternalClass>();
                for(int x=0;x<10000;x++)
                {
                a.add(new InternalClass());
                }
                for(InternalClass x:a)
                {
                	x.toString();
                }

I am unable to see any leaking objects.

Additionally, I inspected the array list iterator code -- it seems
work when I step through it.

In order to debug this issue I think that I need some help from you.
If you could create a self contained example that causes a memory leak
I would be more than happy to figure out what is going on.

Thanks,

-- Joshua Melcon



2010/3/27 Paul Poley <bay...@gm...>:
> Hi All,
> I was just making some suggested modifications to a couple of my patches.
>  After I was done, I was testing to make sure I didn't introduce any memory
> leaks.
> Unfortunately, the code seemed to have a lot of leaks.  Upon digging in, the
> first leak I found was in ArrayList's iterator(), which didn't leak before &
> nothing had changed (side note: that existed before my patches).  When I
> first tested & submitted my patches, they were using the auto-release pool.
>  So I reverted to revision 977 before the auto-release pool was removed &
> all the leaks went away.
> Has anyone else observed a similar effect?  For now I will need to continue
> using the old version.
> Perhaps we can set up a branch separate from trunk that removes the
> auto-release pool until it's been fully baked?
> Thanks a bunch!  I appreciate the effort!
> Paul Poley
>
> 2010/3/26 Arno Puder <ar...@pu...>
>>
>> I just committed Joshua's fix.
>>
>> Arno
>>
>>
>> On 3/25/10 10:49 PM, Joshua Melcon wrote:
>> > Ok, I understand now.  Yes that is a bug -- and an interesting one.
>> > Basically, its doing:
>> >
>> >
>> > R1 = object;  // R1 has one retain
>> > Temp = R1; /
>> > R1 = object.subobject
>> > Release Temp (causing an implicit release of the object now in R1)
>> > retain R1 (so we don't lose it).
>> >
>> > Basically, the fix is to just emit the retain instruction before the
>> > rtmp release.  In the future, we will notice that the back to back
>> > retain/release is not necessacry.
>> >
>> > http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to
>> > the trunk after the review completes.
>> >
>> > Panayotis: Thanks for finding the bug! I appreciate the feedback, as
>> > well as your clear description of the issue and how to reproduce it.
>> > Please let me know if you find anything else.
>> >
>> > all :)
>> > -- Joshua Melcon
>> >
>> >
>> >
>> > On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
>> > <pan...@pa...>  wrote:
>> >> Yes these applications work.
>> >>
>> >> If you just try to convert the java source code I gave to you though,
>> >> you
>> >> will see the error :)
>> >> Just try ;)
>> >> To be fair, I've also checked a lot of code, from my own appplications
>> >> and
>> >> test cases and this was the only problem found :)
>> >>
>> >> Still, it is a bug ;)
>> >>
>> >>
>> >>
>> >> --
>> >> Panayotis
>> >> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>  έγραψε:
>> >>
>> >> If the last retain is failing it indicates that there is an issue
>> >> related to
>> >> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>> >>
>> >> I have run Xokoban, Afireworks, and another CCed program and not
>> >> encountered
>> >> any problems.  It is possible that you have found a case which we do
>> >> not
>> >> handle correctly that doesn't show up in those programs.  Later tonight
>> >> I
>> >> can attempt to reproduce this error using one of our demo apps --
>> >>
>> >> Could you confirm that the Xokoban and Afireworks demo apps are working
>> >> for
>> >> you?
>> >>
>> >> Thanks,
>> >>
>> >>
>> >> -- Joshua Melcon
>> >>
>> >>
>> >> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
>> >>>
>> >>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>> >>>
>> >>>>     _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2
>> >>>> comes
>> >>>> back ref count += 1 because its a get function
>> >>>>     _rtmp.o =  _r2.o; // We are overwriting R2 on the next line, so
>> >>>> we
>> >>>> need to free our +1 afterwords
>> >>>>     _r2.o = ((org_xmlvm_iphone_CGRect*)
>> >>>> _r2.o)->size_org_xmlvm_iphone_
>> >>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>> >>>>     [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the +=
>> >>>> from
>> >>>> the first line
>> >>>>     [_r2.o retain]; // retaining the value from _r2, presumably
>> >>>> because
>> >>>> we will be returning soon (can't tell without the rest of the code).
>> >>>>
>> >>>> But, based on this code sequence, everything looks correct?  How does
>> >>>> _r2.o retain break things?
>> >>>
>> >>>
>> >>> It says that it tries to retain am already fee'd object.
>> >>>
>> >>> Try it for yourself and see ;)
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Download Intel&#174; 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
>> >>
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download Intel&#174; 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
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; 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
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Joshua M. <xm...@me...>]

Thanks for the project -- it was very easy to get running.  After some
investigation, it looks like the call to NSMutableArray
objectEnumerator causes an object to be allocated in the auto release
pool.  I verified it by experiment, but it also looks to be how the
NSCollection classes work:

http://svn.opengroupware.org/SOPE/trunk/libFoundation/Foundation/NSDictionary.m

- (NSEnumerator*)objectEnumerator
{
    return AUTORELEASE([[_NSDictionaryObjectEnumerator alloc]
                           initWithDictionary:self]);
}

The reference code is doing its job perfectly.  The NsMutableArray is
also OK. Eventually, if the thread terminated it would cause all the
itereators that were added to the autorelease pool to be freed.
Basically the call stack is:

run thread // creates an auto release pool, releases after its callees
come back.
...
loop forever creating iterators in the auto release pool, effectively
never freeing the memory the iterators used.

I am too tired to think of a clever solution at the moment, but I will
look at it tomorrow.  If you want a workaround, just use a for loop
rather than an iterator in that thread :/

It seems somewhat weird that the enumerators work this way in obj c,
because it creates this probably in normal objective c... Course its
nice to not have to worry about freeing enumerators....

-- Joshua Melcon



2010/3/27 Paul Poley <bay...@gm...>:
> Sure thing.  I've attached an Eclipse project.  It starts the UI & then runs
> a background thread, which infinitely loops.  Inside the loop, a method is
> called so that anything allocated can be released, which wouldn't otherwise
> happen until the loop ended (that fact is unrelated to our discussion).
> Inside the method, an ArrayList is allocated & iterated.  Nothing is
> actually added to it.
> When compiling against revision 977, memory usage remains consistent.  When
> compiling against revision 981, memory usage is quickly increased.  I use
> the OSX "Activity Monitor" to check memory usage.
> Thanks Josh!
> Paul Poley
>
>
> 2010/3/27 Joshua Melcon <xm...@me...>
>>
>> Hi Paul,
>>
>> I attempted to produce a leak with the array list iterator today using
>> a few variations of code similar to:
>>
>> ArrayList<InternalClass> a = new ArrayList<InternalClass>();
>>                for(int x=0;x<10000;x++)
>>                {
>>                a.add(new InternalClass());
>>                }
>>                for(InternalClass x:a)
>>                {
>>                        x.toString();
>>                }
>>
>> I am unable to see any leaking objects.
>>
>> Additionally, I inspected the array list iterator code -- it seems
>> work when I step through it.
>>
>> In order to debug this issue I think that I need some help from you.
>> If you could create a self contained example that causes a memory leak
>> I would be more than happy to figure out what is going on.
>>
>> Thanks,
>>
>> -- Joshua Melcon
>>
>>
>>
>> 2010/3/27 Paul Poley <bay...@gm...>:
>> > Hi All,
>> > I was just making some suggested modifications to a couple of my
>> > patches.
>> >  After I was done, I was testing to make sure I didn't introduce any
>> > memory
>> > leaks.
>> > Unfortunately, the code seemed to have a lot of leaks.  Upon digging in,
>> > the
>> > first leak I found was in ArrayList's iterator(), which didn't leak
>> > before &
>> > nothing had changed (side note: that existed before my patches).  When I
>> > first tested & submitted my patches, they were using the auto-release
>> > pool.
>> >  So I reverted to revision 977 before the auto-release pool was removed
>> > &
>> > all the leaks went away.
>> > Has anyone else observed a similar effect?  For now I will need to
>> > continue
>> > using the old version.
>> > Perhaps we can set up a branch separate from trunk that removes the
>> > auto-release pool until it's been fully baked?
>> > Thanks a bunch!  I appreciate the effort!
>> > Paul Poley
>> >
>> > 2010/3/26 Arno Puder <ar...@pu...>
>> >>
>> >> I just committed Joshua's fix.
>> >>
>> >> Arno
>> >>
>> >>
>> >> On 3/25/10 10:49 PM, Joshua Melcon wrote:
>> >> > Ok, I understand now.  Yes that is a bug -- and an interesting one.
>> >> > Basically, its doing:
>> >> >
>> >> >
>> >> > R1 = object;  // R1 has one retain
>> >> > Temp = R1; /
>> >> > R1 = object.subobject
>> >> > Release Temp (causing an implicit release of the object now in R1)
>> >> > retain R1 (so we don't lose it).
>> >> >
>> >> > Basically, the fix is to just emit the retain instruction before the
>> >> > rtmp release.  In the future, we will notice that the back to back
>> >> > retain/release is not necessacry.
>> >> >
>> >> > http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it
>> >> > to
>> >> > the trunk after the review completes.
>> >> >
>> >> > Panayotis: Thanks for finding the bug! I appreciate the feedback, as
>> >> > well as your clear description of the issue and how to reproduce it.
>> >> > Please let me know if you find anything else.
>> >> >
>> >> > all :)
>> >> > -- Joshua Melcon
>> >> >
>> >> >
>> >> >
>> >> > On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
>> >> > <pan...@pa...>  wrote:
>> >> >> Yes these applications work.
>> >> >>
>> >> >> If you just try to convert the java source code I gave to you
>> >> >> though,
>> >> >> you
>> >> >> will see the error :)
>> >> >> Just try ;)
>> >> >> To be fair, I've also checked a lot of code, from my own
>> >> >> appplications
>> >> >> and
>> >> >> test cases and this was the only problem found :)
>> >> >>
>> >> >> Still, it is a bug ;)
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Panayotis
>> >> >> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>  έγραψε:
>> >> >>
>> >> >> If the last retain is failing it indicates that there is an issue
>> >> >> related to
>> >> >> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>> >> >>
>> >> >> I have run Xokoban, Afireworks, and another CCed program and not
>> >> >> encountered
>> >> >> any problems.  It is possible that you have found a case which we do
>> >> >> not
>> >> >> handle correctly that doesn't show up in those programs.  Later
>> >> >> tonight
>> >> >> I
>> >> >> can attempt to reproduce this error using one of our demo apps --
>> >> >>
>> >> >> Could you confirm that the Xokoban and Afireworks demo apps are
>> >> >> working
>> >> >> for
>> >> >> you?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >>
>> >> >> -- Joshua Melcon
>> >> >>
>> >> >>
>> >> >> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
>> >> >>>
>> >> >>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>> >> >>>
>> >> >>>>     _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2
>> >> >>>> comes
>> >> >>>> back ref count += 1 because its a get function
>> >> >>>>     _rtmp.o =  _r2.o; // We are overwriting R2 on the next line,
>> >> >>>> so
>> >> >>>> we
>> >> >>>> need to free our +1 afterwords
>> >> >>>>     _r2.o = ((org_xmlvm_iphone_CGRect*)
>> >> >>>> _r2.o)->size_org_xmlvm_iphone_
>> >> >>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>> >> >>>>     [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the +=
>> >> >>>> from
>> >> >>>> the first line
>> >> >>>>     [_r2.o retain]; // retaining the value from _r2, presumably
>> >> >>>> because
>> >> >>>> we will be returning soon (can't tell without the rest of the
>> >> >>>> code).
>> >> >>>>
>> >> >>>> But, based on this code sequence, everything looks correct?  How
>> >> >>>> does
>> >> >>>> _r2.o retain break things?
>> >> >>>
>> >> >>>
>> >> >>> It says that it tries to retain am already fee'd object.
>> >> >>>
>> >> >>> Try it for yourself and see ;)
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> ------------------------------------------------------------------------------
>> >> >>> Download Intel&#174; 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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Download Intel&#174; 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
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Download Intel&#174; 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
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download Intel&#174; 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
>> >
>> >
>
>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Arno P. <ar...@pu...>]

it is actually interesting to note that Cocoa places quite a few objects 
in the autorelease pool. If you comment out the creation of the one 
autorelease pool in XMLVM's main() method, you will get a lot of 
warnings of leaking objects. Since XMLVM no longer places objects in the 
autorelease pool, these must come from Cocoa. As a matter of fact, all 
so-called convenience methods where the object is not created via the 
usual alloc/init (e.g., [NSString string*]), are placed by convention in 
an autorelease pool. So the question is how to deal with that in XMLVM. 
One suggestion would be to implement System.gc() so that it calls [pool 
drain]. It would be the programmers responsibility to call System.gc() 
from time to time.

In case of the enumerator, since we know it is placed in the autorelease 
pool, one could do a [pool drain] in the wrapper.

Any other ideas?

Arno


On 3/28/10 1:21 AM, Joshua Melcon wrote:
> Thanks for the project -- it was very easy to get running.  After some
> investigation, it looks like the call to NSMutableArray
> objectEnumerator causes an object to be allocated in the auto release
> pool.  I verified it by experiment, but it also looks to be how the
> NSCollection classes work:
>
> http://svn.opengroupware.org/SOPE/trunk/libFoundation/Foundation/NSDictionary.m
>
> - (NSEnumerator*)objectEnumerator
> {
>      return AUTORELEASE([[_NSDictionaryObjectEnumerator alloc]
>                             initWithDictionary:self]);
> }
>
> The reference code is doing its job perfectly.  The NsMutableArray is
> also OK. Eventually, if the thread terminated it would cause all the
> itereators that were added to the autorelease pool to be freed.
> Basically the call stack is:
>
> run thread // creates an auto release pool, releases after its callees
> come back.
> ...
> loop forever creating iterators in the auto release pool, effectively
> never freeing the memory the iterators used.
>
> I am too tired to think of a clever solution at the moment, but I will
> look at it tomorrow.  If you want a workaround, just use a for loop
> rather than an iterator in that thread :/
>
> It seems somewhat weird that the enumerators work this way in obj c,
> because it creates this probably in normal objective c... Course its
> nice to not have to worry about freeing enumerators....
>
> -- Joshua Melcon
>
>
>
> 2010/3/27 Paul Poley<bay...@gm...>:
>> Sure thing.  I've attached an Eclipse project.  It starts the UI&  then runs
>> a background thread, which infinitely loops.  Inside the loop, a method is
>> called so that anything allocated can be released, which wouldn't otherwise
>> happen until the loop ended (that fact is unrelated to our discussion).
>> Inside the method, an ArrayList is allocated&  iterated.  Nothing is
>> actually added to it.
>> When compiling against revision 977, memory usage remains consistent.  When
>> compiling against revision 981, memory usage is quickly increased.  I use
>> the OSX "Activity Monitor" to check memory usage.
>> Thanks Josh!
>> Paul Poley
>>
>>
>> 2010/3/27 Joshua Melcon<xm...@me...>
>>>
>>> Hi Paul,
>>>
>>> I attempted to produce a leak with the array list iterator today using
>>> a few variations of code similar to:
>>>
>>> ArrayList<InternalClass>  a = new ArrayList<InternalClass>();
>>>                 for(int x=0;x<10000;x++)
>>>                 {
>>>                 a.add(new InternalClass());
>>>                 }
>>>                 for(InternalClass x:a)
>>>                 {
>>>                         x.toString();
>>>                 }
>>>
>>> I am unable to see any leaking objects.
>>>
>>> Additionally, I inspected the array list iterator code -- it seems
>>> work when I step through it.
>>>
>>> In order to debug this issue I think that I need some help from you.
>>> If you could create a self contained example that causes a memory leak
>>> I would be more than happy to figure out what is going on.
>>>
>>> Thanks,
>>>
>>> -- Joshua Melcon
>>>
>>>
>>>
>>> 2010/3/27 Paul Poley<bay...@gm...>:
>>>> Hi All,
>>>> I was just making some suggested modifications to a couple of my
>>>> patches.
>>>>   After I was done, I was testing to make sure I didn't introduce any
>>>> memory
>>>> leaks.
>>>> Unfortunately, the code seemed to have a lot of leaks.  Upon digging in,
>>>> the
>>>> first leak I found was in ArrayList's iterator(), which didn't leak
>>>> before&
>>>> nothing had changed (side note: that existed before my patches).  When I
>>>> first tested&  submitted my patches, they were using the auto-release
>>>> pool.
>>>>   So I reverted to revision 977 before the auto-release pool was removed
>>>> &
>>>> all the leaks went away.
>>>> Has anyone else observed a similar effect?  For now I will need to
>>>> continue
>>>> using the old version.
>>>> Perhaps we can set up a branch separate from trunk that removes the
>>>> auto-release pool until it's been fully baked?
>>>> Thanks a bunch!  I appreciate the effort!
>>>> Paul Poley
>>>>
>>>> 2010/3/26 Arno Puder<ar...@pu...>
>>>>>
>>>>> I just committed Joshua's fix.
>>>>>
>>>>> Arno
>>>>>
>>>>>
>>>>> On 3/25/10 10:49 PM, Joshua Melcon wrote:
>>>>>> Ok, I understand now.  Yes that is a bug -- and an interesting one.
>>>>>> Basically, its doing:
>>>>>>
>>>>>>
>>>>>> R1 = object;  // R1 has one retain
>>>>>> Temp = R1; /
>>>>>> R1 = object.subobject
>>>>>> Release Temp (causing an implicit release of the object now in R1)
>>>>>> retain R1 (so we don't lose it).
>>>>>>
>>>>>> Basically, the fix is to just emit the retain instruction before the
>>>>>> rtmp release.  In the future, we will notice that the back to back
>>>>>> retain/release is not necessacry.
>>>>>>
>>>>>> http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it
>>>>>> to
>>>>>> the trunk after the review completes.
>>>>>>
>>>>>> Panayotis: Thanks for finding the bug! I appreciate the feedback, as
>>>>>> well as your clear description of the issue and how to reproduce it.
>>>>>> Please let me know if you find anything else.
>>>>>>
>>>>>> all :)
>>>>>> -- Joshua Melcon
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
>>>>>> <pan...@pa...>    wrote:
>>>>>>> Yes these applications work.
>>>>>>>
>>>>>>> If you just try to convert the java source code I gave to you
>>>>>>> though,
>>>>>>> you
>>>>>>> will see the error :)
>>>>>>> Just try ;)
>>>>>>> To be fair, I've also checked a lot of code, from my own
>>>>>>> appplications
>>>>>>> and
>>>>>>> test cases and this was the only problem found :)
>>>>>>>
>>>>>>> Still, it is a bug ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Panayotis
>>>>>>> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...>    έγραψε:
>>>>>>>
>>>>>>> If the last retain is failing it indicates that there is an issue
>>>>>>> related to
>>>>>>> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize.
>>>>>>>
>>>>>>> I have run Xokoban, Afireworks, and another CCed program and not
>>>>>>> encountered
>>>>>>> any problems.  It is possible that you have found a case which we do
>>>>>>> not
>>>>>>> handle correctly that doesn't show up in those programs.  Later
>>>>>>> tonight
>>>>>>> I
>>>>>>> can attempt to reproduce this error using one of our demo apps --
>>>>>>>
>>>>>>> Could you confirm that the Xokoban and Afireworks demo apps are
>>>>>>> working
>>>>>>> for
>>>>>>> you?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>> -- Joshua Melcon
>>>>>>>
>>>>>>>
>>>>>>> 2010/3/25 Panayotis Katsaloulis<pan...@pa...>
>>>>>>>>
>>>>>>>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>>>>>>>>
>>>>>>>>>      _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2
>>>>>>>>> comes
>>>>>>>>> back ref count += 1 because its a get function
>>>>>>>>>      _rtmp.o =  _r2.o; // We are overwriting R2 on the next line,
>>>>>>>>> so
>>>>>>>>> we
>>>>>>>>> need to free our +1 afterwords
>>>>>>>>>      _r2.o = ((org_xmlvm_iphone_CGRect*)
>>>>>>>>> _r2.o)->size_org_xmlvm_iphone_
>>>>>>>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed
>>>>>>>>>      [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the +=
>>>>>>>>> from
>>>>>>>>> the first line
>>>>>>>>>      [_r2.o retain]; // retaining the value from _r2, presumably
>>>>>>>>> because
>>>>>>>>> we will be returning soon (can't tell without the rest of the
>>>>>>>>> code).
>>>>>>>>>
>>>>>>>>> But, based on this code sequence, everything looks correct?  How
>>>>>>>>> does
>>>>>>>>> _r2.o retain break things?
>>>>>>>>
>>>>>>>>
>>>>>>>> It says that it tries to retain am already fee'd object.
>>>>>>>>
>>>>>>>> Try it for yourself and see ;)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel&#174; 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel&#174; 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
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel&#174; 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
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel&#174; 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
>>>>
>>>>
>>
>>

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Panayotis K. <pan...@pa...>]

On 28 Μαρ 2010, at 12:13 μ.μ., Arno Puder wrote:

> 
> it is actually interesting to note that Cocoa places quite a few objects 
> in the autorelease pool. If you comment out the creation of the one 
> autorelease pool in XMLVM's main() method, you will get a lot of 
> warnings of leaking objects. Since XMLVM no longer places objects in the 
> autorelease pool, these must come from Cocoa. As a matter of fact, all 
> so-called convenience methods where the object is not created via the 
> usual alloc/init (e.g., [NSString string*]), are placed by convention in 
> an autorelease pool. So the question is how to deal with that in XMLVM. 
> One suggestion would be to implement System.gc() so that it calls [pool 
> drain]. It would be the programmers responsibility to call System.gc() 
> from time to time.
> 
> In case of the enumerator, since we know it is placed in the autorelease 
> pool, one could do a [pool drain] in the wrapper.
> 
> Any other ideas?
> 
> Arno


I think I've seen in various places in the autorelease pool objects that are produced through "convenient" methods.
So in any case, an auto-release pool should be always there and keep up with what would have happened when programming in obj-c.
Code as usual, some objects will be on the autorelease pool, and when the specific even cycle ends, then the memory of these objects will return to the system.
So I believe that there should be no special handling of enumerators.

Of course to do some cleanup by overriding  System.gc() , is not a bad idea ;)

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Paul P. <bay...@gm...>]

That is too bad that Cocoa makes use of the auto-release pool  Hopefully we
can figure out a way where we don't have to specifically invoke the garbage
collector, so we can continue converting any old Java program to Obj-C.  I
love not having to do garbage collection in Java & that's part of what makes
XMLVM so great!  I hope we don't need to start worrying about that.  For now
I will take the performance hit over the possible memory leaks caused from
Cocoa's unfortunate use of the auto-release pool.

What I'm working has a couple of background threads that generally continue
running indefinitely (client/server app), so waiting for thread termination
in order to garbage collect is also not an option.

Panayotis,
Is your suggestion a combination of the way we've been using
NSAutoReleasePool & the new way without?  If that works & increases
performance, that seems like a plan.  The only drawback I can think of is
longer build times.

I hope we can find a good solution, so we can all continue using the same
branch of code.  Let me know if I can assist!  Thanks again for your
contribution Joshua!

Thanks everyone!
Paul Poley

Re: [xmlvm-users] No dependence on NSAutoreleasePool

[Arno P. <ar...@pu...>]

I do agree that it is generally preferable to retain the semantics of 
the JVM. Having to call explicitly System.gc() periodically would be a 
deviation of this. However, merely instantiating NSAutoreleasePool 
causes *huge* performance hit (NSAutoreleasePool is a pretty complicated 
data structure when you think about it). Instead of instantiating a new 
NSAutoreleasePool in the wrappers as Gergely suggested, I propose to 
simply drain the one NSAutoreleasePool we need to create anyways.

Arno


On 3/28/10 11:34 PM, Gergely Kis wrote:
> Hi,
>
> Since the generated code AFAIK does not call any Cocoa methods directly,
> my suggestion is that in the compat-lib we should create autorelease
> pools in the wrapper methods to make sure that if such Cocoa methods are
> called, the objects get into an autorelease pool in the same method.
> Then of course one needs to do a [x retain] on return, as usual.  This
> way the compat-lib will conform to both the Cocoa Memory Management
> guidelines and the XMLVM calling convention.
>
> I planned to do this even when the generated code still used autorelease
> pools.
> The reason:
> If you call a wrapper method in a tight loop, which implicitly puts
> objects on the nearest autorelease pool in the call stack, you could end
> up with many objects in the pool that should have been freed already,
> before your application's Java method has the chance to free them.
>
> Of course I think it is advisable to use the [[alloc] init*]  sequence
> everywhere, if you can, because of the performance benefits. However, I
> already ran into places where the Cocoa API only provides you
> autoreleased objects, and you have no way to request otherwise.
>
> I think the strategy should be to minimize the deviations from the JVM
> based Java platforms, and making the programmers call System.gc() is in
> my opinion a step in the wrong direction.
>
> Best Regards,
> Gergely
>
> 2010/3/28 Arno Puder <ar...@pu... <mailto:ar...@pu...>>
>
>
>     it is actually interesting to note that Cocoa places quite a few objects
>     in the autorelease pool. If you comment out the creation of the one
>     autorelease pool in XMLVM's main() method, you will get a lot of
>     warnings of leaking objects. Since XMLVM no longer places objects in the
>     autorelease pool, these must come from Cocoa. As a matter of fact, all
>     so-called convenience methods where the object is not created via the
>     usual alloc/init (e.g., [NSString string*]), are placed by convention in
>     an autorelease pool. So the question is how to deal with that in XMLVM.
>     One suggestion would be to implement System.gc() so that it calls [pool
>     drain]. It would be the programmers responsibility to call System.gc()
>     from time to time.
>
>     In case of the enumerator, since we know it is placed in the autorelease
>     pool, one could do a [pool drain] in the wrapper.
>
>     Any other ideas?
>
>     Arno
>
>
>     On 3/28/10 1:21 AM, Joshua Melcon wrote:
>      > Thanks for the project -- it was very easy to get running.  After
>     some
>      > investigation, it looks like the call to NSMutableArray
>      > objectEnumerator causes an object to be allocated in the auto release
>      > pool.  I verified it by experiment, but it also looks to be how the
>      > NSCollection classes work:
>      >
>      >
>     http://svn.opengroupware.org/SOPE/trunk/libFoundation/Foundation/NSDictionary.m
>      >
>      > - (NSEnumerator*)objectEnumerator
>      > {
>      >      return AUTORELEASE([[_NSDictionaryObjectEnumerator alloc]
>      >                             initWithDictionary:self]);
>      > }
>      >
>      > The reference code is doing its job perfectly.  The NsMutableArray is
>      > also OK. Eventually, if the thread terminated it would cause all the
>      > itereators that were added to the autorelease pool to be freed.
>      > Basically the call stack is:
>      >
>      > run thread // creates an auto release pool, releases after its
>     callees
>      > come back.
>      > ...
>      > loop forever creating iterators in the auto release pool, effectively
>      > never freeing the memory the iterators used.
>      >
>      > I am too tired to think of a clever solution at the moment, but I
>     will
>      > look at it tomorrow.  If you want a workaround, just use a for loop
>      > rather than an iterator in that thread :/
>      >
>      > It seems somewhat weird that the enumerators work this way in obj c,
>      > because it creates this probably in normal objective c... Course its
>      > nice to not have to worry about freeing enumerators....
>      >
>      > -- Joshua Melcon
>      >
>      >
>      >
>      > 2010/3/27 Paul Poley<bay...@gm...
>     <mailto:bay...@gm...>>:
>      >> Sure thing.  I've attached an Eclipse project.  It starts the
>     UI&  then runs
>      >> a background thread, which infinitely loops.  Inside the loop, a
>     method is
>      >> called so that anything allocated can be released, which
>     wouldn't otherwise
>      >> happen until the loop ended (that fact is unrelated to our
>     discussion).
>      >> Inside the method, an ArrayList is allocated&  iterated.  Nothing is
>      >> actually added to it.
>      >> When compiling against revision 977, memory usage remains
>     consistent.  When
>      >> compiling against revision 981, memory usage is quickly
>     increased.  I use
>      >> the OSX "Activity Monitor" to check memory usage.
>      >> Thanks Josh!
>      >> Paul Poley
>      >>
>      >>
>      >> 2010/3/27 Joshua Melcon<xm...@me... <mailto:xm...@me...>>
>      >>>
>      >>> Hi Paul,
>      >>>
>      >>> I attempted to produce a leak with the array list iterator
>     today using
>      >>> a few variations of code similar to:
>      >>>
>      >>> ArrayList<InternalClass>  a = new ArrayList<InternalClass>();
>      >>>                 for(int x=0;x<10000;x++)
>      >>>                 {
>      >>>                 a.add(new InternalClass());
>      >>>                 }
>      >>>                 for(InternalClass x:a)
>      >>>                 {
>      >>>                         x.toString();
>      >>>                 }
>      >>>
>      >>> I am unable to see any leaking objects.
>      >>>
>      >>> Additionally, I inspected the array list iterator code -- it seems
>      >>> work when I step through it.
>      >>>
>      >>> In order to debug this issue I think that I need some help from
>     you.
>      >>> If you could create a self contained example that causes a
>     memory leak
>      >>> I would be more than happy to figure out what is going on.
>      >>>
>      >>> Thanks,
>      >>>
>      >>> -- Joshua Melcon
>      >>>
>      >>>
>      >>>
>      >>> 2010/3/27 Paul Poley<bay...@gm...
>     <mailto:bay...@gm...>>:
>      >>>> Hi All,
>      >>>> I was just making some suggested modifications to a couple of my
>      >>>> patches.
>      >>>>   After I was done, I was testing to make sure I didn't
>     introduce any
>      >>>> memory
>      >>>> leaks.
>      >>>> Unfortunately, the code seemed to have a lot of leaks.  Upon
>     digging in,
>      >>>> the
>      >>>> first leak I found was in ArrayList's iterator(), which didn't
>     leak
>      >>>> before&
>      >>>> nothing had changed (side note: that existed before my
>     patches).  When I
>      >>>> first tested&  submitted my patches, they were using the
>     auto-release
>      >>>> pool.
>      >>>>   So I reverted to revision 977 before the auto-release pool
>     was removed
>      >>>> &
>      >>>> all the leaks went away.
>      >>>> Has anyone else observed a similar effect?  For now I will need to
>      >>>> continue
>      >>>> using the old version.
>      >>>> Perhaps we can set up a branch separate from trunk that
>     removes the
>      >>>> auto-release pool until it's been fully baked?
>      >>>> Thanks a bunch!  I appreciate the effort!
>      >>>> Paul Poley
>      >>>>
>      >>>> 2010/3/26 Arno Puder<ar...@pu... <mailto:ar...@pu...>>
>      >>>>>
>      >>>>> I just committed Joshua's fix.
>      >>>>>
>      >>>>> Arno
>      >>>>>
>      >>>>>
>      >>>>> On 3/25/10 10:49 PM, Joshua Melcon wrote:
>      >>>>>> Ok, I understand now.  Yes that is a bug -- and an
>     interesting one.
>      >>>>>> Basically, its doing:
>      >>>>>>
>      >>>>>>
>      >>>>>> R1 = object;  // R1 has one retain
>      >>>>>> Temp = R1; /
>      >>>>>> R1 = object.subobject
>      >>>>>> Release Temp (causing an implicit release of the object now
>     in R1)
>      >>>>>> retain R1 (so we don't lose it).
>      >>>>>>
>      >>>>>> Basically, the fix is to just emit the retain instruction
>     before the
>      >>>>>> rtmp release.  In the future, we will notice that the back
>     to back
>      >>>>>> retain/release is not necessacry.
>      >>>>>>
>      >>>>>> http://xmlvm-reviews.appspot.com/33001 is a fix -- i will
>     submit it
>      >>>>>> to
>      >>>>>> the trunk after the review completes.
>      >>>>>>
>      >>>>>> Panayotis: Thanks for finding the bug! I appreciate the
>     feedback, as
>      >>>>>> well as your clear description of the issue and how to
>     reproduce it.
>      >>>>>> Please let me know if you find anything else.
>      >>>>>>
>      >>>>>> all :)
>      >>>>>> -- Joshua Melcon
>      >>>>>>
>      >>>>>>
>      >>>>>>
>      >>>>>> On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis
>      >>>>>> <pan...@pa... <mailto:pan...@pa...>>
>       wrote:
>      >>>>>>> Yes these applications work.
>      >>>>>>>
>      >>>>>>> If you just try to convert the java source code I gave to you
>      >>>>>>> though,
>      >>>>>>> you
>      >>>>>>> will see the error :)
>      >>>>>>> Just try ;)
>      >>>>>>> To be fair, I've also checked a lot of code, from my own
>      >>>>>>> appplications
>      >>>>>>> and
>      >>>>>>> test cases and this was the only problem found :)
>      >>>>>>>
>      >>>>>>> Still, it is a bug ;)
>      >>>>>>>
>      >>>>>>>
>      >>>>>>>
>      >>>>>>> --
>      >>>>>>> Panayotis
>      >>>>>>> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...
>     <mailto:xm...@me...>>    έγραψε:
>      >>>>>>>
>      >>>>>>> If the last retain is failing it indicates that there is an
>     issue
>      >>>>>>> related to
>      >>>>>>> the releasing /retaining/nulling of
>     size_org_xmlvm_iphone_CGSize.
>      >>>>>>>
>      >>>>>>> I have run Xokoban, Afireworks, and another CCed program
>     and not
>      >>>>>>> encountered
>      >>>>>>> any problems.  It is possible that you have found a case
>     which we do
>      >>>>>>> not
>      >>>>>>> handle correctly that doesn't show up in those programs.  Later
>      >>>>>>> tonight
>      >>>>>>> I
>      >>>>>>> can attempt to reproduce this error using one of our demo
>     apps --
>      >>>>>>>
>      >>>>>>> Could you confirm that the Xokoban and Afireworks demo apps are
>      >>>>>>> working
>      >>>>>>> for
>      >>>>>>> you?
>      >>>>>>>
>      >>>>>>> Thanks,
>      >>>>>>>
>      >>>>>>>
>      >>>>>>> -- Joshua Melcon
>      >>>>>>>
>      >>>>>>>
>      >>>>>>> 2010/3/25 Panayotis Katsaloulis<pan...@pa...
>     <mailto:pan...@pa...>>
>      >>>>>>>>
>      >>>>>>>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote:
>      >>>>>>>>
>      >>>>>>>>>      _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o)
>     getFrame__]; // R2
>      >>>>>>>>> comes
>      >>>>>>>>> back ref count += 1 because its a get function
>      >>>>>>>>>      _rtmp.o =  _r2.o; // We are overwriting R2 on the
>     next line,
>      >>>>>>>>> so
>      >>>>>>>>> we
>      >>>>>>>>> need to free our +1 afterwords
>      >>>>>>>>>      _r2.o = ((org_xmlvm_iphone_CGRect*)
>      >>>>>>>>> _r2.o)->size_org_xmlvm_iphone_
>      >>>>>>>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not
>     needed
>      >>>>>>>>>      [_rtmp.o release]; _rtmp.o = [NSNull null]; //
>     release the +=
>      >>>>>>>>> from
>      >>>>>>>>> the first line
>      >>>>>>>>>      [_r2.o retain]; // retaining the value from _r2,
>     presumably
>      >>>>>>>>> because
>      >>>>>>>>> we will be returning soon (can't tell without the rest of the
>      >>>>>>>>> code).
>      >>>>>>>>>
>      >>>>>>>>> But, based on this code sequence, everything looks
>     correct?  How
>      >>>>>>>>> does
>      >>>>>>>>> _r2.o retain break things?
>      >>>>>>>>
>      >>>>>>>>
>      >>>>>>>> It says that it tries to retain am already fee'd object.
>      >>>>>>>>
>      >>>>>>>> Try it for yourself and see ;)
>      >>>>>>>>
>      >>>>>>>>
>      >>>>>>>>
>      >>>>>>>>
>     ------------------------------------------------------------------------------
>      >>>>>>>> Download Intel&#174; 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...
>     <mailto:xml...@li...>
>      >>>>>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>      >>>>>>>
>      >>>>>>>
>      >>>>>>
>      >>>>>>
>      >>>>>>
>      >>>>>>
>     ------------------------------------------------------------------------------
>      >>>>>> Download Intel&#174; 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...
>     <mailto:xml...@li...>
>      >>>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>     ------------------------------------------------------------------------------
>      >>>>> Download Intel&#174; 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...
>     <mailto:xml...@li...>
>      >>>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>      >>>>
>      >>>>
>      >>>>
>      >>>>
>     ------------------------------------------------------------------------------
>      >>>> Download Intel&#174; 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...
>     <mailto:xml...@li...>
>      >>>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>      >>>>
>      >>>>
>      >>
>      >>
>
>     ------------------------------------------------------------------------------
>     Download Intel&#174; 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...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> --
> 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&#174; 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