xmlvm-users — For current and interested XMLVM users, for public discussions and anouncements.

Re: [xmlvm-users] Is this the end of XMLVM?

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

Hi,

Not to mention Unity. It would be nice to know how much money Apple may
loose if all the games written if Unity or similar frameworks would be
banned from the App Store.

Best Regards,
Gergely

2010/4/9 Arno Puder <ar...@pu...>

>
> little follow-up, as more and more blogs are picking up on this subject.
> Here is an interesting article that makes some good points:
>
>
> http://joeberkovitz.com/blog/2010/04/08/apple-takes-stance-on-consciousness/
>
> It will really be interesting to see how Adobe and Novell react to this.
>
> Arno
>
>
> On 4/9/10 4:49 PM, Björn Caroll wrote:
> > http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
> >
> >
> ------------------------------------------------------------------------------
> > 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] Is this the end of XMLVM?

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

little follow-up, as more and more blogs are picking up on this subject. 
Here is an interesting article that makes some good points:

http://joeberkovitz.com/blog/2010/04/08/apple-takes-stance-on-consciousness/

It will really be interesting to see how Adobe and Novell react to this.

Arno


On 4/9/10 4:49 PM, Björn Caroll wrote:
> http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Is this the end of XMLVM?

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

Guys,

we have certainly noticed this change in the iPhone SDK license 
agreement. With the way the new agreement is formulated, Apple pretty 
much bars any cross-platform technology, including XMLVM, MonoTouch, and 
Adobe's planned offering to cross-compile Flash applications to the 
iPhone. Let give it some time and see what the final language will look 
like. In particular I'm looking forward to Adobe's and Novell's response 
to this.

I'm just waiting for the license agreement to bar for-loops in 
Objective-C because Steve Jobs doesn't like them (ok, that's a German 
trying to be funny).

 From our side it is business as usual for now.

Arno



On 4/9/10 4:49 PM, Björn Caroll wrote:
> http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Is this the end of XMLVM?

[Sascha H. <sa...@xm...>]

Björn,

we are aware of this and are currently investigating the situation. We don't
feel confident at this point to say XMLVM is safe or not.

We know that this affects most people in the XMLVM community, so we will
update you as soon as we know more.

Thanks
// Sascha

On Fri, Apr 9, 2010 at 4:49 PM, Björn Caroll <bj...@ca...>wrote:

> http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler
>
>
> ------------------------------------------------------------------------------
> 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
>

[xmlvm-users] Is this the end of XMLVM?

[Björn C. <bj...@ca...>]

http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler

[xmlvm-users] type in CGFont.createFromDataProider

[Joris V. <jbv...@gm...>]

CGFont.createFromDataProider should be renamed to type in
CGFont.createFromDataProvider

[xmlvm-users] UIImage broken

[Joris V. <jbv...@gm...>]

Hi,

UIImage is currently broken. drawAtPoint(CGPoint) isn't implemented in
objc. drawAtPoint(int, int) is.
So I change the java code to:
    public void drawAtPoint(int x, int y) {
        CGContext.UICurrentContext().xmlvmGetGraphics2D().drawImage(image,
x, y, Simulator.getDisplay());
    }

I think it's better to change the objc code, because the objc code is
creating a CGPoint from x,y

[xmlvm-users] missing: dex:add-long|dex:add-long-2addr

[Joris V. <jbv...@gm...>]

Hi, I came across a missing op in xmlvm2objc (svn trunk). I added it
before <xsl:template match="dex:sub-long|dex:sub-long-2addr"> :

<xsl:template match="dex:add-long|dex:add-long-2addr">
  <xsl:text>    _r</xsl:text>
  <xsl:value-of select="@vx"/>
  <xsl:text>.l = _r</xsl:text>
  <xsl:value-of select="@vy"/>
  <xsl:text>.l + _r</xsl:text>
  <xsl:value-of select="@vz"/>
  <xsl:text>.l;
</xsl:text>
</xsl:template>

Re: [xmlvm-users] iTunesConnect Upload problems

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

note that this is *not* a problem with XMLVM, but with Apple's 
complicated submission procedure. You need to adjust the file name of 
your icon in Info.plist. Check the respective property.

Arno


