Re: [Mono-dev] (no subject)
On Thu, 29 Mar 2007 11:28:49 -0400, Miguel de Icaza [EMAIL PROTECTED] scribbled: Hello, Please review a performance optimization for HttpRequest.Headers and HttpRequest.ServerVariables collections. It implements lazy collection fill because most common flow is to ask for value by name. Only if user ask for enumerator or count, collection will be fully loaded. This gives about 25% performance improvement on common flow. Ah, this is brilliant, I love it. I like the patch very much, too. Please commit! regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono enhancements
To the Gendarme gurus,
I don't know if the GC is smart enough to Dispose of resources for us, but I
will assume that it does not hurt to help it. There are two patterns that
Gendarme could look for.
class Foo
{
Foo()
{
IDisposable resource = new Resource();
throw new System.Exception();
resource.Dispose();
}
}
This should either be remedied with a try finally or with the using construct
which encapsulates try finally (I vote for the latter as a suggested fix).
Another related rule should be to check if resource.Dispose() is never called
anywhere in scope.
An unrelated pattern which is not too important to me:
class Foo
{
Foo()
{
System.Console.WriteLine(string.Format(hello {9}, world));
}
}
Note that I missed the zero and typed nine.
Is it possible to promote Gendarme rules to compiler errors/warnings or would
that somehow break compatibility with csc? Is it worth it if it means better
code is produced? I realize that it won't matter as much once there is a nice
Gendarme Plugin for MonoDevelop but even then, we could ask for severe flaws to
be compiler warnings at least.
Many thanks,
Vlad Giszpenc
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] missing class scrollProperties (system.windows.forms)
Hi All, I am making a winform gui for monotorrent and I see with moma that some properties are missing to make my code compile on mono. So I just code a basic structure for missing class but it is still unfinished (Monotodo attributes) because I do not know very well the internal things of mono framework. Hope It can help. If I do bad, make a feed back and I will fix my code. There are no methodes (only properties) so I have done no unit test. bye, Duff (olivier dufour) Scroll properties duff.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono enhancements
Hello Vladimir,
On Thu, 2007-03-29 at 09:42 -0400, Vladimir Giszpenc wrote:
To the Gendarme gurus,
I don't know if the GC is smart enough to Dispose of resources for us,
but I will assume that it does not hurt to help it. There are two
patterns that Gendarme could look for.
Side node: We don't lack ideas for Gendarme but time/people do implement
them ;-)
class Foo
{
Foo()
{
IDisposable resource = new Resource();
throw new System.Exception();
resource.Dispose();
}
}
This should either be remedied with a try finally or with the using
construct which encapsulates try finally (I vote for the latter as a
suggested fix).
In many cases it's hard to get a perfect rule (e.g. ensuring a Dispose
is reached in every cases) while keeping false negative to a minimum.
Note that in some cases the public Dispose can be named something else
(e.g. Close).
Here your test case is simple but, in real life, just about any code
between the ctor and the dispose can throw something (outside your
method). So a perfect rule would warn you just about every IDisposable
object you have outside a try/finally.
Another related rule should be to check if resource.Dispose() is never
called anywhere in scope.
However it's possible (and much better than nothing ;-) to have a rule
that catch most of them, with very few false positive. In this spirit it
shouldn't be hard to track, at least when the variable is local.
An unrelated pattern which is not too important to me:
class Foo
{
Foo()
{
System.Console.WriteLine(string.Format(hello {9}, world));
}
}
Note that I missed the zero and typed nine.
It's a good idea.
I'll clean up my notes and (sometime soon ;-) add a new Gendarme Ideas
page to the wiki. I'll add your suggestions there.
Is it possible to promote Gendarme rules to compiler errors/warnings
or would that somehow break compatibility with csc?
Possible ? yes
Likely ? no
Is it worth it if it means better code is produced?
Generally you'll compile *much* more often than you'll be use Gendarme.
IMO it's not worth the extra time at every compilation.
I realize that it won't matter as much once there is a nice Gendarme
Plugin for MonoDevelop
amen :)
but even then, we could ask for severe flaws to be compiler warnings
at least.
You could make a csc script that calls [g]mcs and, if successful, then
call gendarme on the output assembly.
Many thanks,
Vlad Giszpenc
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Sebastien Pouliot [EMAIL PROTECTED]
Blog: http://pages.infinit.net/ctech/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi Alan, On 3/29/07, Alan McGovern [EMAIL PROTECTED] wrote: I ran it again, and came up with this (startling ;) ) figures for allocations: 1) type=System.Runtime.Remoti...ing.MonoMethodMessage 4185 1024.1M 256603.6 0.5 System.Threading.ThreadPool:QueueUserWorkItem System.Timers.Timer:StartTimer What the hell? 1 gig of allocations from a System.Timers.Timer? Whats going on here!? Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9 resizes going from a size of 2.8 megs to 322.6 megs. On the surface it looks like a Mono bug, or possibly a bug in the amount of data you're processing through remoting. As Miguel suggested, using heap-shot at this point will be helpful in finding out what objects are allocating these and hopefully why. Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi, On 3/30/07, Miguel de Icaza [EMAIL PROTECTED] wrote: One question: how do I enable the four different profiling modes for HeapBuddy? The summary mode is the default. For the others, you just provide the relevant word on the command line. history, types, backtraces. You can also turn off the autoabbreviation by saying something like full names and change the sorting with sort by age, for example. Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] missing class scrollProperties (system.windows.forms)
Hey Olivier! Thanks for your patch! I took it and added the implementation and tests as well. It is committed in SVN as r75208. Please read up on our coding guidelines (http://www.mono-project.com/Coding_Guidelines) if you submit more stuff in the future. I fixed it all this time, but next time we won't accept it until it's up to standards. Thanks for your work! Jon [EMAIL PROTECTED] wrote: Hi All, I am making a winform gui for monotorrent and I see with moma that some properties are missing to make my code compile on mono. So I just code a basic structure for missing class but it is still unfinished (Monotodo attributes) because I do not know very well the internal things of mono framework. Hope It can help. If I do bad, make a feed back and I will fix my code. There are no methodes (only properties) so I have done no unit test. bye, Duff (olivier dufour) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi, Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9 resizes going from a size of 2.8 megs to 322.6 megs. Yup, i had noticed that ;) There is something fishy, but i can't find out what it is. I've run heap-shot and attached and emailed the results in already. Hopefully they'll make sense to someone. By the looks of it, there's some kind of problem internal to mono which is resulting in this rapid memory usage as on MS.NET this doesn't happen. There could easily be a bug in my own code and MS.NET just handles it better, but i have no idea what is causing the problem to start off with, so i can't fix it. Im not using remoting as such, I assume that internally AsyncSockets make use of the remoting framework. I do make heavy use of those, but i'm using them in the way they're supposed to be used. Any further advice would be brilliant. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi Alan, If you can run your application on Windows, check this tool which can help to find where's located memory leak: http://www.microsoft.com/downloads/details.aspx?amp;amp;displaylang=enfamilyid=9bfa49bc-376b-4a54-95aa-73c9156706e7displaylang=en. This guide can also help: http://support.microsoft.com/?scid=kb%3Ben-us%3B919790x=11y=15. From your e-mail, it seems to be those AsyncSockets not disposing as expected. Cheers, 2007/3/30, Alan McGovern [EMAIL PROTECTED]: Hi, Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9 resizes going from a size of 2.8 megs to 322.6 megs. Yup, i had noticed that ;) There is something fishy, but i can't find out what it is. I've run heap-shot and attached and emailed the results in already. Hopefully they'll make sense to someone. By the looks of it, there's some kind of problem internal to mono which is resulting in this rapid memory usage as on MS.NET this doesn't happen. There could easily be a bug in my own code and MS.NET just handles it better, but i have no idea what is causing the problem to start off with, so i can't fix it. Im not using remoting as such, I assume that internally AsyncSockets make use of the remoting framework. I do make heavy use of those, but i'm using them in the way they're supposed to be used. Any further advice would be brilliant. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Just a quick update, i think my email bounced due to the attached heap-shot data. I'm now hosting it here: http://www.megaupload.com/?d=QOJKRWT2 If theres problems with that, let me know. Alan. On 3/30/07, Marcos Cobeña Morián [EMAIL PROTECTED] wrote: Hi Alan, If you can run your application on Windows, check this tool which can help to find where's located memory leak: http://www.microsoft.com/downloads/details.aspx?amp;amp;displaylang=enfamilyid=9bfa49bc-376b-4a54-95aa-73c9156706e7displaylang=en . This guide can also help: http://support.microsoft.com/?scid=kb%3Ben-us%3B919790x=11y=15. From your e-mail, it seems to be those AsyncSockets not disposing as expected. Cheers, 2007/3/30, Alan McGovern [EMAIL PROTECTED]: Hi, Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9 resizes going from a size of 2.8 megs to 322.6 megs. Yup, i had noticed that ;) There is something fishy, but i can't find out what it is. I've run heap-shot and attached and emailed the results in already. Hopefully they'll make sense to someone. By the looks of it, there's some kind of problem internal to mono which is resulting in this rapid memory usage as on MS.NET this doesn't happen. There could easily be a bug in my own code and MS.NET just handles it better, but i have no idea what is causing the problem to start off with, so i can't fix it. Im not using remoting as such, I assume that internally AsyncSockets make use of the remoting framework. I do make heavy use of those, but i'm using them in the way they're supposed to be used. Any further advice would be brilliant. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
From your e-mail, it seems to be those AsyncSockets not disposing as expected Even if i wasn't disposing of them at all, i connect to at most 5 people a second, so that's at most 5 sockets being created a second. There's no way that they would lead to such a huge allocation rate. Also, i can monitor the number of ports/handles i have open and when memory usage rockets, they remain stable. So that should indicate that it isn't run-away creation of sockets. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi, I gave that a shot, but i can't actually make use of it :( The problem is that the memory usage goes from 20 megabytes to 2 gigabytes in the space of 2 seconds. I can't get a snapshot of anywhere in between and once memory usage rockets up there, i can't take a snapshot using the tool. So once again, i'm at a loss. Alan On 3/30/07, Marcos Cobeña Morián [EMAIL PROTECTED] wrote: Hi Alan, If you can run your application on Windows, check this tool which can help to find where's located memory leak: http://www.microsoft.com/downloads/details.aspx?amp;amp;displaylang=enfamilyid=9bfa49bc-376b-4a54-95aa-73c9156706e7displaylang=en . This guide can also help: http://support.microsoft.com/?scid=kb%3Ben-us%3B919790x=11y=15. From your e-mail, it seems to be those AsyncSockets not disposing as expected. Cheers, 2007/3/30, Alan McGovern [EMAIL PROTECTED]: Hi, Yep, that's your problem right there. ;) Also, if you look at the summary you posted, you'll notice that in the course of 1 second, you have 9 resizes going from a size of 2.8 megs to 322.6 megs. Yup, i had noticed that ;) There is something fishy, but i can't find out what it is. I've run heap-shot and attached and emailed the results in already. Hopefully they'll make sense to someone. By the looks of it, there's some kind of problem internal to mono which is resulting in this rapid memory usage as on MS.NET this doesn't happen. There could easily be a bug in my own code and MS.NET just handles it better, but i have no idea what is causing the problem to start off with, so i can't fix it. Im not using remoting as such, I assume that internally AsyncSockets make use of the remoting framework. I do make heavy use of those, but i'm using them in the way they're supposed to be used. Any further advice would be brilliant. Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Marcos - http://www.youcannoteatbits.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hey, On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote: Yup, i had noticed that ;) There is something fishy, but i can't find out what it is. I've run heap-shot and attached and emailed the results in already. Hopefully they'll make sense to someone. By the looks of it, there's some kind of problem internal to mono which is resulting in this rapid memory usage as on MS.NET this doesn't happen. There could easily be a bug in my own code and MS.NET just handles it better, but i have no idea what is causing the problem to start off with, so i can't fix it. I just took a look at your heap-shot files, and it's a little odd. Specifically in Second Run/outfile_1.omap: object[] is the obvious problem. 367 instances, 490 megs, average size: 1.3 megs. You have to drill down in the inverse references to find specifically the big consumer: object[] - System.Collections.Queue - System.Net.Sockets.Socket - System.Net.Sockets.Socket/SocketAsyncResult - object[]. It has 35 instances taking 373 megs, with an average of 10.6 megs each. That huge object array, in turn, is referenced by System.Collections.Queue - System.Net.Socket.Socket, specifically the readQ member. So basically it means that the readQ member in System.Net.Socket.Socket is a huge Queue, which internally has an object array, which apparently has millions of SocketAsyncResult objects inside. So how those are being allocated? These objects are created a lot, but the ones that create them and enqueue them into readQ are BeginReceive() and BeginReceiveFrom(). That queue is dequeued inside the Complete() method. I don't know much about the Socket class and how the async IO works, but it boils down to the fact that BeginReceive() is being called probably millions of times, but it doesn't look like Complete() is being called enough (or possibly at all) to balance the load. Hope this helps, Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Porting runtime - where to start?
I'm trying to port the mono runtime to a device called a Wii. Although it has a PowerPC based CPU, I think getting it running with the interpreter first would be the best approach rather than attempting to patch up the existing PowerPC JIT, but I can not seem to find any documentation that would describe how to begin fixing up the build system so that I can compile it with the Wii's build tools (which are not gcc based). Any ideas on where to start? Thanks! John ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi again, On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote: That huge object array, in turn, is referenced by System.Collections.Queue - System.Net.Socket.Socket, specifically the readQ member. So basically it means that the readQ member in System.Net.Socket.Socket is a huge Queue, which internally has an object array, which apparently has millions of SocketAsyncResult objects inside. So how those are being allocated? These objects are created a lot[...] I got a little ahead of myself here: I'm obviously looking at the code for System.Net.Sockets.Socket here. I don't know much about the Socket class and how the async IO works, but it boils down to the fact that BeginReceive() is being called probably millions of times, but it doesn't look like Complete() is being called enough (or possibly at all) to balance the load. I actually noticed something else: The object array in question has an average size of 10.6 megs, but it only holds 56 references to SocketAsyncResult at the time of this snapshot. So this seems to indicate to me that the enqueues and dequeues do ultimately match up, but that the allocation pattern is bad and probably not interspersed. That is, enqueue, enqueue, dequeue, dequeue, enqueue, enqueue, etc. would mean that an array could be as small as 2 items and still work for N items, assuming a 1:1 match.. But if the pattern is instead, enqueue, enqueue, enqueue, enqueue, dequeue, dequeue, etc. then it would have to be at least N. Now pretend N is a million. :) Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
AFAIK, the interpreter was discontinued. :) On 3/30/07, John Matzen [EMAIL PROTECTED] wrote: I'm trying to port the mono runtime to a device called a Wii. Although it has a PowerPC based CPU, I think getting it running with the interpreter first would be the best approach rather than attempting to patch up the existing PowerPC JIT, but I can not seem to find any documentation that would describe how to begin fixing up the build system so that I can compile it with the Wii's build tools (which are not gcc based). Any ideas on where to start? Thanks! John ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Hello, I'm trying to port the mono runtime to a device called a Wii. Although it has a PowerPC based CPU, I think getting it running with the interpreter first would be the best approach rather than attempting to patch up the existing PowerPC JIT, but I can not seem to find any documentation that would describe how to begin fixing up the build system so that I can compile it with the Wii's build tools (which are not gcc based). Any ideas on where to start? I strongly suggest that you go directly to the JIT. Because the difficulty in porting Mono to the Wii will be the OS, not the CPU. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Miguel de Icaza wrote: Hello, I'm trying to port the mono runtime to a device called a Wii. Although it has a PowerPC based CPU, I think getting it running with the interpreter first would be the best approach rather than attempting to patch up the existing PowerPC JIT, but I can not seem to find any documentation that would describe how to begin fixing up the build system so that I can compile it with the Wii's build tools (which are not gcc based). Any ideas on where to start? I strongly suggest that you go directly to the JIT. Because the difficulty in porting Mono to the Wii will be the OS, not the CPU. Besides it is probably more reasonable to get linux running on the wii (and somewhere on the road also mono) than just try to figure out the os stuff Nintendo was brewing... www.wiili.org ym2c ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Just to let you know since I did something very similiar for XBOX360 : Even if I was able to make glib and then mono compile on XBOX360 (it was a bit painful but doable) and it generated valid code to execute at runtime, nevertheless memory protection against execution of user allocated area totally prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). When I checked about using the interpreter, I've read somewhere that it wasn't up to date anymore (maybe the info was too old and it's now up to date to execute everything, anyone can confirm ?). So, before going on, check that either the console can run unsigned code loaded in memory (which I doubt since they tend to avoid that, since it would quickly run into hacking of the console) or that mono interpreter is now working again. Hope that helps, do not hesitate if you would like some other infos. Cordially, Virgile Quoting John Matzen [EMAIL PROTECTED]: I'm trying to port the mono runtime to a device called a Wii. Although it has a PowerPC based CPU, I think getting it running with the interpreter first would be the best approach rather than attempting to patch up the existing PowerPC JIT, but I can not seem to find any documentation that would describe how to begin fixing up the build system so that I can compile it with the Wii's build tools (which are not gcc based). Any ideas on where to start? Thanks! John ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Hello, When I checked about using the interpreter, I've read somewhere that it wasn't up to date anymore (maybe the info was too old and it's now up to date to execute everything, anyone can confirm ?). It still builds, but no maintenance has gone into it. It is also missing important things like generics support, that was never updated. But the main problem you have with the interpreter is that the interpreter *also* needs to generate dynamic code. All the trampoline code is emitted at runtime so you need to have that. So in short: the interpreter just generates *less* code than the JIT, but it still generates code. I heard from an embedded customer of ours that they are looking at pregenerating all the trampoline code but am not sure this is a long term strategy. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Hello, prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). I read somewhere that some of those restrictions were being lifted, am I incorrect? Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Porting runtime - where to start?
Hello, Just to let you know since I did something very similiar for XBOX360 : Even if I was able to make glib and then mono compile on XBOX360 (it was a bit painful but doable) and it generated valid code to execute at runtime, nevertheless memory protection against execution of user allocated area totally prevented me to continue (you can check the blog post I did about that on http://dev.kalimdor.org/entropia/). Another thing that am wondering is whether precompilation (AOT) might be enough to use Mono on those consoles. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi, That leaves me with the question of how the hell a SocketAsyncResult is 10 megs in size! The size of the largest single object in my entire code is a 16kB byte[] buffer. If each SocketAsyncResult is 10 megabytes in size, i have to question the internal workings of mono, as i know from profiling my own code does *not* create objects anywhere near that size. I'm going to do a bit of profiling to count how many socket BeginXXX calls are made from my own code as compared to the EndXXX calls to see how they match up. Is there any way of finding out what exactly is inside those SocketAsyncResults that is 10 megs in size? I can verify that the exact same code running under Mono 1.2 and earlier does *not* exhibit the same behavior, everything works fine. I only came across this bug after updating my mono installation to 1.2.3. This is why i think it's a mono bug, however i can't reproduce the problem in the form of an NUnit test. Thanks again, Alan. On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote: Hi again, On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote: That huge object array, in turn, is referenced by System.Collections.Queue - System.Net.Socket.Socket, specifically the readQ member. So basically it means that the readQ member in System.Net.Socket.Socket is a huge Queue, which internally has an object array, which apparently has millions of SocketAsyncResult objects inside. So how those are being allocated? These objects are created a lot[...] I got a little ahead of myself here: I'm obviously looking at the code for System.Net.Sockets.Socket here. I don't know much about the Socket class and how the async IO works, but it boils down to the fact that BeginReceive() is being called probably millions of times, but it doesn't look like Complete() is being called enough (or possibly at all) to balance the load. I actually noticed something else: The object array in question has an average size of 10.6 megs, but it only holds 56 references to SocketAsyncResult at the time of this snapshot. So this seems to indicate to me that the enqueues and dequeues do ultimately match up, but that the allocation pattern is bad and probably not interspersed. That is, enqueue, enqueue, dequeue, dequeue, enqueue, enqueue, etc. would mean that an array could be as small as 2 items and still work for N items, assuming a 1:1 match.. But if the pattern is instead, enqueue, enqueue, enqueue, enqueue, dequeue, dequeue, etc. then it would have to be at least N. Now pretend N is a million. :) Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Hi, On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote: That leaves me with the question of how the hell a SocketAsyncResult is 10 megs in size! It's not the SocketAsyncResult itself that's 10 megs in size, it's the object array that holds them that is 10 megs in size. I'm going to do a bit of profiling to count how many socket BeginXXX calls are made from my own code as compared to the EndXXX calls to see how they match up. I think this is a good idea, and if that doesn't work out, I would use Mono's tracing facility to see how often the methods I mentioned in my last email were being called and in what order. And if that doesn't work, instrument the class libs themselves. I can verify that the exact same code running under Mono 1.2 and earlier does *not* exhibit the same behavior, everything works fine. I only came across this bug after updating my mono installation to 1.2.3. This is why i think it's a mono bug, however i can't reproduce the problem in the form of an NUnit test. It's probably in the sockets code, so take a diff of System.Net.Sockets.Socket between 1.2 and 1.2.3 and see what, if anything changed. If you can narrow it down to a specific change between the releases, that will hopefully make it easier to write a test case. Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need help tracking this bug...
Ok, i did a quick bit of testing on my code. Firstly, the 54 instances of SocketAsyncResult do make sense. Typically there will *always* be a pending BeginReceive on every socket i have opened. Therefore 54 instances of SocketAsyncResult would correspond to 54 open connections, which is pretty standard stuff. Every call to socket.BeginXXX or socket.EndXXX goes through a TCPConnection class, so i added a count there so i could see how many calls to each BeginXXX and EndXXX method i actually make. The results were pretty much as expected. There was always a difference between BeginReceive and EndReceive pretty much equal to the number of sockets i have open. The difference between BeginSend and EndSend was always close enough to zero, which would also make sense as most messages i'm sending would only be a few bytes in size. The difference between the BeginConnects and EndConnects is always 5. This is right as i've set it so i only connect to at most 5 people at any one instant. So i can rule out a bug in my code that's causing millions of BeginXXX's without corresponding EndXXX's. There'd typically be between 80 and 120 Begin/EndReceive calls a second, which isn't that much really. A similar amount for Begin/EndSend. On 3/31/07, Alan McGovern [EMAIL PROTECTED] wrote: Hi, That leaves me with the question of how the hell a SocketAsyncResult is 10 megs in size! The size of the largest single object in my entire code is a 16kB byte[] buffer. If each SocketAsyncResult is 10 megabytes in size, i have to question the internal workings of mono, as i know from profiling my own code does *not* create objects anywhere near that size. I'm going to do a bit of profiling to count how many socket BeginXXX calls are made from my own code as compared to the EndXXX calls to see how they match up. Is there any way of finding out what exactly is inside those SocketAsyncResults that is 10 megs in size? I can verify that the exact same code running under Mono 1.2 and earlier does *not* exhibit the same behavior, everything works fine. I only came across this bug after updating my mono installation to 1.2.3. This is why i think it's a mono bug, however i can't reproduce the problem in the form of an NUnit test. Thanks again, Alan. On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote: Hi again, On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote: That huge object array, in turn, is referenced by System.Collections.Queue - System.Net.Socket.Socket , specifically the readQ member. So basically it means that the readQ member in System.Net.Socket.Socket is a huge Queue, which internally has an object array, which apparently has millions of SocketAsyncResult objects inside. So how those are being allocated? These objects are created a lot[...] I got a little ahead of myself here: I'm obviously looking at the code for System.Net.Sockets.Socket here. I don't know much about the Socket class and how the async IO works, but it boils down to the fact that BeginReceive() is being called probably millions of times, but it doesn't look like Complete() is being called enough (or possibly at all) to balance the load. I actually noticed something else: The object array in question has an average size of 10.6 megs, but it only holds 56 references to SocketAsyncResult at the time of this snapshot. So this seems to indicate to me that the enqueues and dequeues do ultimately match up, but that the allocation pattern is bad and probably not interspersed. That is, enqueue, enqueue, dequeue, dequeue, enqueue, enqueue, etc. would mean that an array could be as small as 2 items and still work for N items, assuming a 1:1 match.. But if the pattern is instead, enqueue, enqueue, enqueue, enqueue, dequeue, dequeue, etc. then it would have to be at least N. Now pretend N is a million. :) Joe ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Build broken?
I've been trying to compile SVN head on both windows and MacOS and it fails on both. Is this a problem on just my side, or is compilation actually broken? I've attached the last 100 or so lines of output when trying to build on Mac OS X. If anyone has any ideas, let me know. Thanks, Alan. gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono 6.6\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -g -O2 -MT pthread_support.lo -MD -MP -MF .deps/pthread_support.Tpo -c pthread_support.c -o pthread_support.o /dev/null 21 if /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono\ 6.6\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -g -O2 -MT pthread_stop_world.lo -MD -MP -MF .deps/pthread_stop_world.Tpo -c -o pthread_stop_world.lo pthread_stop_world.c; \ then mv -f .deps/pthread_stop_world.Tpo .deps/pthread_stop_world.Plo; else rm -f .deps/pthread_stop_world.Tpo; exit 1; fi gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono 6.6\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -g -O2 -MT pthread_stop_world.lo -MD -MP -MF .deps/pthread_stop_world.Tpo -c pthread_stop_world.c -fno-common -DPIC -o .libs/pthread_stop_world.o In file included from ./include/private/gc_priv.h:66, from ./include/private/pthread_support.h:4, from pthread_stop_world.c:1: ./include/private/gcconfig.h:316:1: warning: USE_MMAP redefined command line:1:1: warning: this is the location of the previous definition gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono 6.6\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -g -O2 -MT pthread_stop_world.lo -MD -MP -MF .deps/pthread_stop_world.Tpo -c pthread_stop_world.c -o pthread_stop_world.o /dev/null 21 if /bin/sh ./libtool --mode=compile gcc -DPACKAGE_NAME=\libgc-mono\ -DPACKAGE_TARNAME=\libgc-mono\ -DPACKAGE_VERSION=\6.6\ -DPACKAGE_STRING=\libgc-mono\ 6.6\ -DPACKAGE_BUGREPORT=\[EMAIL PROTECTED] -DGC_DARWIN_THREADS=1 -DTHREAD_LOCAL_ALLOC=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -D_IN_LIBGC=1 -I./.. -I./.. -I./include -no-cpp-precomp -D_THREAD_SAFE -DGC_MACOSX_THREADS -DPLATFORM_MACOSX -DUSE_MMAP -DUSE_MUNMAP -DGetCurrentProcess=MonoGetCurrentProcess -g -O2 -MT darwin_stop_world.lo -MD -MP -MF .deps/darwin_stop_world.Tpo -c -o darwin_stop_world.lo darwin_stop_world.c; \ then mv -f .deps/darwin_stop_world.Tpo
Re: [Mono-dev] Build broken?
On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote: I've been trying to compile SVN head on both windows and MacOS and it fails on both. Is this a problem on just my side, or is compilation actually broken? I've attached the last 100 or so lines of output when trying to build on Mac OS X. If anyone has any ideas, let me know. Works fine for me in Linux, have you tried making dist clean and running autogen? Thanks, Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
