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
