Re: [Mono-dev] xsp2 crashes
Hi, > I'm using mono 1.2.3.1 on RedHat EL 3.0, so is it possible to find an > RPM to upgrade it to 1.9? You could use the rpms in Fedora Rawhide (2.0RC1). You won't be able to upgrade to 1.9 directly as you'll also need mono-1.9 installed (afterall, xsp2 is built for RH/Fedora using 1.9) TTFN Paul Fedora Packager -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Not sure where the problem is here (building nclass 1.09)
Hi, I'm building nclass against Mono2.0RC1 on my Fedora rawhide box and have hit a problem Buildfile: file:///home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Translations.build Target framework: Mono 2.0 Profile Target(s) specified: compile compile: [csc] Compiling 2 files to '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll'. [resgen] Read in 292 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.es.resx' [resgen] Writing resource file... Done. [resgen] Read in 294 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.hu.resx' [resgen] Writing resource file... Done. [resgen] Read in 261 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.pt-BR.resx' [resgen] Writing resource file... Done. [resgen] Read in 293 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.resx' [resgen] Writing resource file... Done. [resgen] Read in 293 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.ru.resx' [resgen] Writing resource file... Done. [al] Compiling 1 files to '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/es/NClass.Translations.resources.dll'. [al] ** (/usr/lib/mono/1.0/al.exe:25819): WARNING **: Missing method .ctor in assembly /home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll, type System.Runtime.CompilerServices.RuntimeCompatibilityAttribute [al] ** (/usr/lib/mono/1.0/al.exe:25819): WARNING **: The class System.Runtime.CompilerServices.RuntimeCompatibilityAttribute could not be loaded, used in NClass.Translations [al] ** (/usr/lib/mono/1.0/al.exe:25819): WARNING **: Can't find custom attr constructor image: /home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll mtoken: 0x0a23 [al] Unhandled Exception: System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.RuntimeCompatibilityAttribute' from assembly 'NClass.Translations'. [al] at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) [al] at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x0] [al] at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x0] [al] at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, Boolean inherit) [0x0] [al] at System.Reflection.Assembly.GetCustomAttributes (Boolean inherit) [0x0] [al] at Mono.AssemblyLinker.AssemblyLinker.DoIt () [0x0] [al] at Mono.AssemblyLinker.AssemblyLinker.DynMain (System.String[] args) [0x0] [al] at Mono.AssemblyLinker.AssemblyLinker.Main (System.String[] args) [0x0] BUILD FAILED - 0 non-fatal error(s), 12 warning(s) External Program Failed: /usr/lib/mono/1.0/al.exe (return code was 1) Is this a mono problem or something up elsewhere? The first error certainly looks to be from one of the libraries. TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Fwd: Not sure where the problem is here (building nclass 1.09)
Forgot to copy the list. Sorry -- Forwarded message -- From: Rafael Teixeira <[EMAIL PROTECTED]> Date: Thu, Sep 25, 2008 at 1:48 PM Subject: Re: [Mono-dev] Not sure where the problem is here (building nclass 1.09) To: [EMAIL PROTECTED] nant is calling /usr/lib/mono/1.0/al.exe it should be calling /usr/lib/mono/2.0/al.exe to effect that please change the nant.exe.config from al true to al2 true in both Mono-2.0 sections :) On Thu, Sep 25, 2008 at 1:39 PM, Rafael Teixeira <[EMAIL PROTECTED]> wrote: > Oops, you are telling nant to use 2.0, but it is still calling the compiler > without telling to look into the 2.0 corlib. Some changes about that area > happened in the compiler and nant may need to be adjusted. > > > On Thu, Sep 25, 2008 at 1:37 PM, Rafael Teixeira <[EMAIL PROTECTED]>wrote: > >> you need to force nant to use the 2.0 profile. it is using 1.0 that >> doesn't have this attribute. >> >> :) >> >> 2008/9/25 Paul <[EMAIL PROTECTED]> >> >>> Hi, >>> >>> I'm building nclass against Mono2.0RC1 on my Fedora rawhide box and have >>> hit a problem >>> >>>Buildfile: >>> >>> file:///home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Translations.build >>>Target framework: Mono 2.0 Profile >>>Target(s) specified: compile >>> >>>compile: >>> >>> [csc] Compiling 2 files to >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll'. >>> [resgen] Read in 292 resources from >>> >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.es.resx' >>> [resgen] Writing resource file... Done. >>> [resgen] Read in 294 resources from >>> >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.hu.resx' >>> [resgen] Writing resource file... Done. >>> [resgen] Read in 261 resources from >>> >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.pt-BR.resx' >>> [resgen] Writing resource file... Done. >>> [resgen] Read in 293 resources from >>> >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.resx' >>> [resgen] Writing resource file... Done. >>> [resgen] Read in 293 resources from >>> >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.ru.resx' >>> [resgen] Writing resource file... Done. >>> [al] Compiling 1 files to >>> >>> '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/es/NClass.Translations.resources.dll'. >>> [al] ** (/usr/lib/mono/1.0/al.exe:25819): >>> WARNING **: Missing method .ctor in >>> assembly >>> /home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll, type >>> System.Runtime.CompilerServices.RuntimeCompatibilityAttribute >>> [al] ** (/usr/lib/mono/1.0/al.exe:25819): >>> WARNING **: The class >>> System.Runtime.CompilerServices.RuntimeCompatibilityAttribute could not >>> be loaded, used in NClass.Translations >>> [al] ** (/usr/lib/mono/1.0/al.exe:25819): >>> WARNING **: Can't find custom attr constructor >>> image: >>> /home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll >>> mtoken: 0x0a23 >>> [al] Unhandled Exception: >>> System.TypeLoadException: Could not load type >>> 'System.Runtime.CompilerServices.RuntimeCompatibilityAttribute' from >>> assembly 'NClass.Translations'. >>> [al] at (wrapper managed-to-native) >>> System.MonoCustomAttrs:GetCustomAttributesInternal >>> (System.Reflection.ICustomAttributeProvider,System.Type,bool) >>> [al] at >>> System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider >>> obj, System.Type attributeType) [0x0] >>> [al] at >>> System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider >>> obj, System.Type attributeType, Boolean inherit) [0x0] >>> [al] at >>> System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider >>> obj, Boolean inherit) [0x0] >>> [al] at >>> System.Reflection.Assembly.GetCustomAttributes (Boolean inherit) >>> [0x0] >>> [al] at >>> Mono.AssemblyLinker.AssemblyLinker.DoIt () [0x0] >>> [al] at >>> Mono.AssemblyLinker.AssemblyLinker.DynMain (System.String[] args) >>> [0x0] >>> [al] at >>> Mono
[Mono-dev] Patch: Fast virtual generic method calls
Hey everybody,
This is my second attempt at implementing fast virtual generic method
calls. The implementation is very close to Paolo's proposal here:
https://bugzilla.novell.com/show_bug.cgi?id=324481
The main difference is that I don't hash the methods into slots but use
the (until now unused) "normal" vtable slots for the thunks. This is
necessary because with generic code sharing the method signature is not
known statically.
A big problem with this implementation is the memory management of the
thunks. Since thunks become obsolete when new method instantiations are
added we have to reclaim their memory. We can only do this safely if we
know that no thread is still executing the thunk code. The current
solution is a hack: Freed thunks are queued until there are 50 of them,
at which point for each new freed thunk we reclaim the oldest one in the
queue. The other problem with this approach is that if there are only a
few thunks which grow and grow we won't be able to reuse the freed small
pieces, i.e. a program can easily make us use an arbitrary amount of
memory by having a single virtual generic method which is instantiated
with a large number of different type arguments (easy to do
recursively).
One solution I have to the latter issue is by splitting the thunks into
small fixed-size code pieces, in the simplest case one piece per
decision-tree node. Not difficult to implement. Another solution would
be to have a code manager which permits freeing items :-)
The patch currently only supports x86.
Mark
Index: metadata/domain.c
===
--- metadata/domain.c (revision 114081)
+++ metadata/domain.c (working copy)
@@ -1971,6 +1971,10 @@
g_hash_table_destroy (domain->method_code_hash);
domain->method_code_hash = NULL;
}
+ if (domain->generic_virtual_cases) {
+ g_hash_table_destroy (domain->generic_virtual_cases);
+ domain->generic_virtual_cases = NULL;
+ }
DeleteCriticalSection (&domain->assemblies_lock);
DeleteCriticalSection (&domain->jit_code_hash_lock);
Index: metadata/object.c
===
--- metadata/object.c (revision 114081)
+++ metadata/object.c (working copy)
@@ -35,6 +35,7 @@
#include "mono/metadata/mono-debug-debugger.h"
#include
#include
+#include
#ifdef HAVE_BOEHM_GC
#define NEED_TO_ZERO_PTRFREE 1
@@ -1049,8 +1050,8 @@
}
entry = malloc (sizeof (MonoImtBuilderEntry));
- entry->method = method;
- entry->vtable_slot = vtable_slot;
+ entry->key = method;
+ entry->value.vtable_slot = vtable_slot;
entry->next = imt_builder [imt_slot];
if (imt_builder [imt_slot] != NULL) {
entry->children = imt_builder [imt_slot]->children + 1;
@@ -1092,7 +1093,7 @@
MonoImtBuilderEntry *e1 = *(MonoImtBuilderEntry**) p1;
MonoImtBuilderEntry *e2 = *(MonoImtBuilderEntry**) p2;
- return (e1->method < e2->method) ? -1 : ((e1->method > e2->method) ? 1 : 0);
+ return (e1->key < e2->key) ? -1 : ((e1->key > e2->key) ? 1 : 0);
}
static int
@@ -1104,8 +1105,8 @@
int i;
for (i = start; i < end; ++i) {
MonoIMTCheckItem *item = g_new0 (MonoIMTCheckItem, 1);
- item->method = sorted_array [i]->method;
- item->vtable_slot = sorted_array [i]->vtable_slot;
+ item->key = sorted_array [i]->key;
+ item->value = sorted_array [i]->value;
item->is_equals = TRUE;
if (i < end - 1)
item->check_target_idx = out_array->len + 1;
@@ -1117,7 +1118,7 @@
int middle = start + count / 2;
MonoIMTCheckItem *item = g_new0 (MonoIMTCheckItem, 1);
- item->method = sorted_array [middle]->method;
+ item->key = sorted_array [middle]->key;
item->is_equals = FALSE;
g_ptr_array_add (out_array, item);
imt_emit_ir (sorted_array, start, middle, out_array);
@@ -1154,13 +1155,14 @@
if (imt_builder_entry != NULL) {
if (imt_builder_entry->children == 0) {
/* No collision, return the vtable slot contents */
- return vtable->vtable [imt_builder_entry->vtable_slot];
+ return vtable->vtable [imt_builder_entry->value.vtable_slot];
} else {
/* Collision, build the thunk */
GPtrArray *imt_ir = imt_sort_slot_entries (imt_builder_entry);
gpointer result;
int i;
- result = imt_thunk_builder (vtable, domain, (MonoIMTCheckItem**)imt_ir->pdata, imt_ir->len);
+ result = imt_thunk_builder (vtable, domain,
+(MonoIMTCheckItem**)imt_ir->pdata, imt_ir->len, NULL);
for (i = 0; i < imt_ir->len; ++i)
g_free (g_ptr_array_index (imt_ir, i));
g_ptr_array_free (imt_ir, TRUE);
@@ -1294,6 +1296,203 @@
mono_domain_unlock (vtable->domain);
}
+
+/*
+ * The first two free list entries both belong to the wait list: The
+ * first entry is the pointer to the head of the list and the second
+ * entry points to the last element. That way appending and removing
+ * the first element are both O(1) operations.
+ */
+#define NUM_FREE_LISTS 12
+#define FIRST_FREE_LIST_SIZE 64
+#define MAX_WAIT_LENGTH 50
+
+/*
+ * LOCKING: The
[Mono-dev] How to: Run tar command from c# app
Hi all, How would I run a tar command from a c# app on mono (1.9.1) on Debian? Would I use the Process and ProcessStartInfo object? My time is short so any help would be greatly appreciated. Thanks, Ebonnett -- View this message in context: http://www.nabble.com/How-to%3A-Run-tar-command-from-c--app-tp19675227p19675227.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
Re: [Mono-dev] How to: Run tar command from c# app
On Thu, Sep 25, 2008 at 2:05 PM, ebonnett <[EMAIL PROTECTED]> wrote: > > Hi all, > > How would I run a tar command from a c# app on mono (1.9.1) on Debian? > Would I use the Process and ProcessStartInfo object? Yes, you would. There are a number of examples floating around the net, including the mailing list archives. -- 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] Fwd: Not sure where the problem is here (building nclass 1.09)
Rafael, Paul is actually using an old version of NAnt. More recent versions support al2 out of the box. Gert From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafael Teixeira Sent: donderdag 25 september 2008 19:02 To: mono-devel-list Subject: [Mono-dev] Fwd: Not sure where the problem is here (building nclass 1.09) Forgot to copy the list. Sorry -- Forwarded message -- From: Rafael Teixeira <[EMAIL PROTECTED]> Date: Thu, Sep 25, 2008 at 1:48 PM Subject: Re: [Mono-dev] Not sure where the problem is here (building nclass 1.09) To: [EMAIL PROTECTED] nant is calling /usr/lib/mono/1.0/al.exe it should be calling /usr/lib/mono/2.0/al.exe to effect that please change the nant.exe.config from al true to al2 true in both Mono-2.0 sections :) On Thu, Sep 25, 2008 at 1:39 PM, Rafael Teixeira <[EMAIL PROTECTED]> wrote: Oops, you are telling nant to use 2.0, but it is still calling the compiler without telling to look into the 2.0 corlib. Some changes about that area happened in the compiler and nant may need to be adjusted. On Thu, Sep 25, 2008 at 1:37 PM, Rafael Teixeira <[EMAIL PROTECTED]> wrote: you need to force nant to use the 2.0 profile. it is using 1.0 that doesn't have this attribute. :) 2008/9/25 Paul <[EMAIL PROTECTED]> Hi, I'm building nclass against Mono2.0RC1 on my Fedora rawhide box and have hit a problem Buildfile: file:///home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Translations.build Target framework: Mono 2.0 Profile Target(s) specified: compile compile: [csc] Compiling 2 files to '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll'. [resgen] Read in 292 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.es.resx' [resgen] Writing resource file... Done. [resgen] Read in 294 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.hu.resx' [resgen] Writing resource file... Done. [resgen] Read in 261 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.pt-BR.resx' [resgen] Writing resource file... Done. [resgen] Read in 293 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.resx' [resgen] Writing resource file... Done. [resgen] Read in 293 resources from '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/src/Translations/Strings.ru.resx' [resgen] Writing resource file... Done. [al] Compiling 1 files to '/home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/es/NClass.Translations.resources.dll'. [al] ** (/usr/lib/mono/1.0/al.exe:25819): WARNING **: Missing method .ctor in assembly /home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll, type System.Runtime.CompilerServices.RuntimeCompatibilityAttribute [al] ** (/usr/lib/mono/1.0/al.exe:25819): WARNING **: The class System.Runtime.CompilerServices.RuntimeCompatibilityAttribute could not be loaded, used in NClass.Translations [al] ** (/usr/lib/mono/1.0/al.exe:25819): WARNING **: Can't find custom attr constructor image: /home/paul/rpmbuild/BUILD/NClass_v1.09_src/bin/NClass.Translations.dll mtoken: 0x0a23 [al] Unhandled Exception: System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.RuntimeCompatibilityAttribute' from assembly 'NClass.Translations'. [al] at (wrapper managed-to-native) System.MonoCustomAttrs:GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) [al] at System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) [0x0] [al] at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) [0x0] [al] at System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, Boolean inherit) [0x0] [al] at System.Reflection.Assembly.GetCustomAttributes (Boolean inherit) [0x0] [al] at Mono.AssemblyLinker.AssemblyLinker.DoIt () [0x0] [al] at Mono.AssemblyLinker.AssemblyLinker.DynMain (System.String[] args) [0x0]
Re: [Mono-dev] How to: Run tar command from c# app
2008/9/25 Michael Hutchinson <[EMAIL PROTECTED]>: > On Thu, Sep 25, 2008 at 2:05 PM, ebonnett <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> How would I run a tar command from a c# app on mono (1.9.1) on Debian? >> Would I use the Process and ProcessStartInfo object? > > Yes, you would. There are a number of examples floating around the > net, including the mailing list archives. Yu can use this class i writted , it should simplify thinghs : http://monoosc.svn.sourceforge.net/viewvc/monoosc/MonoOSC/MonoOSC/Class/UnixShell.cs?revision=34&view=markup > > -- > 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 > -- Cordially. Small Eric Quotations of the days: --- If one day one reproaches you that your work is not a work of professional, say you that: Amateurs built the arch of Noah, and professionals the Titanic. --- Few people are done for independence, it is the privilege of the powerful ones. --- No key was wounded during the drafting of this message. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch: Fast virtual generic method calls
Hey Mark, 2008/9/25 Mark Probst <[EMAIL PROTECTED]> > Hey everybody, > > This is my second attempt at implementing fast virtual generic method > calls. The implementation is very close to Paolo's proposal here: > > https://bugzilla.novell.com/show_bug.cgi?id=324481 > > The main difference is that I don't hash the methods into slots but use > the (until now unused) "normal" vtable slots for the thunks. This is > necessary because with generic code sharing the method signature is not > known statically. > Makes sense, the space is already these. Does it handle dispatching of interface generic methods? The code in method-to-ir.c suggests not. > > A big problem with this implementation is the memory management of the > thunks. Since thunks become obsolete when new method instantiations are > added we have to reclaim their memory. We can only do this safely if we > know that no thread is still executing the thunk code. The current > solution is a hack: Freed thunks are queued until there are 50 of them, > at which point for each new freed thunk we reclaim the oldest one in the > queue. The other problem with this approach is that if there are only a > few thunks which grow and grow we won't be able to reuse the freed small > pieces, i.e. a program can easily make us use an arbitrary amount of > memory by having a single virtual generic method which is instantiated > with a large number of different type arguments (easy to do > recursively). > > One solution I have to the latter issue is by splitting the thunks into > small fixed-size code pieces, in the simplest case one piece per > decision-tree node. Not difficult to implement. Another solution would > be to have a code manager which permits freeing items :-) > > The patch currently only supports x86. > Since you have a hashtable with the expansions, what about introducing a limit on the number of trunks per method, this change should not be hard. Have you thought about using something else than a MonoMethod as key? We could, for example, use the following scheme: Right now it's only possible to share if all instantiations are reference types. I guess we can determine if the method is shareable on first compilation, which is before any trunk code is generated. Given that we know this, we could store in the upper bit of the tokens used for resolving the trunk if they refer to a sharable instantiation. Then on trunk code, if the method is sharable we check this bit and avoid generating tons of trunks. But even with that we would still need to generate trunks. If we generate then partially, as you suggest, for each decision node, I can't think how the current scheme would allow for making it balanced. I guess it would be doable if we stored the keys in an array not part of the code, as sorting it would not mean doing a lot of code modification, so no icache flushes unless we wanted to link a new trunk block in the tree and each trunk block could be a 15 entries decision tree. Cheers, Rodrigo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Patch: Fast virtual generic method calls
Hi Rodrigo, > Makes sense, the space is already these. Does it handle dispatching of > interface generic methods? The code in method-to-ir.c suggests not. No, it doesn't. I don't think interfaces should be too hard, though. All we need to do is to pass the fully instantiated MonoMethod* as the key. Not sure how this plays together with non-generic interface methods, though. > Since you have a hashtable with the expansions, what about introducing a > limit > on the number of trunks per method, this change should not be hard. What would it buy me, though? I'd suggest, without any hard data, that methods with more instantiations are more heavily used, so limiting them doesn't make much sense. Unless we use an LRU schema for selecting which instantiations make it into the thunk, but I think that can easily lead to thunks which are constantly re-compiled because the "working set" changes periodically. > Have you thought about using something else than a MonoMethod as key? Actually, the key is not the MonoMethod but the method_inst. > Right now it's only possible to share if all instantiations are reference > types. I guess we > can determine if the method is shareable on first compilation, which is > before any trunk code > is generated. > > Given that we know this, we could store in the upper bit of the tokens used > for resolving the trunk > if they refer to a sharable instantiation. Then on trunk code, if the method > is sharable > we check this bit and avoid generating tons of trunks. Whether the method is sharable can be determined in the thunk-table builder, as well. However, there's no point in doing that because unfortunately we can't use one thunk entry for all shared instantiations. It's true that those instantiations share the same native code, but on the other hand, each of them needs to be passed a different MRGCTX. This is currently implemented by jumping not to the method directly but to a static RGCTX invoke wrapper for the method, which passes the MRGCTX. > But even with that we would still need to generate trunks. If we generate > then partially, as you suggest, > for each decision node, I can't think how the current scheme would allow for > making it balanced. My suggestion was to build a new decision-tree every time a new item was added, like now, with the only difference of using lots of small code pieces to implement it instead of one big one. I wasn't suggesting updating the code-tree, like you would update a search tree. > I guess it would be doable if we stored the keys in an array not part of the > code, as sorting it would not > mean doing a lot of code modification, so no icache flushes unless we wanted > to link a new trunk block > in the tree and each trunk block could be a 15 entries decision tree. I'm not sure I understand what you mean. Could you give an example? Thanks for the feedback! Mark ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
