Re: [Mono-dev] [PATCH] Generic sharing: Static field access
Hey! I don't really understand why a new trampoline is needed here. Since the argument to the trampoline is dynamic, it is not possible to patch the caller code, so a normal call to mono_runtime_class_init () would be sufficient. To be honest, I don't see any reason why we shouldn't use an icall in those cases. For some reason we defaulted to the trampoline, but it doesn't seem to be necessary. Paolo? Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Generic sharing: Static field access
On 11/19/07 Mark Probst wrote: I don't really understand why a new trampoline is needed here. Since the argument to the trampoline is dynamic, it is not possible to patch the caller code, so a normal call to mono_runtime_class_init () would be sufficient. To be honest, I don't see any reason why we shouldn't use an icall in those cases. For some reason we defaulted to the trampoline, but it doesn't seem to be necessary. The new trampoline is not strictly essential to get the code working, but it is needed to not make it too slow (we have the same perf issue with AOT code). The new trampoline code would be a singleton and passing the argument in a register allows it to be just: deref vtable-initialized compare/and ret branch to icall so basically just 4-5 instructions executed in the common case instead of all the cost of going to unmanaged and back. There is an alternative solution which we could implement as well, though this requires one additional pointer per MonoVTable. When the MonoVTable is created this pointer is set to the icall and once the type is initialized it is set to a tiny function that just does: ret With this the initialization becomes a memory dereference and an indirect call+ret. The runtime cost is similar to the above solution (in AOT code we'd even avoid a PLT call), but it has the additional memory overhead. Other suggestions for optimizing this codepath are welcome as well. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Generic sharing: Static field access
Hi, A simpler solution would be to emit the code below inline instead of making a call to a trampoline at all. Zoltan deref vtable-initialized compare/and ret branch to icall so basically just 4-5 instructions executed in the common case instead of all the cost of going to unmanaged and back. There is an alternative solution which we could implement as well, though this requires one additional pointer per MonoVTable. When the MonoVTable is created this pointer is set to the icall and once the type is initialized it is set to a tiny function that just does: ret With this the initialization becomes a memory dereference and an indirect call+ret. The runtime cost is similar to the above solution (in AOT code we'd even avoid a PLT call), but it has the additional memory overhead. Other suggestions for optimizing this codepath are welcome as well. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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] [PATCH] Generic sharing: Static field access
On 11/19/07 Zoltan Varga wrote: A simpler solution would be to emit the code below inline instead of making a call to a trampoline at all. This moves the memory overhead at the callsite, increasing icache footprint (we're talking about 10 bytes for x86 and 16+ bytes for other architectures). This means about 4 KB more code for mscorlib and 24 KB for a mcs compile (we should investigate what's up with mcs, though: the number of class inits we insert seems excessive). The trampoline would instead be shared between all the types in both generics and AOT (and there is a single conditional branch in the whole process instead of hundreds scattered around, saving also on the needed branch predictor resources). Inlining the check also means introducing additional basic blocks, making the existing ones smaller, which can have other side effects on the quality of the generated code. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Generic sharing: Static field access
Hi, The problem with the trampoline is that since the class to init is dynamically decided, there is nothing to patch, so all calls will go through the generic trampoline code, which is much slower than a simple managed-to-native transition. Zoltan On Nov 19, 2007 7:25 PM, Paolo Molaro [EMAIL PROTECTED] wrote: On 11/19/07 Zoltan Varga wrote: A simpler solution would be to emit the code below inline instead of making a call to a trampoline at all. This moves the memory overhead at the callsite, increasing icache footprint (we're talking about 10 bytes for x86 and 16+ bytes for other architectures). This means about 4 KB more code for mscorlib and 24 KB for a mcs compile (we should investigate what's up with mcs, though: the number of class inits we insert seems excessive). The trampoline would instead be shared between all the types in both generics and AOT (and there is a single conditional branch in the whole process instead of hundreds scattered around, saving also on the needed branch predictor resources). Inlining the check also means introducing additional basic blocks, making the existing ones smaller, which can have other side effects on the quality of the generated code. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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] 1.2.6 Preview 2 status...
Hey Guys, We just finished our test runs on 1.2.6p2. Here's the list of bugs that we'd like to look at fixing for Mono 1.2.6p3. [Unsure of the culprit] https://bugzilla.novell.com/show_bug.cgi?id=342507 [Packaging] https://bugzilla.novell.com/show_bug.cgi?id=323555 [Packaging] https://bugzilla.novell.com/show_bug.cgi?id=342572 [gmcs] https://bugzilla.novell.com/show_bug.cgi?id=342584 [Runtime] https://bugzilla.novell.com/show_bug.cgi?id=341112 [HttpWebRequest] https://bugzilla.novell.com/show_bug.cgi?id=342533 [Sys.Core] https://bugzilla.novell.com/show_bug.cgi?id=342890 [Winforms] https://bugzilla.novell.com/show_bug.cgi?id=342504 [Winforms] https://bugzilla.novell.com/show_bug.cgi?id=342568 [Winforms] https://bugzilla.novell.com/show_bug.cgi?id=342122 [Winforms] https://bugzilla.novell.com/show_bug.cgi?id=342123 342507 is quite weird. It does not happen on 1.2.5.1, and I don't remember it happening on 1.2.6p1 either (however, I may have installed the c/c++ pattern for another reason). It is clearly not a MonoDevelop bug, but since I have no idea what's causing it, I haven't moved it yet. Could someone please take a look at it? Thanks, Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Bug Counts 11-16-07...
Hey Miguel, Miguel de Icaza wrote: This is an interesting list; I wonder if it would be easy to get a list along with these status reports of the new bugs filed during the week, it might help give them some visibilit. Hmm, I just found a way to get a list of filed bugs between certain dates. Unfortunately, you can't use relative dates, so I can't add this to /Bugs. I'll start adding this to my bug count e-mails. Here's the list of bugs filed last week (it looks like it was about 60 new bugs): https://bugzilla.novell.com/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=fulltextlong_desc=classification=Monoproduct=Mono%3A+Class+Libraries+product=Mono%3A+Compilersproduct=Mono%3A+Debuggerproduct=Mono%3A+Doctoolsproduct=Mono%3A+Runtimeproduct=Mono%3A+Toolsbug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=anywordskeywords=deadlinefrom=deadlineto=emailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailqa_contact2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=creation_tstype0-0-0=greaterthanvalue0-0-0=2007-11-9field0-1-0=creation_tstype0-1-0=lessthanvalue0-1-0=2007-11-17 Thanks for the suggestion, Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
