Re: [Mono-dev] Long execution time on first execution (in AOT case)
On 08.06.10 16:58, Martin Däumler wrote: > thanks for your answer. That is a possible solution, but I want to use > as much infrastructure of Mono as possible. So, I decided to do a kind > of pre-compilation like it was intended do be done by > "mono_precompile_assemblies()" (mono/mini/driver.c)?! > > So I use a lot of AOT-code to pre-compile all referenced assemblies, > maybe in combination with the tool "monolinker" in order to reduce > overhead. While pre-compilation, the compiled code is inserted into > a mono-internal cache by "mono_jit_compile_method_inner()" > (mono/mini/mini.c). While executing the assembly, the pre-compiled > code is already in the cache and JIT-compilation is avoided. > > Unfortunately, there is a problem with icall-wrappers. I adapted the > code from "add_wrappers()" (mono/mini/aot-compiler.c) to use it in my > own pre-compilation code. This line: > > g_hash_table_foreach (mono_get_jit_icall_info > (),add_jit_icall_wrapper,acfg); > > is used to AOT-compile icall-wrappers. Icall-wrappers that are now > pre-compiled in scope of that code are not inserted into the > mono-internal hash correctly. Hello, I solved that problem in the meantime. In method "mono_icall_get_wrapper_full()" (mono/mini/mini.c), I call "mono_compile_method()" in order to pre-compile an icall-wrapper. Now, I want to do some quality tests. That is, I want to test if the JIT compiler is needed to execute an assembly, which C# keywords etc. are covered. I want to annotate the method(s) in question so that there is an output if the JIT compiler is needed. So, my question is: Is the method "mini_method_compile()" the only place in Mono that triggers the JIT compiler on that level? Is there way to trigger the JIT compiler that does not use the method "mini_method_compile()"? With kind regards, Martin Däumler ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Long execution time on first execution (in AOT case)
On Fri, Jul 9, 2010 at 4:06 AM, Martin Däumler wrote: > On 08.06.10 16:58, Martin Däumler wrote: > > > thanks for your answer. That is a possible solution, but I want to use > > as much infrastructure of Mono as possible. So, I decided to do a kind > > of pre-compilation like it was intended do be done by > > "mono_precompile_assemblies()" (mono/mini/driver.c)?! > > > > So I use a lot of AOT-code to pre-compile all referenced assemblies, > > maybe in combination with the tool "monolinker" in order to reduce > > overhead. While pre-compilation, the compiled code is inserted into > > a mono-internal cache by "mono_jit_compile_method_inner()" > > (mono/mini/mini.c). While executing the assembly, the pre-compiled > > code is already in the cache and JIT-compilation is avoided. > > > > Unfortunately, there is a problem with icall-wrappers. I adapted the > > code from "add_wrappers()" (mono/mini/aot-compiler.c) to use it in my > > own pre-compilation code. This line: > > > > g_hash_table_foreach (mono_get_jit_icall_info > > (),add_jit_icall_wrapper,acfg); > > > > is used to AOT-compile icall-wrappers. Icall-wrappers that are now > > pre-compiled in scope of that code are not inserted into the > > mono-internal hash correctly. > > > Hello, > > > I solved that problem in the meantime. In method > "mono_icall_get_wrapper_full()" (mono/mini/mini.c), I call > "mono_compile_method()" in order to pre-compile an icall-wrapper. > > Now, I want to do some quality tests. That is, I want to test if > the JIT compiler is needed to execute an assembly, which C# keywords > etc. are covered. I want to annotate the method(s) in question so > that there is an output if the JIT compiler is needed. > > So, my question is: Is the method "mini_method_compile()" the only > place in Mono that triggers the JIT compiler on that level? Is there > way to trigger the JIT compiler that does not use the method > "mini_method_compile()"? > > > No, there isn't. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight
I have built a successful gtk-sharp-2-12-branch mcs mono mono-addins mono-basic moon from:: co svn://anonsvn.mono-project.com/source/trunk/ but on the monodevelop I get errors: This error: ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,50): error CS0584: Internal compiler error: base call hoisting ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,25): error CS1579: foreach statement cannot operate on variables of type `object' because it does not contain a definition for `GetEnumerator' or is not accessible has been posted here (by someone): http://monobin.com/__m5e90fc9c I came across the same issue. (so doesn't appear to be unique to my build/environment) I "fixed" it, by: changing in AspProjectDom.cs // created GetInheritanceTree2 in ProjectDomDecorator.cs (copy of GetInheritanceTree, but no override). public override System.Collections.Generic.IEnumerable GetInheritanceTree (IType type) { foreach (IType t in (IEnumerable )(base.GetInheritanceTree2) (type)) { yield return CheckType (t); } } The same "base call hoisting" error also occurs for MoonlightFrameworkBackend.cs // where again I create a GetToolsPaths2 from the bases GetToolsPaths public override IEnumerable GetToolsPaths () { foreach (var f in GetFrameworkFolders ()) yield return f; foreach (var f in base.GetToolsPaths2 ()) yield return f; } Now monodevelop builds successfully. The error "hoisting" or "base call hoisting" and other derivatives , doesn't get much useful return by googling. I don't see any reason why the compiler doesn't like it, but there may be some deep routed reason? It doesn't appear the error name/description is useful. I am guessing there is a better name/description that could be used? that would create a valuable return of info from googling? For my own education, what is "base call hoisting"? perhaps with some more info I can get some useful google hits. Now the fix above, may not have even been a useful cludge? As I still have to cludge my MD Moonlight project to build sucessfully. (the default project). If i create a new Moonlight app in MD, when I build the first time I get: - Building: testmoon2 (Debug) Performing main compilation... Generating codebehind accessors for App.xaml... Generating codebehind accessors for Page.xaml... Packing resources... Unhandled Exception: System.ArgumentException: Path is empty at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x0] in :0 at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x0] in :0 at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.IO.File.OpenRead (System.String path) [0x0] in :0 at ResourcePacker.Pack (System.Collections.Generic.List`1 files) [0x0] in :0 at ResourcePacker.Main (System.String[] args) [0x0] in :0 Build complete -- 1 error, 0 warnings -- Done -- Build: 1 error, 0 warnings -- build it again, and it is successful! (just at building, app doesn't run) (error in checking deps.?), but it created a 0 size testmoon2.g.resources file if I manually at shell: xamlg -sl2app:testmoon2.dll Page.xaml,Page.xaml.g.cs respack obj/Debug/testmoon2.g.resources App.xaml,App.xaml Page.xaml,Page.xaml then "run" in MD I get a sucessfully running Moonlight plugin showing in my browser. Since the "hoist" error effects the GetToolsPath in Moonlight (in MD), it may be the reason for my MD moonlight build issue. If not, then there seems to be two seperate issues. The fact that MD errors once, then not the next time, and "appears" to generate a successful moonlight app, only to have to give a "blank" plugin (in browser), probably isn't correct behavior, even if I somehow F'd up my install? (check for empty *.g.resources file?) (but I like to think I did the install like anyone else would have). -- ted leslie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight
On Fri, Jul 9, 2010 at 5:31 PM, ted leslie wrote: > I have built a successful > > gtk-sharp-2-12-branch > mcs > mono > mono-addins > mono-basic > moon > > from:: co svn://anonsvn.mono-project.com/source/trunk/ > > but on the monodevelop I get errors: > > This error: > > ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,50): error CS0584: Internal > compiler error: base call hoisting > ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,25): error CS1579: foreach > statement cannot operate on variables of type `object' because it does not > contain a definition for `GetEnumerator' or is not accessible [trimmed] > Since the "hoist" error effects the GetToolsPath in Moonlight (in MD), it > may be the reason for my > MD moonlight build issue. If not, then there seems to be two seperate issues. > The fact that MD errors once, then not the next time, and "appears" to > generate a successful moonlight > app, only to have to give a "blank" plugin (in browser), probably isn't > correct behavior, even if I > somehow F'd up my install? (check for empty *.g.resources file?) > (but I like to think I did the install like anyone else would have). The root of the problem is a C# compiler bug ("Internal error") in mcs trunk. It's likely there other issues are knock-on effects - maybe your workaround is returning bad values. -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight
I ran into this last weekend. It's a regression in the compiler. I was going to send a patch in Monday, but somebody on the mono team already did. I believe it's on monobin. They posted it on IRC, but I guess nobody has applied it yet. What you need to do is move the base calls into their own method and call that method for the base hoist error. Michael if you need a link to the patch, just let me know and I will post it. I don't have it on hand right now. Thanks, Dale On Jul 9, 2010, at 5:53 PM, Michael Hutchinson wrote: > On Fri, Jul 9, 2010 at 5:31 PM, ted leslie wrote: >> I have built a successful >> >> gtk-sharp-2-12-branch >> mcs >> mono >> mono-addins >> mono-basic >> moon >> >> from:: co svn://anonsvn.mono-project.com/source/trunk/ >> >> but on the monodevelop I get errors: >> >> This error: >> >> ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,50): error CS0584: >> Internal compiler error: base call hoisting >> ./MonoDevelop.AspNet.Gui/AspProjectDom.cs(91,25): error CS1579: >> foreach statement cannot operate on variables of type `object' >> because it does not contain a definition for `GetEnumerator' or is >> not accessible > [trimmed] >> Since the "hoist" error effects the GetToolsPath in Moonlight (in >> MD), it may be the reason for my >> MD moonlight build issue. If not, then there seems to be two >> seperate issues. >> The fact that MD errors once, then not the next time, and "appears" >> to generate a successful moonlight >> app, only to have to give a "blank" plugin (in browser), probably >> isn't correct behavior, even if I >> somehow F'd up my install? (check for empty *.g.resources file?) >> (but I like to think I did the install like anyone else would have). > > The root of the problem is a C# compiler bug ("Internal error") in mcs > trunk. It's likely there other issues are knock-on effects - maybe > your workaround is returning bad values. > > -- > Michael Hutchinson > http://mjhutchinson.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
Re: [Mono-dev] base call hoisting (error) and MonoDevelop w/Moonlight
Hello, > I ran into this last weekend. It's a regression in the compiler. I > was going to send a patch in Monday, but somebody on the mono team > already did. I believe it's on monobin. They posted it on IRC, but I > guess nobody has applied it yet. > It's not really regression, gmcs produced invalid IL for such construct which I have discovered recently and until I implement this feature gmcs reports ICE instead of generating invalid IL. > What you need to do is move the base calls into their own method and > call that method for the base hoist error. > Correct, the workaround is simple. Just move the call into a method Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] PATCH: Don't suspend Mach exception thread when stopping the world
The mono_sgen_is_worker_thread() will be needed soon when SGen actually uses worker threads, for parallel mark and concurrent sweep. Please review, Geoff. Mark sgen-darwin-exception-thread 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] PATCH: Don't suspend Mach exception thread when stopping the world
Looks fine to me. Thanks Mark -g On 2010-07-09, at 6:51 PM, Mark Probst wrote: > The mono_sgen_is_worker_thread() will be needed soon when SGen > actually uses worker threads, for parallel mark and concurrent sweep. > > Please review, Geoff. > > Mark > ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list