On 4/3/10 9:01 PM, Dr. Alexander K. Seewald wrote:
> Hi,
>
> I'm in the process of uploading my app to the App Store using iTunes
> Connect but keep running into problems (the app was cross-compiled
> from Android)
>
> When uploading via webform, I get "The binary you uploaded was
> invalid. The Info.plist file was missing or could not be parsed."
> - Info.plist is present, can be parsed (app works on simulator and actual
>    device), and contains only ASCII characters. I've also tried to
>    remove Entitlements.plist to no avail.
>
> When uploading via Application Loader, I get "iPhone/iPod touch:
> launcher.png: icon dimensions (0 x 0) don't meet the size
> requirements. The icon file must be 57 x 57 pixels, in png format"
> - The icon file _is_ 57x57 PNG. I've tried uncompressed PNG, with
>    and without alpha channels, reducing color depth. In each case the
>    icon is correctly shown on the device but I get the same error.
>    In fact, the webform upload told me earlier that my png had only
>    48x48 pixels and I fixed this.
>
> I'm compiling the app for the device using the ad-hoc distribution -
> it always works there. I'm compiling for the app-store using the app
> store distribution - I always get one of these errors (depending on
> upload method)
>
> Both errors seem to be spurious. Does anyone have a clue what is going
> on here? I've sent these upload errors to Apple but did not get
> anything back from them.
>
> Best,
>    Alex
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

[xmlvm-users] iTunesConnect Upload problems

[Dr. A. K. S. <al...@se...>]

Hi,

I'm in the process of uploading my app to the App Store using iTunes
Connect but keep running into problems (the app was cross-compiled
from Android)

When uploading via webform, I get "The binary you uploaded was
invalid. The Info.plist file was missing or could not be parsed."
- Info.plist is present, can be parsed (app works on simulator and actual
  device), and contains only ASCII characters. I've also tried to
  remove Entitlements.plist to no avail.

When uploading via Application Loader, I get "iPhone/iPod touch:
launcher.png: icon dimensions (0 x 0) don't meet the size
requirements. The icon file must be 57 x 57 pixels, in png format"
- The icon file _is_ 57x57 PNG. I've tried uncompressed PNG, with
  and without alpha channels, reducing color depth. In each case the
  icon is correctly shown on the device but I get the same error.
  In fact, the webform upload told me earlier that my png had only
  48x48 pixels and I fixed this.

I'm compiling the app for the device using the ad-hoc distribution -
it always works there. I'm compiling for the app-store using the app
store distribution - I always get one of these errors (depending on
upload method)

Both errors seem to be spurious. Does anyone have a clue what is going
on here? I've sent these upload errors to Apple but did not get
anything back from them.

Best,
  Alex

[xmlvm-users] Proposal for an XMLVM Debugging Architecture

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

Guys,

we have been discussing a possible debugging architecture for XMLVM. 
There is currently no way to debug a program that was created with XMLVM 
in Apple's emulator or on an actual device. It is possible to debug on 
the Java side using XMLVM's emulation library for Cocoa Touch. However, 
this has two major disadvantages: problems often only materialize when 
you deploy your application on the actual device and it also requires us 
to keep pace with our own emulation library. We are getting more and 
more patches where people create new Java wrappers for Cocoa Touch API, 
but don't have the time and resources to provide an implementation for 
our Java-based emulation library. This approach does not scale.

To solve both problems, we consider to focus our resources in a 
debugging architecture. Java supports remote debugging:
http://java.sun.com/javase/technologies/core/toolsapis/jpda/index.jsp

In particular, there is the so-called Java Debug Wire Protocol (JDWP):
http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jdwp-spec.html

It defines an on-the-wire protocol between debugger and debugee (the 
application to be debugged). So, here is the idea we have been toying 
with: write a JDWP protocol engine in Java, cross-compile it to 
Objective-C, and deploy it (together with the application to be 
debugged) on the device. It should then be possible to connect via any 
standard Java Debugger to the application running on the device.

Once we achieve that goal, it would enable us to do source-level 
debugging on the actual device and we no longer need to maintain our 
Java emulation library (since we would just leverage Apple's own emulator).

We think that this is the way to go. Leaves us only with *a lot* of very 
tricky code. To implement the JDWP is no small feat. Anyone out there 
who has some experience with this? I have been poking around to see if 
there might already be a Java-based implementation of the JDWP, but I 
couldn't find one. Anyone?

Arno

Re: [xmlvm-users] weak references

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

The patch I have sent already intergrates this technology :)


