Unknown selector and garbage collection

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Unknown selector and garbage collection

rnendel
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

Jackson Harper

I agree that this is a problem. But its not the garbage collector, it is just doing its job.  The problem is, that many of the APIs that you would expect to hold a managed ref to your objects do not. To do things in a ".NETy" kind of way, I would expect something like:

PushViewController (new MyController ()) to hold a reference to the new MyController

Jackson


On Sun, Jan 15, 2012 at 5:23 PM, rnendel <[hidden email]> wrote:
This is going to sound negative, but for all of us Monotouch enthusiasts,
please read between the lines at the heart of the issue and not just read it
as "flaming" - for monotouch developers, please just read.
-------
The changes to the garbage collector have got to get fixed.  Getting tired
of chasing <unrecognized selector sent to instance> exceptions.  Not all
variables can be declared and/or initialized at class scope (that seems to
be the "quick fix" given out for the problem, but really doesn't solve much)
and I have seen zero productive feedback to anyone reporting the issue
(which many have).

Part of the c# pattern is a reliable garbage collector that behaves in a
predictable manner.  The use of lambda expressions and a reliance on
predictable behavior based on reference count is a key part of what c# is
all about.  Requiring variables to be declared at class scope, or allowing
these exceptions to continue with "quick fix" suggestions really doesn't
help much - we're talking about "core language functionality" here, not
optional features.

The attractiveness of c# over objective C is NOT just the language
semantics/framework, but also the behavior of the backend components, such
as a reliable garbage collector.  This is c# not a "kinda c# hack" right?
The objective of MT is a "quicker learning curve" by removing the
Objective-C component.  However, if the development pattern must change (and
take more time tracking down bugs) because of faulty behavior, then the
"value add" of MT is greatly reduced.

So, please, do something about this or many people coming from stable c#
elsewhere will start to believe that learning Objective-C really isn't such
a bad thing after all.  MT is designed to attract existing c# developers,
but if the MT c# implementation and run-time behavior does not match or come
close to what c# developers would expect will they have a "positive"
experience or a negative one.
--------
Again, to all those who would respond as MT enthusiasts - believe me, I can
imagine what you'll say, so please don't trash up the thread with flame @
me, or whatever.  The garbage collector is a real problem right now and has
gotta get fixed.  And, no, I'm not a noob - been developing in MT for over a
year and have 20+ years professional development under my belt (mostly in
the PC/console games industry).  I simply want this solution to "work" as
expected for the language being used, as do we all I would assume.

So, devs, please respond and let's get some information going on the garbage
collector changes.  Which of the various errors reported are *really* due to
an IOS bug and which are due to the collector.  So far it is all very vague
and no real information about a "fix" has been provided that I can tell.
I'd ask that you stop addressing specific scenarios, like "when I click my
button I get an <unrecognized selector> in the event handler" and begin
addressing the overall issue, which is the garbage collector.

Thanks.

--
View this message in context: http://monotouch.2284126.n4.nabble.com/Unknown-selector-and-garbage-collection-tp4297921p4297921.html
Sent from the MonoTouch mailing list archive at Nabble.com.
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch


_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

rnendel
In reply to this post by rnendel
Ugh, accidental deletion (by me) -

Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

rnendel
In reply to this post by Jackson Harper
IMHO, there is more than one issue around this, and various scenarios that have involved some known IOS issues, which clouds the problem.  I agree with the reference expectations and that some objects simply don't carry it.  However, there are plenty of <unrecognized selector> errors that the devs have responded to that involved "class level declarations" as being the solution due to the aggression changes made to the GC.
Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

Nic Wise
For my 2c, I've seen this as a problem that other people have had -
not something I've had in my own code. (so far). So maybe it's
something I'm (not?) doing...

Like any development, there has to be trade offs. Look at the full
framework on Windows, for example. There are 2 versions (server and
client) which have very, VERY different GC profiles: the client GC's
quickly and often to keep memory usage down, the server does it very
infrequently to keep performance up, but is expected to have a lot of
RAM to work in. .NET Compact Framework was** closer to MonoTouch, tho
MSFT had control over more parts of it.

So I would expect something even more different to those on a mobile
device which has very limited resources. If we had the windows server
CLR's GC model on a mobile device, none of us would actually be doing
anything - our apps would just crash with out of memory errors, and
hello world would ship as a 20meg+ binary. Or the app would pause for
ages while it GC'ed, which would be even worse.

For me, thats part of the process of learning mobile development: how
the whole system works, in the same way I don't expect (or want to)
use windows forms or WPF on the phone*, I expect to have to adapt to
the constraints of the platform and environment. Lack of resources and
an agressive GC are two of those constraints.

(Maybe this stemmed out of learning .NET using the Compact Framework.
Even when I'm doing server stuff (my day job), I'm still thinking
about where objects are stored and released, leaks, excessive object
creation etc)

Clearly, this (GCing) is a problem for you and others, or you wouldn't
have written this. From my perspective, this is a trade off for being
able to use C# - a language I like a lot - on the iPhone - a platform
I like a lot, and one I'm willing to work with or around. It does need
addressing by Xamarin, but (IMO) it might be more of a documentation /
education thing than a code change. Or more likely, both.

* ok, maybe silverlight and a form a declarative UI constructions....
maybe. Thats kinda what IB is...

** I've not used it since v1 and 1.1, so that might have changed a bit



On Sun, Jan 15, 2012 at 23:02, rnendel <[hidden email]> wrote:

> IMHO, there is more than one issue around this, and various scenarios that
> have involved some known IOS issues, which clouds the problem.  I agree with
> the reference expectations and that some objects simply don't carry it.
> However, there are plenty of <unrecognized selector> errors that the devs
> have responded to that involved "class level declarations" as being the
> solution due to the aggression changes made to the GC.
>
> --
> View this message in context: http://monotouch.2284126.n4.nabble.com/Unknown-selector-and-garbage-collection-tp4297921p4297989.html
> Sent from the MonoTouch mailing list archive at Nabble.com.
> _______________________________________________
> MonoTouch mailing list
> [hidden email]
> http://lists.ximian.com/mailman/listinfo/monotouch



--
Nic Wise
t.  +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/

Nearest Bus: find when the next bus is coming to your stop. http://goo.gl/Vcz1p
mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
London Bike App: Find the nearest Boris Bike, and get riding! http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

René Ruppert
In reply to this post by Jackson Harper
Exactly your example of pushing a new controller DOES to my experience and knowledge keep a reference. No need for a class reference. In fact in most situations the reference is kept (where possible) and if not, it is a bug in Monotouch. That's how it was explained to me by Sebastien and Rolf. 



Grüße, René

Am 15.01.2012 um 23:54 schrieb Jackson Harper <[hidden email]>:


I agree that this is a problem. But its not the garbage collector, it is just doing its job.  The problem is, that many of the APIs that you would expect to hold a managed ref to your objects do not. To do things in a ".NETy" kind of way, I would expect something like:

PushViewController (new MyController ()) to hold a reference to the new MyController

Jackson


On Sun, Jan 15, 2012 at 5:23 PM, rnendel <[hidden email]> wrote:
This is going to sound negative, but for all of us Monotouch enthusiasts,
please read between the lines at the heart of the issue and not just read it
as "flaming" - for monotouch developers, please just read.
-------
The changes to the garbage collector have got to get fixed.  Getting tired
of chasing <unrecognized selector sent to instance> exceptions.  Not all
variables can be declared and/or initialized at class scope (that seems to
be the "quick fix" given out for the problem, but really doesn't solve much)
and I have seen zero productive feedback to anyone reporting the issue
(which many have).

Part of the c# pattern is a reliable garbage collector that behaves in a
predictable manner.  The use of lambda expressions and a reliance on
predictable behavior based on reference count is a key part of what c# is
all about.  Requiring variables to be declared at class scope, or allowing
these exceptions to continue with "quick fix" suggestions really doesn't
help much - we're talking about "core language functionality" here, not
optional features.

The attractiveness of c# over objective C is NOT just the language
semantics/framework, but also the behavior of the backend components, such
as a reliable garbage collector.  This is c# not a "kinda c# hack" right?
The objective of MT is a "quicker learning curve" by removing the
Objective-C component.  However, if the development pattern must change (and
take more time tracking down bugs) because of faulty behavior, then the
"value add" of MT is greatly reduced.

So, please, do something about this or many people coming from stable c#
elsewhere will start to believe that learning Objective-C really isn't such
a bad thing after all.  MT is designed to attract existing c# developers,
but if the MT c# implementation and run-time behavior does not match or come
close to what c# developers would expect will they have a "positive"
experience or a negative one.
--------
Again, to all those who would respond as MT enthusiasts - believe me, I can
imagine what you'll say, so please don't trash up the thread with flame @
me, or whatever.  The garbage collector is a real problem right now and has
gotta get fixed.  And, no, I'm not a noob - been developing in MT for over a
year and have 20+ years professional development under my belt (mostly in
the PC/console games industry).  I simply want this solution to "work" as
expected for the language being used, as do we all I would assume.

So, devs, please respond and let's get some information going on the garbage
collector changes.  Which of the various errors reported are *really* due to
an IOS bug and which are due to the collector.  So far it is all very vague
and no real information about a "fix" has been provided that I can tell.
I'd ask that you stop addressing specific scenarios, like "when I click my
button I get an <unrecognized selector> in the event handler" and begin
addressing the overall issue, which is the garbage collector.

Thanks.

--
View this message in context: http://monotouch.2284126.n4.nabble.com/Unknown-selector-and-garbage-collection-tp4297921p4297921.html
Sent from the MonoTouch mailing list archive at Nabble.com.
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch

_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch

_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

Rolf Bjarne Kvinge
In reply to this post by rnendel
Hi,

We do know about this problem and we've tried to come up with at least a partial solution, which will be included in MonoTouch 5.2 when it comes out. I can't say much about it right now (partially because it's quite a complex topic, and I wasn't the one adding this new support), but it is designed to improve this situation a lot. If you download the latest beta (5.1.1) you can try it out already (enable sgen and add --new-refcount to mtouch additional arguments). Documentation about exactly what it fixes (and what it doesn't) is being written, and should be done when 5.2 is released.

Unfortunately it is impossible to fix this problem 100% (which would be to never crash due to objects being freed, while at the same time not leak any objects, no matter what C# code you wrote), because of the differences between the managed world and the underlying iOS world. The GC will still need some help from the developer, but hopefully we've been able to reduce those cases a lot.

Rolf

On Sun, Jan 15, 2012 at 11:23 PM, rnendel <[hidden email]> wrote:
This is going to sound negative, but for all of us Monotouch enthusiasts,
please read between the lines at the heart of the issue and not just read it
as "flaming" - for monotouch developers, please just read.
-------
The changes to the garbage collector have got to get fixed.  Getting tired
of chasing <unrecognized selector sent to instance> exceptions.  Not all
variables can be declared and/or initialized at class scope (that seems to
be the "quick fix" given out for the problem, but really doesn't solve much)
and I have seen zero productive feedback to anyone reporting the issue
(which many have).

Part of the c# pattern is a reliable garbage collector that behaves in a
predictable manner.  The use of lambda expressions and a reliance on
predictable behavior based on reference count is a key part of what c# is
all about.  Requiring variables to be declared at class scope, or allowing
these exceptions to continue with "quick fix" suggestions really doesn't
help much - we're talking about "core language functionality" here, not
optional features.

The attractiveness of c# over objective C is NOT just the language
semantics/framework, but also the behavior of the backend components, such
as a reliable garbage collector.  This is c# not a "kinda c# hack" right?
The objective of MT is a "quicker learning curve" by removing the
Objective-C component.  However, if the development pattern must change (and
take more time tracking down bugs) because of faulty behavior, then the
"value add" of MT is greatly reduced.

So, please, do something about this or many people coming from stable c#
elsewhere will start to believe that learning Objective-C really isn't such
a bad thing after all.  MT is designed to attract existing c# developers,
but if the MT c# implementation and run-time behavior does not match or come
close to what c# developers would expect will they have a "positive"
experience or a negative one.
--------
Again, to all those who would respond as MT enthusiasts - believe me, I can
imagine what you'll say, so please don't trash up the thread with flame @
me, or whatever.  The garbage collector is a real problem right now and has
gotta get fixed.  And, no, I'm not a noob - been developing in MT for over a
year and have 20+ years professional development under my belt (mostly in
the PC/console games industry).  I simply want this solution to "work" as
expected for the language being used, as do we all I would assume.

So, devs, please respond and let's get some information going on the garbage
collector changes.  Which of the various errors reported are *really* due to
an IOS bug and which are due to the collector.  So far it is all very vague
and no real information about a "fix" has been provided that I can tell.
I'd ask that you stop addressing specific scenarios, like "when I click my
button I get an <unrecognized selector> in the event handler" and begin
addressing the overall issue, which is the garbage collector.

Thanks.

--
View this message in context: http://monotouch.2284126.n4.nabble.com/Unknown-selector-and-garbage-collection-tp4297921p4297921.html
Sent from the MonoTouch mailing list archive at Nabble.com.
_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch


_______________________________________________
MonoTouch mailing list
[hidden email]
http://lists.ximian.com/mailman/listinfo/monotouch
Reply | Threaded
Open this post in threaded view
|

Re: Unknown selector and garbage collection

stevek
Is "--new-refcount" the same as the "Use the reference counting extension" checkbox next to the SGen checkbox in Project Options->iPhone Build?