[Mono-dev] [PATCH] Redirect certain string constructors toCreateString

Kornél Pál kornelpal at gmail.com
Mon Jul 17 07:13:18 EDT 2006


Hi,

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
>performance-sensitive code.

I think this patch does exactly the same:
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060712/a8ba9469/attachment.obj

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:
http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060716/e4a64304/attachment.obj

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 
little.

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 
described.

If I didn't understand something correctly please let me know.

Kornél

----- 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 
toCreateString


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 
> think
> other problems may occur altough I never experienced such problems.
>
> I attached an extended version of the previous patch that creates a 
> wrapper.
>
> 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
performance-sensitive code.

lupus

-- 
-----------------------------------------------------------------
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
http://lists.ximian.com/mailman/listinfo/mono-devel-list 




More information about the Mono-devel-list mailing list