Re: [Mono-dev] shut gcc up + add string.h for memmove(3) + don't compile ipaddress_to_struct_in6_addr() when it's not needed
Applied to SVN HEAD/2.6 branch. Zoltan On Sat, Apr 24, 2010 at 8:17 PM, Robert Nagy rob...@openbsd.org wrote: Hey boehm-gc.c: string.h is needed for memmove(3) socket-io.c: ipaddress_to_struct_in6_addr() is only needed when defined(HAVE_STRUCT_IP_MREQN) || defined(HAVE_STRUCT_IP_MREQ) method-to-ir.c: make gcc shut up because it thinks that code will never be reached ___ 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] sys/param.h and sys/types.h dependencies in configure.in
Applied to SVN HEAD/2.6. Zoltan On Sat, Apr 24, 2010 at 8:42 PM, Robert Nagy rob...@openbsd.org wrote: Hi The diff reorders the check for sys/param.h and adds dependencies for it for several headers so the checks won't fail because of undefined stuff. It also adds sys/types.h for the if.h check because that's needed there too. ___ 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] 64-bit OSX support
Hello Geoff, I have successfully build Mono 64 bits for Mac OS X on my machine (10.6.3/Intel C2Duo 2.4GHz), by using the SVN r156105 trunk. Here some experiments I made: - make check reports 2 failing tests: thread6.exe and appdomain-thread-abort.exe. - mono -V works and report the architecture amd64 - the command line utilities (gmcs, monodis, ...) seem to work. I ran into a crash when calling System.Diagnostics.Process.MainModule. I have attached the crash log and a small test-case to reproduce. Let me know if you need more information. Regards, Laurent Etiemble. 2010/4/23 Geoff Norton gnor...@novell.com Hey all, I've landed experimental support for mono in 64-bit osx on trunk, you can test it by running configure with: /configure --with-glib=embedded --host=x86_64-apple-darwin10 For anyone who is interested I would appreciate some testing and reports, it does successfully bootstrap on my machine. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Program.cs Description: Binary data output.log 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] 64-bit OSX support
Hey Laurent, I fixed the process problem in r156118, I'll take a look at the failing tests later tonight. -g On 2010-04-26, at 12:28 PM, Laurent Etiemble wrote: Hello Geoff, I have successfully build Mono 64 bits for Mac OS X on my machine (10.6.3/Intel C2Duo 2.4GHz), by using the SVN r156105 trunk. Here some experiments I made: - make check reports 2 failing tests: thread6.exe and appdomain-thread-abort.exe. - mono -V works and report the architecture amd64 - the command line utilities (gmcs, monodis, ...) seem to work. I ran into a crash when calling System.Diagnostics.Process.MainModule. I have attached the crash log and a small test-case to reproduce. Let me know if you need more information. Regards, Laurent Etiemble. 2010/4/23 Geoff Norton gnor...@novell.com Hey all, I've landed experimental support for mono in 64-bit osx on trunk, you can test it by running configure with: /configure --with-glib=embedded --host=x86_64-apple-darwin10 For anyone who is interested I would appreciate some testing and reports, it does successfully bootstrap on my machine. -g ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Program.csoutput.log ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Ephemeron support for sgen
Hi folks,
This is a summary of the initial design of Ephemeron support for sgen. The
idea is to tailor it specially for ConditionalWeakTable since
it's the only user for it on V4.
ConditionalWeakTable (CWT) will be implemented using open addressing instead
of chaining since both key and value must be reference types and
scanning it is more cache friendly since the whole thing is just an array.
Since ephemerons must prevent both key and value to be marked during regular
scan we'll use a valuetype for it and special case it's gc bitmap to be
empty. Something like struct Ephemeron { object key,value;}. I'm don't
know if it's worth the trouble using a generics version of it since CWT is.
Ephemerons are handled using the traditional 3-phase GC, with
the additional phase happening before weak references. CWT icalls the
runtime to register
all relevant arrays, de-registering is done when they go unreachable.
The additional phase loops over all registered arrays looking for marked
keys without marked values and pushing those to the grey stack. Termination
happens when no new marked key/unmaked value pair is found.
Once this is properly working, two additional improvements should be done.
Split the registered arrays in two, for nursery and oldgen and use remset
information to know which old gen arrays needs to be scanned. The other is
to use a bitmap to encode which array slots must be scanned.
Using an array with references that are not scanned what chosen since the
alternative would be to use an array of IntPtr and lose support for write
barriers. It would have to be IntPtr otherwise since the GC must not scan
them. Moving both values to the runtime would make manipulating the array
much harder and possibly slower.
CWT won't be a nice, fast hashtable while I sort out all gc details, it will
do linear search and only then I'll look into using proper hashing with
linear/quadratic probing.
Finally, a note on boehm. Since it will be phased out after 2.8 the idea is
to implement it using a WeakReference for the key and live with leaks in
case the value references it. It sucks, but requires little effort and
should perform reasonably well.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing the release of Mono 2.6.4
Today we release Mono 2.6.4, a bugfix release in the 2.6 series containing around 40 bugfixes since 2.6.3. The release notes are here: http://go-mono.com/archive/2.6.4 and downloads are available here: http://go-mono.com/mono-downloads/ Thanks to all those who contributed to this release! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ephemeron support for sgen
On Mon, Apr 26, 2010 at 10:25 PM, Rodrigo Kumpera kump...@gmail.com wrote: Once this is properly working, two additional improvements should be done. Split the registered arrays in two, for nursery and oldgen and use remset information to know which old gen arrays needs to be scanned. I doubt scanning old-gen arrays during the nursery collection is worth the trouble - it might even be counterproductive in terms of performance. I'd just leave remsets as they are. If they lead to a few nursery objects to be promoted unnecessarily, big deal. Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
