[Mono-dev] [PATCH] Redirect certain string constructors toCreateString
kornelpal at gmail.com
Mon Jul 17 07:13:18 EDT 2006
I understand what are talking about but I don't really understand how this
affects my patch.:)
This patch would make the runtime to avoid any unmanaged code in these three
string .ctors (other string .ctors could simply redirected as well but
currently there is no use to do so). Strings are allocated
String.InternalAllocateStr. InternalAllocateStr is currently implemented in
native code but if managed string allocation were implemented in ther
runtime these .ctor to CreateString redirections still were useful.
I thing it's easier to patch InternalAllocateStr to a managed string
allocation code in the runtime rather than every string constructor because
in these three string .ctors in qestion there is no string allocation done.
The expected behavior is to let Encoding.GetString allocate the strings.
Furthermore StringBuilder and TextInfo are using InternalAllocateStr as well
so I think string allocation should be left in InternalAllocateStr that
should be called by .ctors later. When InternalAllocateStr will be managed
there will be use to implement the other string constructors using managed
code but until that native implementation should be faster because there is
only one internal call that way.
>The JIT will automatically use the method headers from the Create*
>methods for the implementation of the string ctors internal calls
>with trivial changes to the runtime. This implementation should cover
>your needs and it will avoid having a wrapper in the middle of
I think this patch does exactly the same:
But later I realized that it has drawbacks do do something like this. There
will be no .ctor in stack trace, security attributes won't be used...
The currently proposed patch:
Is different only in the fact that there is a simple managed-to-managed
wrapper (uses CEE_CALL) that is named .ctor and is marked as a wrapper, so
the runtime can handle it as a wrapper method and the above described
problems should disappear.
If you have a solution to aviod the wrapper and avoid the above described
problems at the same time as well it would be appreciated. Otherwise I think
using a managed-to-managed wrapper is good because the overhead is very
I think your plans doesn't interfere with this patch and in fact they
implement a part of your plans. As I see after applying my patch only
InternalAllocateStr should be made managed to achieve the goals you
If I didn't understand something correctly please let me know.
----- Original Message -----
From: "Paolo Molaro" <lupus at ximian.com>
To: <mono-devel-list at lists.ximian.com>
Sent: Monday, July 17, 2006 12:32 PM
Subject: Re: [Mono-dev] [PATCH] Redirect certain string constructors
On 07/13/06 Kornél Pál wrote:
> I reallized that simply redirecting the method may not be a good solution
> because the .ctor method is lost from the stack trace this way. And I
> other problems may occur altough I never experienced such problems.
> I attached an extended version of the previous patch that creates a
> In addition now CreateString () methods are properly implemented and I've
> patched ASCIIEncoding and Latin1Encoding classes so that their GetString
> methods no longer recurse to CreateString () methods.
I had a change similar to this in my long-term todo list, long term
because to improve performance it will need the changes in the GC that
allow object allocation completely in managed code. This way the string
ctors won't need to perform the managed <> unmanaged transitions.
The change would involve all the string ctors, of course.
Since the change would need to improve performance, using a wrapper
is not allowed, instead the Create* methods would have the same
signature as our currently used internal string ctors (taking a fake
string this first argument and returning the string instead of void).
The JIT will automatically use the method headers from the Create*
methods for the implementation of the string ctors internal calls
with trivial changes to the runtime. This implementation should cover
your needs and it will avoid having a wrapper in the middle of
lupus at debian.org debian/rules
lupus at ximian.com Monkeys do it better
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list