Re: [Mono-dev] Monoco, couroutines and Mono.
Hi, On Thu, 16 Apr 2009, Miguel de Icaza wrote: Hello, However, I grant everyone rights to do anything they want with my microthreading code, so please host them on Mono's repository if you think it'll help people. One last thing: what license is the code under? Would you be willing to license it as MIT X11? Sorry it took so long. MIT X11 is ok to me, I've updated the source package at http://www.bat.org/~tomba/monoco-20090429.tar.gz to include MIT X11 license. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Hi, On Tue, 14 Apr 2009, James Mansion wrote: Tomi Valkeinen wrote: And I'm still of the opinnion that this stack-copying is more of an interesting hack, than something people should really use =). Is there a real cast-in-stone reason why a VM engine has to have a contiguous stack at the point where a hardware thread calls into the coroutine scheduler and is scheduled onto a coroutine? I think you mean OS thread. The coroutines are nothing special, they are similar to any other jitted code that mono produces. And thus the stack has to be the normal continuous OS stack. I believe it could be possible to rewrite the whole jit code generation to produce code that doesn't use stack but position independent frames, and then these frames could be used to create much faster continuations without any copying (like stackless python). But this would mean that the frame could not grow dynamically, and I bet there are other limitations which makes this solution not compatible with how CLI is supposed to work. And it would be a huge job =). Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Hi, On Wed, 15 Apr 2009, James Mansion wrote: Tomi Valkeinen wrote: I think you mean OS thread. The coroutines are nothing special, they are similar to any other jitted code that mono produces. Well, except that the core has some knowledge of them now, right? Well, some, of course. But a continuation is just a piece of stack, stored somewhere. The jitted code itself is the same as normally. And thus the stack has to be the normal continuous OS stack. Thus? Why? You probably need to pin stack areas, but why can't you malloc (or mmap) some new space and place a stack in it? I think you'll find that Steve Dekorte's libcoro does that. If you are prepared to forgo guard pages and the like (or roll your own handler) then I don't see why the stack pointer absolutely has to be where you expect. And in fact the gubbins that normally gets pushed to the main CPU stack can get pushed to a fully software stack anyway, just as you do on RISC systems with no push/pop abstraction. The stack pointer is just a pointer, after all. The stack must be able to grow, otherwise we may run out of stack. If we want to manage a proper stack for each continuation, we need to allocate it in page sized chunks, and we need the guard pages. This would increase the required memory needed for each continuation quite a bit. Also, the stack contains pointers to variables in the stack, so the stack has to be in the same memory location. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Monoco, couroutines and Mono.
Hi, On Thu, 9 Apr 2009, Miguel de Icaza wrote: Hello folks, We were having this discussion a few months ago: But remember that stackless python is, I think, more or less proper implementation while Monoco is basically just a hack. As of this week a variation of Mono.Microthreads.Continuation has been included with Mono in the Mono.Tasklets assembly. I wrote a blog entry Nice. I quickly looked at the code, looks like you (or Paolo?) quite much rewrote the whole thing =). Does the new implementation suffer from the same crasher problems as the previous one, like managed-native-managed transitions in stored stack, or restoring continuation above the mark? about this here: http://tirania.org/blog/archive/2009/Apr-09.html I took the liberty of porting Tomi's code to use this assembly and uploaded the port here: http://tirania.org/tmp/monoco-tasklets.tar.gz Tomi, I was wondering if you would mind hosting the source code on Mono's repository on its own top-level module to encourage developers to extend the work that you did. I don't know... I haven't touched the continuation stuff for a couple of years now, and I've been very busy with linux kernel development. I believe hosting here means some kind of maintenance burden, so I think I'll have to say no thank you. However, I grant everyone rights to do anything they want with my microthreading code, so please host them on Mono's repository if you think it'll help people. And I'm still of the opinnion that this stack-copying is more of an interesting hack, than something people should really use =). Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Coroutines, Monoco, and why we love them.
Hi, I though monoco was already gone and forgotten, but it seems I was mistaken =). On Fri, 21 Nov 2008, Lucas Meijer wrote: Hi, At the Unite conference, I was delighted to meet up with Miguel, as that would let me underline the parts of mono (existing or nonexisting) that are very important to our mono using projects. He asked me if I could write a message to mono-dev explaining not only privately why these things are important to us. We're working on a multiplayer MMO game. The backend is written in c# running on mono, the client uses Unity3D, whose scripting is powered by mono. Eariler in the project the plan was to write the backend in Stackless Python, because of its coroutines support. I was thrilled to find Tomi Valkeinen's MonoCo. (http://www.bat.org/~tomba/monoco.html) (Thanks Tomi!). MonoCo brings stackless style coroutines to mono, and this made us switch to mono. But remember that stackless python is, I think, more or less proper implementation while Monoco is basically just a hack. snip Please realize I'm not saying that the current implementation of MonoCo is good (or bad). I'm just looking at it from a user's point of view. I know next to nothing about the internals of the VM. I think Monoco implementation is interesting in hacking sense, but it not what I would call a proper one. It is also inefficient with long call chains, which is bad. But I know what you mean, I would love to have real microthreads in Mono. I think microthreads are very powerfull and make many things much easier to code. Bye, Lucas Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Request for help: Updating Monoco (continuations) for current Mono
Hi, On Thu, 20 Nov 2008, Hurliman, John wrote: During my exploration into micro-threading projects I stumbled across http://www.bat.org/~tomba/monoco.html. This looks like a great solution, however the patch seems to be quite dated. Are any low-level Mono devs available to help get this compiling cleanly against Mono SVN? I updated it, compiles at least on 32bit linux, and examples worked. Unfortunately I don't have 64bit environment currently, so I can't test that. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Monoco update
Hi, I updated Monoco (http://www.bat.org/~tomba/monoco.html) to work with svn head of Mono. Behaviour of GC had changed a bit and it broke the continuations (GC didn't follow an IntPtr in a managed object). I also updated the naive benchmarks on the web page. While fixing the bug I started to think about how the continuations would work with the new precice GC. I've understood that in the first phase the new GC will scan stack conservatively. Is precise stack scanning something that may happen in the distant future, or something that will definitely come? The same information that the GC uses to do a precise stack scan could possibly be used to serialize continuations. Also currently the whole area reserved for continuation's stack is scanned, even if it is known that only part of the area contains real data. This is also something that I hope I will get fixed with the new GC. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Continuations and MicroThreads
Hi, If you want to improve performance you could start by replacing the LinkedList which seems to be overkill. I think you could get along with a singly linked list without listnode-classes for each microthread which should I have three lists for threads, for scheduled, waiting and sleeping threads. I have to move the threads from one list to another. So an array based list is a bad choice. But perhaps a singly linked list would do the job, as you suggested, perhaps each MicroThread object having a pointer to the next thread. That wouldn't be a beautiful implementation, but perhaps the benefits would overweight that. make it a little faster and use much less memory. Also using foreach is resulting in the creation of an iterator and I think you don't need it. Which foreach are you referring to? There is one in ManageSleepers(), but the whole sleeping system is lousy implementation and should be rewritten. What would be cool is to implement the continuations in unsafe managed code. Do you have ideas how this could be implemented? I don't think you can access stack pointer and processor registers from managed code, and that is what the native implementation does. Thanks for feedback! Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Continuations and MicroThreads
Hi, As i remember, previous version of your scheduler class has a strong reference to the socket manager class. What about an application does not using sockets ? What about another socket implementation ( my case ) ? This is not a crucial fix, but i think it is better to keep out the Socket management. A programmer will use a microthread to update his socket ;). The socket manager does not prevent you from doing anything. If you don't use the included socket implementation, the manager does not do anything, so you can as well use standard .Net sockets in your code. However, then you have to do all the work in non-blocking way, because if you block one microthread, all microthreads are frozen. You have to remember that microthreads are not OS threads =). I've thought of implementing a generic way to add these managers to the scheduler, so you could implement blocking code (blocking in microthread sense, not in OS thread sense) similar to the socket implementation I have. But that's not so simple: The basic problem here is about events. If we don't want to run in a busy loop, constantly polling for new events and using 100% of the CPU, there has to be some place where we wait for events or sleep for a certain time. Sleeping is not good because we can't know when the next event will come, and we would usually sleep too long. In my current code this place, where we wait, is in the socket manager when we Select() the sockets. This works because currently socket events are the only events the microthreads react to. If we'd like to add a new type of event, for example input from console, we'd be in trouble as there's no way we could wait for events both from sockets and from console in the same place. Currently you'd have to have a microthread that polls the console input in a loop and sleeps for some milliseconds between the polls. I'm not sure yet how to solve this event problem. Perhaps a separate OS thread that listens to the event, and notifies the OS thread where microthreads run via a socket. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono Continuations and MicroThreads
Hi, The perfect thread scheduler is the one that give the same execution period time for all threads :) So a first ( incomplete ) idea is coming to me : If : * You define a maximum time of execution foreach microthread. * the scheduler call the microthread run method. * An OS thread loop until the max time is reached for the current microthread or the current microthread returns. If the microthread didn't return before the defined max time, the scheduler force this microthread to save his stack and it switch to an another microthread. I have to disagree here. The whole idea in microthreads is that they are non-preemptive, ie. the microthread has to yield willingly. This way there are no concurrency problems, as the state of the program is always known. If the microthreads were preemptive as you describe, the execution of a thread could be interrupted at any time, thus the state of the program would be unknown. This would mean that you'd have to use locks/mutexes/etc to keep datastructures intact. And then we'd have threads similar to OS threads, and I think the OS threads would do the job better. That said, it could be possible to implement preemptive microthreads (I'm not sure about this, I haven't thought it through). However, that would need modifications to the native implementation. And as I described above, I don't really understand why this would be in any way a good thing =). Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Continuations and MicroThreads
Hi, I made some more optimizations and I finally beat stackless python in the yield test. Almost 3.5M yields/s if ran with inline-optimizations, when the old result was 1.6M. http://bat.org/~tomba/monoco.html has updated source and benchmarks. What comes to getting continuations to official mono, I think the implementation is quite far from being ready for that. There are million things to do before the implementation is usable for everyone, and most importantly, the continuations will need a lot of testing before I trust that they actually work... But I do hope that some people will try them out, perhaps even improving something. Test programs would be especially nice, and benchmarks both in C# and stackless python. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Continuations and Microthreads
Hi, I've made some fixing and optimization to the continuation implementation, and also a simple web page with details, instructions, links and benchmark results. As far as I've been able to test, the boehm GC works now fine with continuations and I haven't found any bugs in the native code and all my tests run fine. That said, there are still ways to break things, but I hope that in normal use these problem cases do not arise. The web page can be found at http://bat.org/~tomba/monoco.html . Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Missing Socket.Send and Socket.Receive methods
Hi,
Included is a patch that implements the missing Socket.Send and
Socket.Receive methods that take SocketError as an out parameter. These
methods do not throw an exception when an error occurs (such as
WouldBlock) and so are quite essential for non-blocking socket IO. I also
changed the SocketError enum to be internal in .Net 1.x version of the
class lib, so that it can be used in socket code instead of those horrible
if (error != 10035) checks.
I've also made a similar Socket.Connect method, but that's not included as
Microsoft's .Net framework does not have such a method. What is the policy
on non-standard methods?
TomiIndex: mcs/class/System/System.Net.Sockets/Socket.cs
===
--- mcs/class/System/System.Net.Sockets/Socket.cs (revision 59285)
+++ mcs/class/System/System.Net.Sockets/Socket.cs (working copy)
@@ -1318,7 +1318,14 @@
if (buf == null)
throw new ArgumentNullException (buf);
- return Receive_nochecks (buf, 0, buf.Length,
SocketFlags.None);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, 0, buf.Length,
SocketFlags.None, out error);
+
+ if (error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
public int Receive (byte [] buf, SocketFlags flags)
@@ -1329,7 +1336,14 @@
if (buf == null)
throw new ArgumentNullException (buf);
- return Receive_nochecks (buf, 0, buf.Length, flags);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, 0, buf.Length, flags,
out error);
+
+ if (error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
public int Receive (byte [] buf, int size, SocketFlags flags)
@@ -1343,17 +1357,16 @@
if (size 0 || size buf.Length)
throw new ArgumentOutOfRangeException (size);
- return Receive_nochecks (buf, 0, size, flags);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, 0, size, flags, out
error);
+
+ if (error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
- [MethodImplAttribute(MethodImplOptions.InternalCall)]
- private extern static int Receive_internal(IntPtr sock,
- byte[] buffer,
- int offset,
- int count,
- SocketFlags flags,
- out int error);
-
public int Receive (byte [] buf, int offset, int size,
SocketFlags flags)
{
if (disposed closed)
@@ -1368,24 +1381,58 @@
if (size 0 || offset + size buf.Length)
throw new ArgumentOutOfRangeException (size);
- return Receive_nochecks (buf, offset, size, flags);
+ SocketError error;
+
+ int ret = Receive_nochecks (buf, offset, size, flags,
out error);
+
+ if(error != SocketError.Success)
+ throw new SocketException ((int)error);
+
+ return ret;
}
- int Receive_nochecks (byte [] buf, int offset, int size,
SocketFlags flags)
+#if NET_2_0
+ public int Receive (byte[] buf, int offset, int size,
SocketFlags flags, out SocketError error)
{
- int ret, error;
+ if (disposed closed)
+ throw new ObjectDisposedException (GetType
().ToString ());
+
+ if (buf == null)
+ throw new ArgumentNullException (buf);
+
+ if (offset 0 || offset buf.Length)
+ throw new ArgumentOutOfRangeException
(offset);
+
+ if (size 0 || offset + size buf.Length)
+ throw new ArgumentOutOfRangeException (size);
- ret = Receive_internal (socket, buf, offset, size,
Re: [Mono-dev] What would you like to see in Mono?
On Tue, 28 Mar 2006, Miguel de Icaza wrote: Hey, What would be the top feature you would like to see in Mono? Think of a feature that is not something we are currently working on (we know about those), for example avoid saying: a class-is-missing feature or IDE or the debugger. We know about those. Miguel. Hi, - Optimizations for embedded use. Currently the Java for ARM I've been using is faster than Mono, especially startup time is very much faster with Java. - Continuations and microthreads. This is actually something that I've been hacking together, and I even managed to get something running. Continuations with native code and microthreads and scheduler with C#. - More support for dynamic languages. Perhaps there's an unsafe way (read: you have to know what you are doing) to unload types. Or perhaps a modified mcs could generate code for dynamic methods. Or something else I haven't thought about =). Of course the latter two mentioned things break CLI-standard compliance... Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What would you like to see in Mono?
On Wed, 29 Mar 2006, Jonathan Pryor wrote: On Wed, 2006-03-29 at 13:02 +0300, Tomi Valkeinen wrote: - More support for dynamic languages. Perhaps there's an unsafe way (read: you have to know what you are doing) to unload types. Or perhaps a modified mcs could generate code for dynamic methods. Or something else I haven't thought about =). What do you have in mind, exactly? .NET 2.0 added System.Reflection.Emit.DynamicMethod, largely to target dynamic languages such as IronPython. It provides access to an ILGenerator for a method, and the DynamicMethod + IL + assembly language is garbage collected in the usual fashion (instead of being tied to an Assembly, thus necessitating an AppDomain unload to free the memory). Given IronPython is Microsoft's dynamic-language testbed, and it's running rather nicely under .NET, I'm not sure how much more needs to be added to better support dynamic languages... Hi, Yes, DynamicMethod is quite a nice feature, and IronPython is a great tool, I've been using them both. But DynamicMethods have their downside, as they are, in a sense, just plain global static functions. You lose the class structure etc. I imagine that unloading a type is possible, but it's very hard to ensure that no one will use that unloaded type. But if I implement a framework that handles the type loading and unloading, I could live with the fact that if the core framework bugs, the application will crash. I think the IronPython guys have problems because of DynamicMethods. DynamicMethods are very good for helper functions, like complied regexp parser, but using them to implement a full object oriented language is not that simple. Of course DynamicMethods are much better than what we had in .Net 1.1 (ie. nothing =). Also, I don't like python very much, and I'd like the language to be strictly typed. What I would like is a C# with type unloading. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What would you like to see in Mono?
On Wed, 29 Mar 2006, Dave Cramer wrote: Tomi, You were able to get mono to build on the arm? If so how ? Hi, Yes, Mono runtime compiles fine on ARM when using Scratchbox, and mcs and the classlibs compile fine too if you first build a mono-devkit for Scratchbox. Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] What would you like to see in Mono?
On Wed, 29 Mar 2006, Jonathan Pryor wrote: Given all the interdependencies between JITed code, executing code, and call stacks, unloading types is a difficult proposition, which is probably why an AppDomain unload is the only way to do that under .NET. Yes, that's probably the reason. Still, I believe that types could be unloaded, and everything would work fine if I just wouldn't use those unloaded types afterwards. Sure it's dangerous and unsafe, but it could work if restricted to a small piece of code in the core of the framework you are coding. So what's wrong with AppDomains? If they're too slow, perhaps we should improve cross-AppDomain invocation. If they're buggy, they should be fixed. The speed is the main reason, and I guess memory usage is also an issue. AppDomains work fine for plugin-style cases, where you can group lots of types together, and cross-domain calls are not the majority, but if I would put each and every type in its own AppDomain... You may wonder where I need that kind of functionality, and the case I was thinking about is a MUD (multi user dungeon). BatMUD has currently 20171 loaded programs, ie. types, which can be recompiled on the fly. That's quite a lot of AppDomains. A couple of years ago I made some performance testing with AppDomains on MS's CLR and compared the results to ldmud, which is a MUD driver. I don't have the results here, nor do I exactly remember them, but AppDomains were not ten or hundred times slower, but more like a million times. The .Net version probably was 1.1, and AppDomains have improved since then, but I guess they are still far behind the performance I'm looking for. (yes, yes, I should redo the test =). Tomi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono for linux ARM
Hi, Yes, you can cross-compile Mono for ARM. It's not trivial though. I've cross-compiled Mono with traditional cross-compiler toolchains and with Scratchbox, of which Scratchbox has been easier for me. Here's brief description how I compile Mono with Scratchbox: 1. Install Scratchbox. I used version 1.0.2. 2. Build Mono-devkit for HOST target. Mono's build process first builds the mono runtime, and then uses that to run mcs to compile the class libraries. This is something you don't want to do, as the runtime is an ARM binary and therefore will be run on your ARM device or on ARM emulator. What you want to do is to run mcs on the host machine. This can be accomplished with Scratchbox's devkits. You can find more information about devkits on Scratchbox's website. So select HOST target on scratchbox, use the devkit template from http://www.bat.org/~tomba/sb-mono-devkit.tar.gz to compile mono devkit. 3. Edit runtime/mono-wrapper.in and runtime/monodis-wrapper.in to use Mono from your devkit. For example, I changed mono-wrapper.in's last line to: mono --config $r/runtime/wrapper-config $@ 4. Set up your ARM target. Select arm-compiler, debian and mono devkits, and qemu-arm for CPU-transparency. See Scratchbox documentation how to set up the target and install the files. Here's a short version: - Edit apt.sources (stable debian-arm works fine for me) - apt-get update - sb-install-base-packages - fakeroot apt-get install libgtk2.0-dev 5. Configure and compile Mono as you normally would. That's about it. I hope I didn't forget any steps =). Compiling gtk-sharp should also work. Tomi On Wed, 25 Jan 2006, Dave Cramer wrote: Apparently it can be cross compiled http://www.mono-project.com/Mono:ARM However I have tried and can't see my previous message earlier this week I'd love to get it cross-compiled anyone ? Dave On 24-Jan-06, at 12:16 PM, Dario Salvi wrote: Hi, does anyone know any project or anyone working on the development of MONO on linux for ARM architectures ? I need to install MONO on a Philips XSilo, aka gigavuPro from Jobo. This device uses the Intel PXA255 processor, source code for the kernel is already available. Can anyone help me please ? Dario -- El hombre esta siempre dispuesto a negar aquello que no comprende. Luigi Pirandello Dario Salvi PhD student at LST Life Supporting Technologies Technical Univesity of Madrid (UPM) Ciudad Universitaria 28040 Madrid España e-mail: [EMAIL PROTECTED] web: http://www.lst.tfo.upm.es mobile: +34 664130294 (ES) +39 3473887225 (I) personal homepage: www.dariosalvi.info ___ 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___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GC segfault on ARM
On Sat, 20 Aug 2005, Paolo Molaro wrote: On 08/18/05 Tomi Valkeinen wrote: Oh, and if you are using an ARM11 based board, you may also want to fix the swp-bug (http://bugzilla.ximian.com/show_bug.cgi?id=75114) Did you test that change? Care to research with the libc guys why they wrote it that way and if your change is really the right fix? Hi, Yes, I did test it. All compilers seem to produce correct code after the change. The interesting part with the bug is that even if the produced code is against ARM reference manual, it works with all the ARM9 processors I have tested, but fails with ARM11. The code in recent libc is actually a bit different. This is from glibc-2.3.5: __asm__ __volatile__(swp %0, %1, [%2] : =r(ret) : 0(1), r(spinlock)); And this is from mono's libgc: __asm__ __volatile__(swp %0, %1, [%2] : =r(oldval) : r(1), r(addr) : memory); The version in glibc produces correct code. The fix that I proposed was suggested in Codesourcery's forums, but I guess the libc version is just as fine. Tomi Valkeinen ___ Mono-devel-list mailing list [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] GC segfault on ARM
Hi again, currently have a functional big endian ARM linux system that I have used to successfully build the ARM JIT. However, upon attempting to run a CIL executable, mono immediately segfaults. A backtrace indicates that the segfault occurs in the Boehm GC: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 32700)] GC_push_all_eager (bottom=0x0, top=0x1990a8 ) at mark.c:1468 1468q = *p; (gdb) bt #0 GC_push_all_eager (bottom=0x0, top=0x1990a8 ) at mark.c:1468 #1 0x000b9ef8 in pthread_push_all_stacks () at pthread_stop_world.c:266 #2 0x000b9fac in GC_push_all_stacks () at pthread_stop_world.c:297 #3 0x000b5848 in GC_push_roots (all=1, cold_gc_frame=0xbefffa4c ) at mark_rts.c:643 #4 0x000b4c60 in $a () at mark.c:326 #5 0x000b4c60 in $a () at mark.c:326 Previous frame identical to this frame (corrupt stack?) I get quite similar backtrace when running the SVN version on our ARM11-based little-endian board: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 395)] 0x001147b0 in GC_push_all_eager () (gdb) bt #0 0x001147b0 in GC_push_all_eager () #1 0x00114844 in GC_push_all_stack () #2 0x0011e320 in pthread_push_all_stacks () #3 0x0011e3ec in GC_push_all_stacks () #4 0x00119164 in GC_default_push_other_roots () #5 0x001164b0 in GC_push_roots () #6 0x00112ab8 in $a () Tomi Valkeinen I got the GC running after changing the method of finding the stack bottom from HEURISTIC1 to LINUX_STACKBOTTOM (gcconfig.h:1755). I don't know why LINUX_STACKBOTTOM wasn't used on arm linux by default, the code looks arm-runnable to me. Of course your problem may be something totally different =). Oh, and if you are using an ARM11 based board, you may also want to fix the swp-bug (http://bugzilla.ximian.com/show_bug.cgi?id=75114) Tomi Valkeinen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Dynamic code generation and mcs
Hi, I've been looking for an embeddable script language for .Net that would use DynamicMethod-class for code generation, to avoid the cannot-unload-assembly-problem. I haven't found any, which is understandable as DynamicMethod is still only in the beta 2.0 framework. I was wondering how difficult (and sensible) it would be to modify mcs so that it would produce code for DynamicMethods. I'd imagine the job would be mostly of disabling things (namespaces, classes etc.), so that only the code for a single static method would be generated. Of course it should be possible to compile mcs as a library for this to work. Or as an other option, how difficult it would be to copy the IL of a static method from a standard assembly to a DynamicMethod? Anyone know any script projects that use or are planning to use DynamicMethods? Tomi Valkeinen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