On Monday, March 29, 2010, Arno Puder <ar...@pu...> wrote:
>
>
> On 3/28/10 11:48 PM, Gergely Kis wrote:
>>     Still, I think I found a better and more elegant solution: the use
>>     of associations, which are new in 10.6 and in iPhone SDK 3.1
>>     (this shouldn't be a problem, right?)
>>
>>     Documentation can be found here:
>>     http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html
>>
>>
>> I think this is a nice, elegant solution, and we should migrate to it.
>> Personally I don't see a problem with only supporting iPhone 3.1+,  with
>> 3.2 around the corner.
>
> I agree with Gergely: this is a nice and elegant solution. I think it is
> OK to have a dependence to the iPhone SDK 3.2. Let's just hope it will
> work properly in the final release of 3.2.
>
> Arno
>
> ------------------------------------------------------------------------------
> Download Intel&#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
>

-- 
Panayotis Katsaloulis

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

[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] weak references

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

On 3/28/10 11:48 PM, Gergely Kis wrote:
>     Still, I think I found a better and more elegant solution: the use
>     of associations, which are new in 10.6 and in iPhone SDK 3.1
>     (this shouldn't be a problem, right?)
>
>     Documentation can be found here:
>     http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html
>
>
> I think this is a nice, elegant solution, and we should migrate to it.
> Personally I don't see a problem with only supporting iPhone 3.1+,  with
> 3.2 around the corner.

I agree with Gergely: this is a nice and elegant solution. I think it is 
OK to have a dependence to the iPhone SDK 3.2. Let's just hope it will 
work properly in the final release of 3.2.

Arno

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

Re: [xmlvm-users] weak references

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

Hi,

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

>
> On 26 Μαρ 2010, at 8:07 μ.μ., Gergely Kis wrote:
>
> > Actually we did something very similar with the "synchronized"
> implementation.
> > We needed to store locks for each method somewhere, and created something
> called "XMLVMRegistry" which stores the locks for each object that uses
> them.
>
>
> I am trying to have a look at it, but I can't find it.
> Is it possible to tell me where it is?
> From what you describe though, it looks like we have implemented the same
> thing.
>
http://xmlvm-reviews.appspot.com/18002/patch/1/33


>
> Still, I think I found a better and more elegant solution: the use of
> associations, which are new in 10.6 and in iPhone SDK 3.1
> (this shouldn't be a problem, right?)
>
> Documentation can be found here:
>
> http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html


I think this is a nice, elegant solution, and we should migrate to it.
Personally I don't see a problem with only supporting iPhone 3.1+,  with 3.2
around the corner.



>
>
> The only problem is that this framework is missing from the emulator!
>
So the code does not even compile for the emulator? Maybe then we should
create a very simple dummy implementation.

Did you check with the 3.2 beta SDK? Maybe this will all go away when we
upgrade to it.



> Since we are going to use it only in one specific location (retaining an
> object when is given as a delegate for example),  and since emulator does
> not suffer from strict memory problems, I believe up to the day this bug
> will be fixed in the simulation (there is already a bug report for that) we
> can "ignore" this memory leak under simulator, since it works fine in
> iPhone.
>

> What do you think?
>
I think we should not reinvent wheels, which are already in the platform.
Maybe we could introduce a few generic macros to make the code more
readable. The use of macros also enables those who have to support older
SDKs to replace it with their own implementations.

Best Regards,
Gergely

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

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

[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

[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

[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

[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

[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

[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] weak references

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

On 26 Μαρ 2010, at 8:07 μ.μ., Gergely Kis wrote:

> Actually we did something very similar with the "synchronized" implementation. 
> We needed to store locks for each method somewhere, and created something called "XMLVMRegistry" which stores the locks for each object that uses them.


I am trying to have a look at it, but I can't find it.
Is it possible to tell me where it is?
From what you describe though, it looks like we have implemented the same thing.

Still, I think I found a better and more elegant solution: the use of associations, which are new in 10.6 and in iPhone SDK 3.1
(this shouldn't be a problem, right?)

Documentation can be found here:
http://17.254.2.129/iphone/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html

The only problem is that this framework is missing from the emulator!
Since we are going to use it only in one specific location (retaining an object when is given as a delegate for example),  and since emulator does not suffer from strict memory problems, I believe up to the day this bug will be fixed in the simulation (there is already a bug report for that) we can "ignore" this memory leak under simulator, since it works fine in iPhone.

What do you think?