Re: [Mono-dev] GDI+ crashing with 2.10.7 beta
I've created a ticket to track this issue:
http://bugzilla.xamarin.com/show_bug.cgi?id=2426
On Thu, Dec 8, 2011 at 2:46 PM, Brian Luczkiewicz wrote:
> Ok, that was easy. This test case crashes within 10s every time for me:
>
> To compile:
>
> $ dmcs /r:System.Drawing foo.cs
>
> To run:
>
> $ cp foo.jpg
> $ mono t.exe
>
> foo.cs:
>
> using System;
> using System.IO;
> using System.Threading;
> using System.Drawing;
> using System.Drawing.Imaging;
>
> public class Foo {
> const string infile = "foo.jpg";
>
> public static void Main(string[] args) {
> for (int i =0; i < 10; i++)
> new Thread(Hammer).Start();
> Hammer();
> }
>
> static void Hammer() {
> while (true) {
> using (var outbmp = new Bitmap(100, 100,
> PixelFormat.Format24bppRgb))
> using (var stream = File.OpenRead(infile))
> using (var inbmp = Bitmap.FromStream(stream))
> using (var g = Graphics.FromImage(outbmp)) {
> g.DrawImage(inbmp, new Rectangle(0, 0, outbmp.Width,
> outbmp.Height));
> }
> }
> }
> }
>
>
>
> On Thu, Dec 8, 2011 at 2:35 PM, Brian Luczkiewicz wrote:
>
>> I wanted to report this sooner rather than later in case someone is
>> already working on it. I don't yet have an isolated test case to reproduce
>> this, but I am working on getting one together.
>>
>> I've observed this crash on a mac running lion. I am using this mono beta
>> build:
>> http://download.mono-project.com/archive/2.10.7/MonoFramework-MDK-2.10.7_gtk-beta.macos10.xamarin.x86.dmg.
>> mono
>> 2.10.6 does not crash like this.
>>
>> This is the code. I am using GDI+ simply as an image loader/scaler here.
>> Note that this code can run concurrently in multiple threads, and the crash
>> happens perhaps once for every 2-3000 times that the code is executed.
>>
>> var outbmp = new Bitmap(o.Width, o.Height,
>> PixelFormat.Format24bppRgb);
>> using (var stream = File.OpenRead(somefile))
>> using (var inbmp = Bitmap.FromStream(stream))
>> using (var g = Graphics.FromImage(bmp))
>> g.DrawImage(outbmp, new Rectangle(0, 0, bmp.Width,
>> bmp.Height));
>>
>> The crash is due to an assert:
>>
>> Assertion failed: (!"reached"), function
>> _cairo_hash_table_lookup_exact_key, file cairo-hash.c, line 471.
>>
>> The stack for the assert look like this:
>>
>> 0 libsystem_kernel.dylib 0x94dad9c6 __pthread_kill + 10
>> 1 libsystem_c.dylib 0x91af2f78 pthread_kill + 106
>> 2 libsystem_c.dylib 0x91ae3bdd abort + 167
>> 3 Sooloos 0x00092f5a
>> mono_handle_native_sigsegv + 858 (mini-exceptions.c:2130)
>> 4 Sooloos 0x000dd0ad sigabrt_signal_handler
>> + 109 (mini-posix.c:195)
>> 5 libsystem_c.dylib 0x91b4859b _sigtramp + 43
>> 6 ??? 0x 0 + 4294967295
>> 7 libsystem_c.dylib 0x91ae3bdd abort + 167
>> 8 libsystem_c.dylib 0x91b1820b __assert_rtn + 351
>> 9 libcairo.2.dylib0x0b172f5e
>> _cairo_hash_table_lookup_exact_key + 270
>> 10 libcairo.2.dylib0x0b172f94
>> _cairo_hash_table_remove + 36
>> 11 libcairo.2.dylib0x0b1bd9ca
>> _cairo_toy_font_face_destroy + 170
>> 12 libcairo.2.dylib0x0b16a02a
>> cairo_font_face_destroy + 170
>> 13 libcairo.2.dylib0x0b16d508 _cairo_gstate_fini + 40
>> 14 libcairo.2.dylib0x0b15fe89 cairo_destroy + 201
>> 15 libgdiplus.dylib0x0af8cbe2 GdipDeleteGraphics +
>> 162
>> 16 ??? 0x0cbee06c 0 + 213835884
>> 17 ??? 0x0cbedee4 0 + 213835492
>> 18 ??? 0x0bfd7dd1 0 + 201162193
>> 19 ??? 0x0bfd576c 0 + 201152364
>> 20 ??? 0x0bfd4a68 0 + 201149032
>> 21 ??? 0x0bfd4264 0 + 201146980
>> 22 ??? 0x0bfd2d86 0 + 201141638
>> 23 ??? 0x070483c1 0 + 117736385
>> 24 ??? 0x035e9b52 0 + 56531794
>> 25 ??? 0x035e966c 0 + 56530540
>> 26 ??? 0x035e9452 0 + 5653
Re: [Mono-dev] GDI+ crashing with 2.10.7 beta
Ok, that was easy. This test case crashes within 10s every time for me:
To compile:
$ dmcs /r:System.Drawing foo.cs
To run:
$ cp foo.jpg
$ mono t.exe
foo.cs:
using System;
using System.IO;
using System.Threading;
using System.Drawing;
using System.Drawing.Imaging;
public class Foo {
const string infile = "foo.jpg";
public static void Main(string[] args) {
for (int i =0; i < 10; i++)
new Thread(Hammer).Start();
Hammer();
}
static void Hammer() {
while (true) {
using (var outbmp = new Bitmap(100, 100,
PixelFormat.Format24bppRgb))
using (var stream = File.OpenRead(infile))
using (var inbmp = Bitmap.FromStream(stream))
using (var g = Graphics.FromImage(outbmp)) {
g.DrawImage(inbmp, new Rectangle(0, 0, outbmp.Width,
outbmp.Height));
}
}
}
}
On Thu, Dec 8, 2011 at 2:35 PM, Brian Luczkiewicz wrote:
> I wanted to report this sooner rather than later in case someone is
> already working on it. I don't yet have an isolated test case to reproduce
> this, but I am working on getting one together.
>
> I've observed this crash on a mac running lion. I am using this mono beta
> build:
> http://download.mono-project.com/archive/2.10.7/MonoFramework-MDK-2.10.7_gtk-beta.macos10.xamarin.x86.dmg.
> mono
> 2.10.6 does not crash like this.
>
> This is the code. I am using GDI+ simply as an image loader/scaler here.
> Note that this code can run concurrently in multiple threads, and the crash
> happens perhaps once for every 2-3000 times that the code is executed.
>
> var outbmp = new Bitmap(o.Width, o.Height,
> PixelFormat.Format24bppRgb);
> using (var stream = File.OpenRead(somefile))
> using (var inbmp = Bitmap.FromStream(stream))
> using (var g = Graphics.FromImage(bmp))
> g.DrawImage(outbmp, new Rectangle(0, 0, bmp.Width, bmp.Height));
>
> The crash is due to an assert:
>
> Assertion failed: (!"reached"), function
> _cairo_hash_table_lookup_exact_key, file cairo-hash.c, line 471.
>
> The stack for the assert look like this:
>
> 0 libsystem_kernel.dylib 0x94dad9c6 __pthread_kill + 10
> 1 libsystem_c.dylib 0x91af2f78 pthread_kill + 106
> 2 libsystem_c.dylib 0x91ae3bdd abort + 167
> 3 Sooloos 0x00092f5a
> mono_handle_native_sigsegv + 858 (mini-exceptions.c:2130)
> 4 Sooloos 0x000dd0ad sigabrt_signal_handler
> + 109 (mini-posix.c:195)
> 5 libsystem_c.dylib 0x91b4859b _sigtramp + 43
> 6 ??? 0x 0 + 4294967295
> 7 libsystem_c.dylib 0x91ae3bdd abort + 167
> 8 libsystem_c.dylib 0x91b1820b __assert_rtn + 351
> 9 libcairo.2.dylib0x0b172f5e
> _cairo_hash_table_lookup_exact_key + 270
> 10 libcairo.2.dylib0x0b172f94
> _cairo_hash_table_remove + 36
> 11 libcairo.2.dylib0x0b1bd9ca
> _cairo_toy_font_face_destroy + 170
> 12 libcairo.2.dylib0x0b16a02a cairo_font_face_destroy
> + 170
> 13 libcairo.2.dylib0x0b16d508 _cairo_gstate_fini + 40
> 14 libcairo.2.dylib0x0b15fe89 cairo_destroy + 201
> 15 libgdiplus.dylib0x0af8cbe2 GdipDeleteGraphics + 162
> 16 ??? 0x0cbee06c 0 + 213835884
> 17 ??? 0x0cbedee4 0 + 213835492
> 18 ??? 0x0bfd7dd1 0 + 201162193
> 19 ??? 0x0bfd576c 0 + 201152364
> 20 ??? 0x0bfd4a68 0 + 201149032
> 21 ??? 0x0bfd4264 0 + 201146980
> 22 ??? 0x0bfd2d86 0 + 201141638
> 23 ??? 0x070483c1 0 + 117736385
> 24 ??? 0x035e9b52 0 + 56531794
> 25 ??? 0x035e966c 0 + 56530540
> 26 ??? 0x035e9452 0 + 56530002
> 27 ??? 0x035e3d9d 0 + 56507805
> 28 Sooloos 0xd0a2 mono_jit_runtime_invoke
> + 722 (mini.c:5791)
> 29 Sooloos 0x001a4caa mono_runtime_invoke +
> 170 (object.c:2755)
> 30 Sooloos 0x001a6547
> mono_runtime_delegate_invoke + 135 (object.c:3420)
> 31 Sooloos 0x0021fec6 start_wrapper_internal
> + 726 (threads.c:799)
> 32 Sooloos 0x0021ff32 start_wrapper + 34
> (threads.c:831)
> 33 Sooloos
[Mono-dev] GDI+ crashing with 2.10.7 beta
I wanted to report this sooner rather than later in case someone is already working on it. I don't yet have an isolated test case to reproduce this, but I am working on getting one together. I've observed this crash on a mac running lion. I am using this mono beta build: http://download.mono-project.com/archive/2.10.7/MonoFramework-MDK-2.10.7_gtk-beta.macos10.xamarin.x86.dmg. mono 2.10.6 does not crash like this. This is the code. I am using GDI+ simply as an image loader/scaler here. Note that this code can run concurrently in multiple threads, and the crash happens perhaps once for every 2-3000 times that the code is executed. var outbmp = new Bitmap(o.Width, o.Height, PixelFormat.Format24bppRgb); using (var stream = File.OpenRead(somefile)) using (var inbmp = Bitmap.FromStream(stream)) using (var g = Graphics.FromImage(bmp)) g.DrawImage(outbmp, new Rectangle(0, 0, bmp.Width, bmp.Height)); The crash is due to an assert: Assertion failed: (!"reached"), function _cairo_hash_table_lookup_exact_key, file cairo-hash.c, line 471. The stack for the assert look like this: 0 libsystem_kernel.dylib 0x94dad9c6 __pthread_kill + 10 1 libsystem_c.dylib 0x91af2f78 pthread_kill + 106 2 libsystem_c.dylib 0x91ae3bdd abort + 167 3 Sooloos 0x00092f5a mono_handle_native_sigsegv + 858 (mini-exceptions.c:2130) 4 Sooloos 0x000dd0ad sigabrt_signal_handler + 109 (mini-posix.c:195) 5 libsystem_c.dylib 0x91b4859b _sigtramp + 43 6 ??? 0x 0 + 4294967295 7 libsystem_c.dylib 0x91ae3bdd abort + 167 8 libsystem_c.dylib 0x91b1820b __assert_rtn + 351 9 libcairo.2.dylib0x0b172f5e _cairo_hash_table_lookup_exact_key + 270 10 libcairo.2.dylib0x0b172f94 _cairo_hash_table_remove + 36 11 libcairo.2.dylib0x0b1bd9ca _cairo_toy_font_face_destroy + 170 12 libcairo.2.dylib0x0b16a02a cairo_font_face_destroy + 170 13 libcairo.2.dylib0x0b16d508 _cairo_gstate_fini + 40 14 libcairo.2.dylib0x0b15fe89 cairo_destroy + 201 15 libgdiplus.dylib0x0af8cbe2 GdipDeleteGraphics + 162 16 ??? 0x0cbee06c 0 + 213835884 17 ??? 0x0cbedee4 0 + 213835492 18 ??? 0x0bfd7dd1 0 + 201162193 19 ??? 0x0bfd576c 0 + 201152364 20 ??? 0x0bfd4a68 0 + 201149032 21 ??? 0x0bfd4264 0 + 201146980 22 ??? 0x0bfd2d86 0 + 201141638 23 ??? 0x070483c1 0 + 117736385 24 ??? 0x035e9b52 0 + 56531794 25 ??? 0x035e966c 0 + 56530540 26 ??? 0x035e9452 0 + 56530002 27 ??? 0x035e3d9d 0 + 56507805 28 Sooloos 0xd0a2 mono_jit_runtime_invoke + 722 (mini.c:5791) 29 Sooloos 0x001a4caa mono_runtime_invoke + 170 (object.c:2755) 30 Sooloos 0x001a6547 mono_runtime_delegate_invoke + 135 (object.c:3420) 31 Sooloos 0x0021fec6 start_wrapper_internal + 726 (threads.c:799) 32 Sooloos 0x0021ff32 start_wrapper + 34 (threads.c:831) 33 Sooloos 0x002653ce thread_start_routine + 206 (wthreads.c:287) 34 Sooloos 0x001efa75 gc_start_thread + 165 (sgen-gc.c:6151) 35 libsystem_c.dylib 0x91af0ed9 _pthread_start + 335 36 libsystem_c.dylib 0x91af46de thread_start + 34 Interestingly, at the same time as the crash, another thread was in a nearby part of the code: 0 libsystem_kernel.dylib 0x94dad876 __psynch_mutexwait + 10 1 libsystem_c.dylib 0x91aef6af pthread_mutex_lock + 633 2 libcairo.2.dylib0x0b1bd25f _cairo_toy_font_face_hash_table_lock + 31 3 libcairo.2.dylib0x0b1bd785 cairo_toy_font_face_create + 229 4 libcairo.2.dylib0x0b170ae8 _cairo_gstate_select_font_face + 56 5 libcairo.2.dylib0x0b162b0d cairo_select_font_face + 77 6 libgdiplus.dylib0x0af8c92a gdip_graphics_cairo_init + 106 7 libgdiplus.dylib0x0af8c975 gdip_graphics_new + 53 8 libgdiplus.dylib0x0afa6072 GdipGetImageGraphicsContext + 306 9 ??? 0x0cbed888 0 + 213833864 10 ??? 0x0cbed58c 0 + 213833100 11 ??? 0x0bfd7c90 0 + 201161872 12 ???
Re: [Mono-dev] sgen + ConditionalWeakTable<,> crashes
While attempting to reproduce this, I ran into another ConditionalWeakTable/sgen bug + entered it into the bug tracker. Unsure if this is related to the segv or not: http://bugzilla.xamarin.com/show_bug.cgi?id=1175 On Sat, Oct 1, 2011 at 12:51 AM, Brian Luczkiewicz wrote: > Before I track down a tiny repro case for this and file a formal bug > report, I wanted to check and see if these stack traces look like any known > bugs. > > We've recently added usage of ConditionalWeakTable<,> api to our codebase. > We are now seeing some crashes in the mono runtime. The crashes appear to be > sgen specific. > > The stack traces look like this: > > Stacktrace: > > at (wrapper managed-to-native) object.__icall_wrapper_mono_object_castclass > (object,intptr) > at System.Runtime.CompilerServices.ConditionalWeakTable`2.TryGetValue > (TKey,TValue&) [0x00083] in > /private/tmp/monobuild/build/BUILD/mono-2.10.5/mcs/cl... stack frames of our > application code ... > at Application.Main (string[]) [0x00622] in > /Projects/sooloos/sooloos/Client/Desktop/main.cs:266 > at (wrapper runtime-invoke) .runtime_invoke_void_object > (object,intptr,intptr,intptr) > > Native stacktrace: > > 0 Sooloos 0x000bc1d6 > mono_handle_native_sigsegv + 422 > 1 Sooloos 0x49fe > mono_sigsegv_signal_handler + 334 > 2 libsystem_c.dylib 0x98cd559b _sigtramp + 43 > 3 ??? 0x 0x0 + 4294967295 > 4 Sooloos 0x0016be1c mono_image_lock + 29 > 5 Sooloos 0x0016bf55 > mono_image_property_insert + 17 > 6 Sooloos 0x00135659 mono_class_set_failure > + 84 > 7 Sooloos 0x0012c745 mono_class_init + 709 > 8 Sooloos 0x001331c4 > mono_class_is_assignable_from + 109 > 9 Sooloos 0x001cc1bf mono_object_isinst + > 118 > 10 Sooloos 0x0007b549 mono_object_castclass > + 57 > 11 ??? 0x004bb8e8 0x0 + 4962536 > 12 ??? 0x0c848794 0x0 + 210012052 > 13 ??? 0x096fc710 0x0 + 158320400 > 14 ??? 0x077aaa80 0x0 + 125479552 > 15 ??? 0x109fdf74 0x0 + 278912884 > 16 ??? 0x109fdf34 0x0 + 278912820 > 17 ??? 0x109b5b8b 0x0 + 278616971 > 18 ??? 0x109b42e8 0x0 + 278610664 > 19 ??? 0x109dfb8e 0x0 + 278789006 > 20 ??? 0x109fb090 0x0 + 278900880 > 21 ??? 0x109fae70 0x0 + 278900336 > 22 ??? 0x109dfb8e 0x0 + 278789006 > 23 ??? 0x109fb090 0x0 + 278900880 > 24 ??? 0x109fae70 0x0 + 278900336 > 25 ??? 0x109dfb8e 0x0 + 278789006 > 26 ??? 0x109fb090 0x0 + 278900880 > 27 ??? 0x137edc24 0x0 + 327080996 > 28 ??? 0x109dfb8e 0x0 + 278789006 > 29 ??? 0x109fb090 0x0 + 278900880 > 30 ??? 0x109fae70 0x0 + 278900336 > 31 ??? 0x109dfb8e 0x0 + 278789006 > 32 ??? 0x109fb090 0x0 + 278900880 > 33 ??? 0x109fae70 0x0 + 278900336 > 34 ??? 0x109dfb8e 0x0 + 278789006 > 35 ??? 0x109fb090 0x0 + 278900880 > 36 ??? 0x109fae70 0x0 + 278900336 > 37 ??? 0x109dfb8e 0x0 + 278789006 > 38 ??? 0x109fb090 0x0 + 278900880 > 39 ??? 0x109fae70 0x0 + 278900336 > 40 ??? 0x109dfb8e 0x0 + 278789006 > 41 ??? 0x109fb090 0x0 + 278900880 > 42 ??? 0x109dfb8e 0x0 + 278789006 > 43 ??? 0x109fb090 0x0 + 278900880 > 44 ??? 0x109fae70 0x0 + 278900336 > 45 ??? 0x109dfb8e 0x0 + 278789006 > 46 ???
[Mono-dev] sgen + ConditionalWeakTable<,> crashes
Before I track down a tiny repro case for this and file a formal bug report, I wanted to check and see if these stack traces look like any known bugs. We've recently added usage of ConditionalWeakTable<,> api to our codebase. We are now seeing some crashes in the mono runtime. The crashes appear to be sgen specific. The stack traces look like this: Stacktrace: at (wrapper managed-to-native) object.__icall_wrapper_mono_object_castclass (object,intptr) at System.Runtime.CompilerServices.ConditionalWeakTable`2.TryGetValue (TKey,TValue&) [0x00083] in /private/tmp/monobuild/build/BUILD/mono-2.10.5/mcs/cl... stack frames of our application code ... at Application.Main (string[]) [0x00622] in /Projects/sooloos/sooloos/Client/Desktop/main.cs:266 at (wrapper runtime-invoke) .runtime_invoke_void_object (object,intptr,intptr,intptr) Native stacktrace: 0 Sooloos 0x000bc1d6 mono_handle_native_sigsegv + 422 1 Sooloos 0x49fe mono_sigsegv_signal_handler + 334 2 libsystem_c.dylib 0x98cd559b _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 4 Sooloos 0x0016be1c mono_image_lock + 29 5 Sooloos 0x0016bf55 mono_image_property_insert + 17 6 Sooloos 0x00135659 mono_class_set_failure + 84 7 Sooloos 0x0012c745 mono_class_init + 709 8 Sooloos 0x001331c4 mono_class_is_assignable_from + 109 9 Sooloos 0x001cc1bf mono_object_isinst + 118 10 Sooloos 0x0007b549 mono_object_castclass + 57 11 ??? 0x004bb8e8 0x0 + 4962536 12 ??? 0x0c848794 0x0 + 210012052 13 ??? 0x096fc710 0x0 + 158320400 14 ??? 0x077aaa80 0x0 + 125479552 15 ??? 0x109fdf74 0x0 + 278912884 16 ??? 0x109fdf34 0x0 + 278912820 17 ??? 0x109b5b8b 0x0 + 278616971 18 ??? 0x109b42e8 0x0 + 278610664 19 ??? 0x109dfb8e 0x0 + 278789006 20 ??? 0x109fb090 0x0 + 278900880 21 ??? 0x109fae70 0x0 + 278900336 22 ??? 0x109dfb8e 0x0 + 278789006 23 ??? 0x109fb090 0x0 + 278900880 24 ??? 0x109fae70 0x0 + 278900336 25 ??? 0x109dfb8e 0x0 + 278789006 26 ??? 0x109fb090 0x0 + 278900880 27 ??? 0x137edc24 0x0 + 327080996 28 ??? 0x109dfb8e 0x0 + 278789006 29 ??? 0x109fb090 0x0 + 278900880 30 ??? 0x109fae70 0x0 + 278900336 31 ??? 0x109dfb8e 0x0 + 278789006 32 ??? 0x109fb090 0x0 + 278900880 33 ??? 0x109fae70 0x0 + 278900336 34 ??? 0x109dfb8e 0x0 + 278789006 35 ??? 0x109fb090 0x0 + 278900880 36 ??? 0x109fae70 0x0 + 278900336 37 ??? 0x109dfb8e 0x0 + 278789006 38 ??? 0x109fb090 0x0 + 278900880 39 ??? 0x109fae70 0x0 + 278900336 40 ??? 0x109dfb8e 0x0 + 278789006 41 ??? 0x109fb090 0x0 + 278900880 42 ??? 0x109dfb8e 0x0 + 278789006 43 ??? 0x109fb090 0x0 + 278900880 44 ??? 0x109fae70 0x0 + 278900336 45 ??? 0x109dfb8e 0x0 + 278789006 46 ??? 0x109de264 0x0 + 278782564 47 ??? 0x0ca05744 0x0 + 211834692 48 ??? 0x0ca05506 0x0 + 211834118 49 ??? 0x004b32b4 0x0 + 4928180 50 ??? 0x004b35a3 0x0 + 4928931 51 Sooloos 0x00010724 mono_jit_runtime_invoke + 164 52 Sooloos 0x001c7815 mono_runtime_invoke + 137 53 Sooloos 0x001ca0f4 mono_runtime_exec_main + 669 54 Sooloos 0x001c942e mono_runtime_run_main + 843 55 Sooloos 0x0008caf0 mono_main + 8
Re: [Mono-dev] how does unmanaged callback marshalling work in full aot?
I just thought of a scheme to do non-static delegate marshalling without code generation, but it's a little bit goofy. Allocate a structure that contains two things: (1) the instance ptr that you want to capture (2) the function ptr for a compile-time-generated invoker that implements the desired unmanaged function signature. Then hand this structure off to unmanaged-land as if it were a function pointer. when you try to execute the function, the kernel will raise a fault. The runtime can notice that it's in this situation and invoke (2) with (1) either using another compile time generated function to forward the call, or (maybe on x86) by rewriting the stack to push the instance pointer + then jumping to the real function. There's obviously a cost associated with the fault. There's also a chance that the specific implementation of iOS's limitations would prohibit this (the kernel might murder the process before we get a chance to recover). Anyways, just a thought.. On Fri, Jul 29, 2011 at 5:14 PM, Geoff Norton wrote: > It is disabled in full-aot environments. Full-aot only supports static > delegates to be pinvoked, and even then they need to be decorated with a > special attribute. > > See https://github.com/mono/mono/blob/master/mono/mini/aot-compiler.c around > line 2793. > > -g > > On 2011-07-29, at 5:03 PM, Brian Luczkiewicz wrote: > > I'm having trouble seeing how an arbitrary delegate can be marshalled into > an unmanaged function pointer without runtime code generation to capture the > object pointer. > > Is this functionality disabled in full-aot environments or is it > accomplished by some mechanism that I'm not considering? > > > ___ > 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-dev] how does unmanaged callback marshalling work in full aot?
I'm having trouble seeing how an arbitrary delegate can be marshalled into an unmanaged function pointer without runtime code generation to capture the object pointer. Is this functionality disabled in full-aot environments or is it accomplished by some mechanism that I'm not considering? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] gc_test_and_set + arm architectures
This code (duplicated below, from gc_locks.h) is a little bit troublesome.
I'm not sure what the best way to resolve is, but I figured I'd raise the
issue anyways.
On most architectures, building for an old CPU then running on a newer one
is safe. For example, running code compiled for i386 on a modern intel cpu
generally turns out ok.
With mono+arm this is not the case. If I use gcc to build for arm with no
-march/etc flags, gcc builds for armv5. If I run this mono on an SMP armv7a
machine, I get deadlocks and terribleness, because test+set is broken. The
comments seems to suggest that someone anticipated this issue, but never
followed up.
Any ideas how we can make this experience better? If it's truly not possible
to write a single code path that is suitable for both CPUs when building for
armv5, maybe code built for armv5 should force mono into a single cpu or
assert at boot if run on an SMP arm machine.
---
inline static int GC_test_and_set(volatile unsigned int *addr) {#if
defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__) ||
defined(__ARM_ARCH_7__)
int ret, tmp;
__asm__ __volatile__ (
"1:\n"
"ldrex %0, [%3]\n"
"strex %1, %2, [%3]\n"
"teq %1, #0\n"
"bne 1b\n"
: "=&r" (ret), "=&r" (tmp)
: "r" (1), "r" (addr)
: "memory", "cc");
return ret;
#else
int oldval;
/* SWP on ARM is very similar to XCHG on x86. Doesn't lock the
* bus because there are no SMP ARM machines. If/when there are,
* this code will likely need to be updated. */
/* See linuxthreads/sysdeps/arm/pt-machine.h in glibc-2.1 */
__asm__ __volatile__("swp %0, %1, [%2]"
: "=&r"(oldval)
: "r"(1), "r"(addr)
: "memory");
return oldval;
#endif
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] F# packaging + fsyacc/fslex
I noticed that the mono distribution includes fsc/fsi but omits fsyacc/fslex. These tools have been part of microsoft's F# drops for years and are part of the vs.net distribution as well. As a result, tons of F# software requires these tools. Any distribution which includes fsc should probably include fsyacc/fslex as well. Because they are missing from the distribution, there is no canonical way to launch these tools on osx/linux. This makes it difficult to write build files that will work out-of-the-box for various users. Making them available in a standard location would save a ton of headache. Can these be added to mono's binary distributions? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Failed assertion on ARM11 after compiling with -DARM_FPU_VFP
It's hard to know if I've run into this specific problem or not from your
description, but I have experience with the pitfalls of building mono for
multi-core arm chips. Some things to try:
- Try starting with -O0 and adding your flags back in one by one. I've seen
evidence of buggy GCC code generation for ARM that manifests in
unpredictable stack corruption and crashes like yours. For my situation
(mono 2.10.2 + codesourcery gcc 2009q1), -O is stable, but -O2 is not.
- Since you're dual-core, make extra-special-sure that mono is using MP-safe
atomic ops--I know that it does on armv7, but unsure about armv6k. If you
configure/build for armv5te, it does not, and you end up with binaries that
do bad things on MP ARM systems but work fine on UP systems.
In case a comparison is useful, my arch/opt flags are:
-march=armv7-a -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon -O -ffast-math
and I am using -DARM_FPU_VFP. The CPU is an APQ8060.
I never tried with ARM_FPU_NONE, but I could totally see gcc optimizer bugs
being hidden by avoiding certain hard fp code generation.
On Sat, Jun 25, 2011 at 9:15 PM, Bill Agee wrote:
> Hi all,
>
> I'm seeing an odd mono crash after cross compiling mono for a Cavium Econa
> CNS3420 (a dual-core ARM11).
>
> I'm using the mono-2.10.2 tarball.
>
> The CNS3420 appears to support VFP, but when I compile Mono with these
> CFLAGS:
>
> CFLAGS="-DARM_FPU_VFP -O3 -march=armv6k -mcpu=mpcore -mfloat-abi=softfp
> -mfpu=vfp"
>
> ...I frequently see a crash in mono when running on my target machine.
>
> The .NET stacktrace varies, but the native stacktrace and error is always
> this failed assertion:
>
>
> wrong maximal instruction length of instruction r4const (expected 20, got
> 24)
> * Assertion: should not be reached at mini-arm.c:4658
>
> Native stacktrace:
>
>mono() [0xa6928]
>/lib/libc.so.6(__default_rt_sa_restorer_v2+0) [0x3575d660]
>/lib/libc.so.6(gsignal+0x40) [0x3575c2fc]
>/lib/libc.so.6(abort+0x1b0) [0x35761b14]
>mono() [0x1ed810]
>mono() [0x1ed854]
>mono() [0xd8e10]
>mono() [0x1c494]
>mono() [0x2166c]
>mono() [0x22b74]
>mono() [0x2342c]
>mono(mono_compile_method+0x18) [0x1a4560]
>mono() [0xaab50]
>mono() [0xab6c4]
>
>
> Aborted
>
>
> The problem goes away if I compile with -DARM_FPU_NONE instead of
> -DARM_FPU_VFP:
>
> CFLAGS="-DARM_FPU_NONE -O3 -march=armv6k -mcpu=mpcore -mfloat-abi=softfp
> -mfpu=vfp"
>
>
> Does anyone have any idea what the issue might be?
>
> Here's the full build command from my makefile:
>
>
>
> CC=/usr/local/cavium/cns3xxx-sdk/tools/glibc64k/bin/arm-none-linux-gnueabi-gcc
> \
>
>
> CXX=/usr/local/cavium/cns3xxx-sdk/tools/glibc64k/bin/arm-none-linux-gnueabi-g++
> \
> CFLAGS="-DARM_FPU_VFP -O3 -march=armv6k -mcpu=mpcore
> -mfloat-abi=softfp -mfpu=vfp" \
> ./configure \
> --prefix=/foo \
> --disable-mcs-build \
> --with-profile4=no \
> --with-moonlight=no \
> --host=arm-none-linux-gnueabi \
> --with-tls=pthread \
> --with-sigaltstack=no \
> mono_cv_uscore=${mono_cv_uscore=no} && \
>make
>
>
> Thanks in advance for any hints/pointers!
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Failed-assertion-on-ARM11-after-compiling-with-DARM-FPU-VFP-tp3625317p3625317.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> 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-dev] monolinker failing on "hello, world"--any ideas?
This is with mono 2.10.2 on osx, installed from the binary installer. Am I
doing something wrong here? Any ideas?
brian@brianmbp ~ $ cat t.cs
using System;
class Hello {
public static void Main(string[] args) {
Console.WriteLine("Hello, World");
}
}
brian@brianmbp ~ $ dmcs t.cs
brian@brianmbp ~ $ monolinker -c link -a t.exe
Fatal error in Mono CIL Linker
System.ArgumentException: Member 'System.Security.AccessControl.AccessRule'
is declared in another module and needs to be imported
at Mono.Cecil.MetadataBuilder.LookupToken (IMetadataTokenProvider
provider) [0x0] in :0
at Mono.Cecil.SignatureWriter.MakeTypeDefOrRefCodedRID
(Mono.Cecil.TypeReference type) [0x0] in :0
at Mono.Cecil.SignatureWriter.WriteTypeSignature (Mono.Cecil.TypeReference
type) [0x0] in :0
at Mono.Cecil.SignatureWriter.WriteGenericInstanceSignature
(IGenericInstance instance) [0x0] in :0
at Mono.Cecil.SignatureWriter.WriteTypeSignature (Mono.Cecil.TypeReference
type) [0x0] in :0
at Mono.Cecil.MetadataBuilder.GetFieldSignature (Mono.Cecil.FieldReference
field) [0x0] in :0
at Mono.Cecil.MetadataBuilder.AddField (Mono.Cecil.FieldDefinition field)
[0x0] in :0
at Mono.Cecil.MetadataBuilder.AddFields (Mono.Cecil.TypeDefinition type)
[0x0] in :0
at Mono.Cecil.MetadataBuilder.AddType (Mono.Cecil.TypeDefinition type)
[0x0] in :0
at Mono.Cecil.MetadataBuilder.AddTypeDefs () [0x0] in :0
at Mono.Cecil.MetadataBuilder.BuildTypes () [0x0] in :0
at Mono.Cecil.MetadataBuilder.BuildModule () [0x0] in :0
at Mono.Cecil.MetadataBuilder.BuildMetadata () [0x0] in :0
at Mono.Cecil.ModuleWriter.m__18
(Mono.Cecil.MetadataBuilder builder, Mono.Cecil.MetadataReader _) [0x0]
in :0
at Mono.Cecil.ModuleDefinition.Read[MetadataBuilder,MetadataBuilder]
(Mono.Cecil.MetadataBuilder item, System.Func`3 read) [0x0] in :0
at Mono.Cecil.ModuleWriter.BuildMetadata (Mono.Cecil.ModuleDefinition
module, Mono.Cecil.MetadataBuilder metadata) [0x0] in :0
at Mono.Cecil.ModuleWriter.WriteModuleTo (Mono.Cecil.ModuleDefinition
module, System.IO.Stream stream, Mono.Cecil.WriterParameters parameters)
[0x0] in :0
at Mono.Cecil.ModuleDefinition.Write (System.IO.Stream stream,
Mono.Cecil.WriterParameters parameters) [0x0] in :0
at Mono.Cecil.ModuleDefinition.Write (System.String fileName,
Mono.Cecil.WriterParameters parameters) [0x0] in :0
at Mono.Cecil.AssemblyDefinition.Write (System.String fileName,
Mono.Cecil.WriterParameters parameters) [0x0] in :0
at Mono.Linker.Steps.OutputStep.OutputAssembly
(Mono.Cecil.AssemblyDefinition assembly) [0x0] in :0
at Mono.Linker.Steps.OutputStep.ProcessAssembly
(Mono.Cecil.AssemblyDefinition assembly) [0x0] in :0
at Mono.Linker.Steps.BaseStep.Process (Mono.Linker.LinkContext context)
[0x0] in :0
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context)
[0x0] in :0
at Mono.Linker.Driver.Run () [0x0] in :0
at Mono.Linker.Driver.Main (System.String[] args) [0x0] in :0
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible regression in Mono 2.10.1
I just ran into this myself..and put in a bug report. https://bugzilla.novell.com/show_bug.cgi?id=686433 (0 - x) is being constant-folded to (x) in mono 2.10.1. On Thu, Mar 24, 2011 at 7:05 PM, David Mitchell wrote: > So I was playing around in my Terminal today, and I did the following: > > ws1331:macintosh dmitchell$ > /Library/Frameworks/Mono.framework/Versions/Current/bin/mono --version > Mono JIT compiler version 2.10.1 (tarball Fri Feb 25 15:56:49 MST 2011) > Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com > TLS: normal > SIGSEGV: normal > Notification: Thread + polling > Architecture: x86 > Disabled: none > Misc: debugger softdebug > LLVM: yes(2.9svn-mono) > GC:Included Boehm (with typed GC) > ws1331:macintosh dmitchell$ > /Library/Frameworks/Mono.framework/Versions/Current/bin/csharp > csharp csharp2 > ws1331:macintosh dmitchell$ > /Library/Frameworks/Mono.framework/Versions/Current/bin/csharp2 > Mono C# Shell, type "help;" for help > > Enter statements below. > csharp> double f = -5.0; > csharp> f = 0 - f; > csharp> f; > -5 > csharp> > > > > Does anyone think that this might be something of a problem? > > Perhaps one worthy of another point release? > > Thanks, > — Dave > > ___ > 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] AOT + the osx installer.
> > This is great news, as we just recently enabled this. > > Was this with LLVM or with the regular AOT? Regular AOT. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] AOT + the osx installer.
> > Perhaps we could provide the option for the user to toggle those on > and off at install time. > Sounds good to me. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] AOT + the osx installer.
When I build mono from source and install on linux, I've noticed that I end up with .so's next to some of the installed dll's and exe's. This provides a nice speedup when running compilers/tools from the mono distribution. Now that we have AOT working on osx, the same optimization makes sense there, too. I decided to try this out with mono 2.8.2 on an intel mac. I manually AOT'd: /Library/Frameworks/Mono.Framework/Versions/Current/lib/mono/*/*.exe /Library/Frameworks/Mono.Framework/Versions/Current/lib/mono/gac/*/*/*.dll I have a project that is about 500kloc of C# and builds with gmcs. AOT'ing the mono distribution as I've described dropped the build time for this project from 84s to 46s on my c2d macbook pro. This is a 44% speedup! I'm unsure who owns the OSX build/packaging, but it seems like this should be a simple change to make since we already do it on linux, and it would be great to get this kind of performance out of the box. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Status of non-full AOT on x86 mac
> > I would suggest to fold this into the preexisting section. Does Darwin/x86 > not define __MACH__? > __MACH__ is an antiquated way to detect an apple machine. Newer code, both out in the world and within the mono tree (e.g. mini-x86.h) seems to use __APPLE__. Obviously, do what you want here, but that was my line of thinking. > And are you sure that __native_client_codegen__ on OSX should influence the > file name extension for shared libraries? Since __native_client_codegen__ is the only pre-existing case where we do aot on x86 mac, I was being extra careful to make sure that when it's defined, the pre-existing behavior is unaffected. I'm unsure whether __native_client_codegen__ depends on filename extension and am not in a position to test it. If you happen to know better then that condition is unnecessary. What warnings are you suppressing there? The surrounding archs don't appear > to. The debug information size expression (Ldebug_end - Ldebug_begin) causes a warning because it's not computable at assembly time since the sections are relocatable. This doesn't appear to cause a problem in practice, but it does cause a warning message. > Same thoughts wrt the extension here. Same response. Is that a typo? The latter part of the #elif would never be true since it is > handled in your #if already. > Yes..good catch. The latter part of the #elif should go. > > Regards, > Andreas > Given my responses above, let me know what you think and I will prepare an updated patch. Thanks, Brian ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Status of non-full AOT on x86 mac
Hello,
> Could you post the patch for review and license it under the MIT X11
> license?
>
> Miguel
>
I've reproduced the patch below.
The following patch is released under the terms of the MIT/X11 license, per
Miguel's request.
Brian
commit fb96f5d6387cc5c019fc00bfc89a25204fa14166
Author: Brian Luczkiewicz
Date: Sat Oct 30 21:52:09 2010 -0400
Enable --aot (but not --aot=full) on osx/x86
diff --git a/mono/mini/aot-compiler.c b/mono/mini/aot-compiler.c
index 5088324..70ff8c0 100644
--- a/mono/mini/aot-compiler.c
+++ b/mono/mini/aot-compiler.c
@@ -82,6 +82,8 @@
#define SHARED_EXT ".dll"
#elif defined(__ppc__) && defined(__MACH__)
#define SHARED_EXT ".dylib"
+#elif defined(__APPLE__) && defined(TARGET_X86) &&
!defined(__native_client_codegen__)
+#define SHARED_EXT ".dylib"
#else
#define SHARED_EXT ".so"
#endif
@@ -6055,6 +6057,8 @@ compile_asm (MonoAotCompile *acfg)
#define LD_OPTIONS "-m elf64ppc"
#elif defined(sparc) && SIZEOF_VOID_P == 8
#define AS_OPTIONS "-xarch=v9"
+#elif defined(TARGET_X86) && defined(__APPLE__) &&
!defined(__native_client_codegen__)
+#define AS_OPTIONS "-arch i386 -W"
#else
#define AS_OPTIONS ""
#endif
@@ -6120,6 +6124,8 @@ compile_asm (MonoAotCompile *acfg)
command = g_strdup_printf ("gcc -dynamiclib -o %s %s.o", tmp_outfile_name,
acfg->tmpfname);
#elif defined(HOST_WIN32)
command = g_strdup_printf ("gcc -shared --dll -mno-cygwin -o %s %s.o",
tmp_outfile_name, acfg->tmpfname);
+#elif defined(TARGET_X86) && defined(__APPLE__) &&
!defined(__native_client_codegen__)
+ command = g_strdup_printf ("gcc -m32 -dynamiclib -o %s %s.o",
tmp_outfile_name, acfg->tmpfname);
#else
command = g_strdup_printf ("%sld %s %s -shared -o %s %s.o", tool_prefix,
EH_LD_OPTIONS, LD_OPTIONS, tmp_outfile_name, acfg->tmpfname);
#endif
diff --git a/mono/mini/aot-runtime.c b/mono/mini/aot-runtime.c
index 4bae87b..d27d44c 100644
--- a/mono/mini/aot-runtime.c
+++ b/mono/mini/aot-runtime.c
@@ -65,6 +65,8 @@
#define SHARED_EXT ".dll"
#elif ((defined(__ppc__) || defined(__powerpc__) || defined(__ppc64__)) ||
defined(__MACH__)) && !defined(__linux__)
#define SHARED_EXT ".dylib"
+#elif defined(__APPLE__) && defined(TARGET_X86) &&
!defined(__native_client_codegen__)
+#define SHARED_EXT ".dylib"
#else
#define SHARED_EXT ".so"
#endif
diff --git a/mono/mini/image-writer.c b/mono/mini/image-writer.c
index ff7e3d8..4a3cf02 100644
--- a/mono/mini/image-writer.c
+++ b/mono/mini/image-writer.c
@@ -113,7 +113,7 @@
#define USE_ELF_RELA 1
#endif
-#if defined(TARGET_X86) && !defined(TARGET_WIN32)
+#if defined(TARGET_X86) && !defined(TARGET_WIN32) && !defined(__APPLE__)
#define USE_ELF_WRITER 1
#endif
@@ -1576,7 +1576,7 @@ static void
asm_writer_emit_global (MonoImageWriter *acfg, const char *name, gboolean
func)
{
asm_writer_emit_unset_mode (acfg);
-#if (defined(__ppc__) && defined(TARGET_ASM_APPLE)) ||
(defined(HOST_WIN32) && !defined(MONO_CROSS_COMPILE))
+#if ((defined(__ppc__) || defined(TARGET_X86)) &&
defined(TARGET_ASM_APPLE)) || (defined(HOST_WIN32) &&
!defined(MONO_CROSS_COMPILE))
// mach-o always uses a '_' prefix.
fprintf (acfg->fp, "\t.globl _%s\n", name);
#else
@@ -1612,7 +1612,13 @@ static void
asm_writer_emit_label (MonoImageWriter *acfg, const char *name)
{
asm_writer_emit_unset_mode (acfg);
-#if defined(HOST_WIN32) && (defined(TARGET_X86) || defined(TARGET_AMD64))
+#if (defined(TARGET_X86) && defined(TARGET_ASM_APPLE))
+name = get_label(name);
+fprintf (acfg->fp, "%s:\n", name);
+if (name[0] != 'L')
+fprintf (acfg->fp, "_%s:\n", name);
+
+#elif (defined(HOST_WIN32) && (defined(TARGET_X86) ||
defined(TARGET_AMD64))) || (defined(TARGET_X86) &&
defined(TARGET_ASM_APPLE))
fprintf (acfg->fp, "_%s:\n", name);
#if defined(HOST_WIN32)
/* Emit a normal label too */
diff --git a/mono/mini/mini-x86.h b/mono/mini/mini-x86.h
index 260e557..385a930 100644
--- a/mono/mini/mini-x86.h
+++ b/mono/mini/mini-x86.h
@@ -285,7 +285,9 @@ typedef struct {
#define MONO_ARCH_MONITOR_OBJECT_REG X86_EAX
#endif
#define MONO_ARCH_HAVE_STATIC_RGCTX_TRAMPOLINE 1
+#if !defined (__APPLE__) || defined(__native_client_codegen__)
#define MONO_ARCH_HAVE_FULL_AOT_TRAMPOLINES 1
+#endif
#define MONO_ARCH_GOT_REG X86_EBX
#define MONO_ARCH_HAVE_GET_TRAMPOLINES 1
@@ -297,9 +299,7 @@ typedef struct {
#define MONO_ARCH_HAVE_DECOMPOSE_LONG_OPTS 1
-#if !defined(__APPLE__) || defined(__native_client_codegen__)
#define MONO_ARCH_AOT_SUPPORTED 1
-#endif
#if defined(__linux__) || defined(__sun)
#define MONO_ARCH_ENABLE_MONITOR_IL_FASTPATH 1
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Status of non-full AOT on x86 mac
I took another look at this today and ended up committing a patch to my github fork that enables --aot on x86 macs. http://github.com/blucz/mono/commit/fb96f5d6387cc5c019fc00bfc89a25204fa14166 It appears to work quite well--I was able to AOT compile a large (~0.5mloc) codebase on osx and cut startup time by 7x for my app. It would be great if you could review this and consider incorporating it into the mono mainline. Brian On Fri, Oct 29, 2010 at 12:24 AM, Zoltan Varga wrote: > Hi > > On Wed, Oct 27, 2010 at 7:41 PM, Brian Luczkiewicz wrote: > >> I have a cross-platform (osx+mono/ms.net) app that runs a large piece of >> generated code at startup--on windows, 95% of the runtime of this code is in >> the JIT compiler and ngen improves startup time for this app dramatically. I >> was hoping to try out --aot and potentially see a corresponding improvement >> in startup time on osx. >> >> Sadly, AOT is locked behind if !defined(__apple__) on x86, even on mono >> 2.8. >> >> So: >> >> 1. Are there plans to enable aot on x86 osx? >> >> > No plans, the x86 support was only implemented to support google native > client which requires aot even on x86. > > >> 2. If not, what work is required to get this done? I'm not opposed to >> getting my hands dirty. >> >> > Probably not much work is needed, but it requires knowledge about mono > internals and osx assembler/linker tools, so it won't be easy. > > Zoltan > > >> >> >> ___ >> 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-dev] Status of non-full AOT on x86 mac
I have a cross-platform (osx+mono/ms.net) app that runs a large piece of generated code at startup--on windows, 95% of the runtime of this code is in the JIT compiler and ngen improves startup time for this app dramatically. I was hoping to try out --aot and potentially see a corresponding improvement in startup time on osx. Sadly, AOT is locked behind if !defined(__apple__) on x86, even on mono 2.8. So: 1. Are there plans to enable aot on x86 osx? 2. If not, what work is required to get this done? I'm not opposed to getting my hands dirty. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
