Skip to content

MonoNotes

Jump to bottom Edit New page
Felix S. Klock II edited this page Jul 28, 2013 · 2 revisions

( see also CommonLarcenyNotes )

Architecture Tests:

  • Sparc: untested
  • PPC: fails during initial startup; stacktrace is a bit scary.
  • IA32:
  • works on Linux (artichoke).
  • Felix has not yet tested Mono/IA32 on Windows though.
  • Somethings going wrong with the preprocessing step for (build-runtime-system) on Poblano, but Felix does not think it is a fundamental bug.
  • A (hopefully short term) workaround is to copy the SchemeObject.cs file off of artichoke and onto poblano.

src/Build/dotnet.sch Notes

Currently, to build on mono, you need to pass the options 'mono 'clr-2.0 to the larceny-setup procedure. So for example, on Linux hosting atop Larceny Felix does:


> (larceny-setup "Larceny" 'unix 'little 'mono 'clr-2.0)
  • The other steps are the same as documented in the CommonLarceny manual.

> (load-compiler)
> (make-dotnet-heap)
> (build-runtime-system)
  • I'm pretty sure that we are depending on using CLR 2.0 features across the board, so I will probably make 'clr-2.0 the default (as opposed to the current default of 'clr-1.1) so that we would not have to pass that flag any more.
  • Other flags that I think are worth adding to the above:
  • 'insert-use-fuel (so that we get better behaved timer interrupts)
  • 'ilasm-debug (so that we invoke ilasm with the debug flag. Not yet sure how worthwhile this is.

dotnet.heap.exe (CommonLarceny.exe) Notes

Then, when you want to run the dotnet.heap.exe executable, you currently need to pass a flag telling it to use the .NET 2.0 compatible runtime:


% mono --runtime=v2.0.50727 dotnet.heap.exe
  • Felix doesn't understand why the Mono folks didn't code the --runtime option to accept v2.0 as a synonym for v2.0.50727, but they didn't, so you really do need to pass a full version number up there.
  • Felix wants to fix things so that the --runtime option is not required; he just isn't sure how to do it yet.
  • The way to do it is to use the ilasm2 program to assemble the generated il files rather than ilasm. I do not yet know if there is also an ilasm2 program in Microsoft's .NET SDK.
  • But either way, this is now a reasonably straight-forward thing to conditionalize on (codegen-option 'clr-2.0).
  • This is no longer a problem; see changeset:4689.

JavaDot notes

The enable-dotnet! procedure does not work yet. When I invoke it, I get an exception with the following stack trace:


> (enable-dotnet!)

Initializing dotnet 2.0.50727.42 .......** called Exn.error (string) ffi:invoke: error in foreign function: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: enumType is not an Enum type.
  at System.Enum.GetNames (System.Type enumType) [0x00000] 
  at <0x00000> 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[])
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] --- End of inner exception stack trace ---

  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] 
  at Scheme.RT.FFI.ffi_syscall_main (Int32 code) [0x00000] 
** called Exn.error (string) exception in ffi: Scheme.RT.SchemeCallException: Exception of type Scheme.RT.SchemeCallException was thrown.
  at Scheme.RT.Call.call1 (Scheme.Rep.Procedure p, Int32 argc) [0x00000] 
  at Scheme.RT.Call.callExceptionHandler (Scheme.Rep.SObject[] values) [0x00000] 
  at Scheme.RT.Exn.error (System.String msg) [0x00000] 
  at Scheme.RT.FFI.ffi_syscall_main (Int32 code) [0x00000] 
  at Scheme.RT.FFI.ffi_syscall () [0x00000] 


Error: exception in ffi: Scheme.RT.SchemeCallException: Exception of type Scheme.RT.SchemeCallException was thrown.
  at Scheme.RT.Call.call1 (Scheme.Rep.Procedure p, Int32 argc) [0x00000] 
  at Scheme.RT.Call.callExceptionHandler (Scheme.Rep.SObject[] values) [0x00000] 
  at Scheme.RT.Exn.error (System.String msg) [0x00000] 
  at Scheme.RT.FFI.ffi_syscall_main (Int32 code) [0x00000] 
  at Scheme.RT.FFI.ffi_syscall () [0x00000] 
Entering debugger; type "?" for help.
debug> q

>
  • Felix does not really enjoy working with JavaDot anyway, so he is not going to make fixing this a priority.

TeachPack and Demo notes

  • First, see note above; (enable-dotnet!) does not work, and so event-handling-demo2.sch does not work.
  • Also, the TeachPacks also had a type mismatch problem that Mono's runtime exposed; filed as Ticket #464.

WinForms Notes

Also, it looks like some "standard" libraries like System.Windows.Forms are not available unless one builds with the option -pkg:dotnet. Felix will look into making this part of the standard Mono build.

  • This hypothesis was not correct; the problem is unrelated to the -pkg:dotnet option (which does not even work on OS X).
  • It seems that Microsoft's .NET runtime just automatically loads the System.Windows related assemblies when you start its runtime. Mono does not do this.
  • However, one can still load the assembly manually; to make this less painful, I added a dotnet syscall for loading named assemblies; see changeset:4692 and changeset:4693.
  • With this syscall in place, one can load up WinForms with the following expression: (clr/%load-assembly "System.Windows.Forms" "2.0.0.0" "" "b77a5c561934e089")
  • You can find this info with the gacutil program, e.g.:

% gacutil -l System.Windows.Forms
The following assemblies are installed into the GAC:
System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Number of items = 1

Performance Notes

Mono seems to take a long long time to get through the steps after it prints In interactive-entry-point. Felix will spend some idle cycles attempting to profile the code to determine where that time is going.

  • Here's a timed run on artichoke:

% time mono dotnet.heap.exe -e "(exit)"
CommonLarceny
CLR, Version=2.0.50727.42
Scheme, Version=0.93.2774.20333, Culture=neutral
dotnet.heap, Version=0.0.0.0, Culture=neutral

real 320.13
user 318.07
sys 0.91
  • Mono's own profiler says that it is spending >10 minutes on artichoke doing JIT-compilation of the big procedure in Will's new reader implementation.
  • (Felix turned the peephole optimizations back on and this stat dropped down to 5 minutes; so further peepholes might be sufficient to get us to a reasonable start up time.)
  • Here's the (start of the) output from Mono's profiler (activated via the --profile option):

% mono --profile dotnet.heap.exe -e "(exit)"
CommonLarceny
CLR, Version=2.0.50727.42
Scheme, Version=0.93.2774.20333, Culture=neutral
dotnet.heap, Version=0.0.0.0, Culture=neutral

Total time spent compiling 28582 methods (sec): 376.1
Slowest method to compile (sec): 301.6: ns_src_lib_common_reader_784c62.CodeVector_12_1::call(int)
...
  • Adding a new peephole to replace load 1,1; load 2,2; ...; load k,k with loadm k cuts out another minute of JIT time:

Total time spent compiling 28582 methods (sec): 317.4
Slowest method to compile (sec): 242.7: ns_src_lib_common_reader_8724c62.CodeVector_12_1::call(int)
  • Adding another peephole to replace save k; store 0,0; store 1,1; ...; store k,k with save/storem k cuts out maybe 45 or 50 seconds:

Total time spent compiling 28582 methods (sec): 269.5
Slowest method to compile (sec): 195.3: ns_src_lib_common_reader_4318c62.CodeVector_12_1::call(int)
Add a custom footer
Add a custom sidebar
Clone this wiki locally