PostSharp

[zigaosolin]

Me and a friend are creating an innovative multimedia framework in C#. We
would like to utilize the power of C# over a more traditional language for
such projects (C++).
To be comptetitive in speed is still a very important goal and we have some
suggestions for either extending Laos or writing our own plugin to
facilitate that.
I hope you could help us with advice or even maybe some code. I think this
project would be big contribution to PostSharp. Here are the suggestions
(and also our requirements):

1) We would like support for parameter attributes. Let me give you an
example. We have a method:
void DoSomething( [NotNull] object mustNotBeNullOrThrow, [MinIntValue(3)]
int mustBeAtLeastThree);

At first, we even wanted a generic attributes (as [MinValue<int>(3)]) but
they are sadly not supported by C#. We had the
following parameter attributes in mind:
* NotNull, Null
* Min/Max*
* NotEmpty (string+array)
* Equal, NotEqual
* CastableTo
* Regex

The attributes would be inherited by overriden methods. They could also be
applied to interface method, automatically promoting
checks to all implementations. If checks needed to be ignored, we would
have special [IgnoreBaseChecks] attribute for that (or something like
that).

Another important thing would be to skip checks when they are not
necessary. This is clearly not needed at the beginning, but later on, we
could
emit two methods or special checked method and method without checks.
Checks could then be done before method call and call method without checks
or we would make checks using a checking method. In the first scenario, we
could use information from static analysis (constant propagation) and
skip checks.

2) Inlining - We inspected how C# JITs code. It does NOT inline any struct
calls. This means that the following code:

struct Vector2 {
double X, Y;
public static double operator*(Vector2 v1, Vector2 v2) { return
v1.X*v2.X+v1.Y*v2.Y; }
}

{
Vector2 v1=..., v2=...;
double z = v1*v2;
}

Would not get inlined. Both arguments are pushed to stack (ironically,
using SSE) and method is called, then return. This is 5x slower than C++
which is not
acceptable by us. There is no way to inform JIT to inline code. We would
like to use PostSharp to inline such methods.


3) static check framework (easy) - This would allow some attributes to use
information about code at compile time. They would construct SSA form of
code (or some other form) and
use it for simple tasks. Attributes such as [ConstantTypeReturn] could be
implemeneted (this ensures that the return value is not computed, it is
always the
same for the same type).

This would also be usable for 1).

4) Threading - out threading system allows pausing threads. We would like
to implement thread pausing scheme in a bit different way. We do not want
thread explosion, but at the same
time we would like many parallel "threads". We could implement this by
injecting automatic stops (every so and so instructions) in the method that
is used in thread. We may even need this
at runtime. This is still eary phase of development, but we would like to
hear some through about this.

5) low level assembly loading, verification, unloading and similar - we
require loading of assemblies through arrays of bytes (or streams, files or
whatever), without .NET loading a similarly
named assembly from the .dll if it is available in the GAC or through
search directories, and we want to be able to reload that assembly if a
change occurs. And all of that without application
domains.

Our main question is, whether this is possible with PostSharp and what
would be the best strategy for coping with these tasks. We are willing to
write all required code in "generic" manner
(not specific to our engine), so it will be usable to not just us and
realease that as an open source project.

Best regards,
Žiga, Bojan

[gfraiteur]

Hi Ziga,

Nice to see you want to use PostSharp for one of your key projects!

Let me answer point per point.

1. I plan to write a validation framework with the features requested there, with optimal MSIL generation and propagation of constraints along the line of inheritance. I will be done by November 10th, 2008, since I promised to present it at the PRIO Conference in Baden-Baden, Germany. Development is planned from August.

Skipping tests when not necessary is interesting but not planned. It is not easy test at compile-time whether a value fulfills constraints. Of course, some static analysis could be done, but it cannot be realized efficiently with the current version of PostSharp because the only level of abstraction (MSIL-level) is too low. It would be necessary to raise the level of abstraction by “decompiling” the MSIL instructions, and basically correlating instructions with their arguments (i.e. do some “stack simulation”: reconstruct the abstract syntax tree (AST) from the MSIL instructions). Although this is a very interesting feature, I had never found time or budget to realize this.

A second, easier approach is to suppose that all internal methods fulfill preconditions, so internal methods call methods without precondition checks. Only methods called from other assemblies would call the precondition-checking wrapper. This is fairly easy.

2. Inlining is not a too big problem. It may not be as efficient as you expect if we do inlining at MSIL level (and not at AST level), because it will be necessary to store all arguments of the inlined methods into local variables in order to be able to use them (because we can load only the element on the top of the stack). So maybe there will be an overallocation of variables – I don’t know how the JIT can cope with that; can it optimize it?

3. It is not as easy as you claim… The first unsolved problem is to build an AST, and first of all to choose the adequate intermediate representation. Not sure that SSA is the best for value analysis. The second problem is the constraint solver (SMT solver). Will a poor solver be enough? Maybe be not. Are we able to build yet another good SMT solver? Hardly. Are other SMT solvers available under a reasonable license for "commercial-enabled ope- souce"? I did not find that.

4. Threading. Yeah, I thought about something similar. What are you trying to achieve exactly? Green threads? I don't think it is possible to have a good implementation in managed code. It's a thing that should be managed by the virtual machine or by extensions like the Profiling API.

5. You can customize the CLR loading process by customizing the CLR host. There is a good book from Pratschner: Customizing the Microsoft .NET Framework CLR.

As for the optimal development process, as I wrote, I already plan to develop some of these components. The validation framework is planned and promised, and some bits of the AST and AST builder are done. You can consider sponsoring some development, which would make development faster since I could allocate more time to it. Depending on your own development expenses and budget (i.e the country from which you operate), it can be the most efficient way.

For non-core components, like inlining or specific validators, I favor completely independent projects without merging in the main code base.

I hope I answered your questions. Let me know if I can help further.

Cheers,

Gael

[zigaosolin]

Thanks for this lengthy response!

I have a few clarifications, suggestions and further questions:

1. I am glad that this feature will be implemented. This will probably be the part of Laos framework?
For skipping tests when necessary, this is clearly not priority number one project. However if you use aspects on parameters extensivelly, we would get big overhead. We found out that making really small constant propagation analysis and keeping track of non-null objects would probably eliminate half, if not more of all checks. Internal method calls should also clearly not use checks, as well as passing data to another constructor. For methods with multiple parameter checks and some fulfilled to be true, we can always emit necessary checks before calling the method (this makes code size a bit bigger) and then calling unchecked method.
I believe a preaty simple code analysis (only keeping track of constants and non-nulls) would be good enough for this kind of optimisations.

In addition, we have total control over the assembly installation process and can therefore analyze calls that happen from one assembly to another.

2. We will probably implement inlining as part of our engine's plugin. About inlining's performance: JIT inlines using MSIL code only. As far as I know, it does some basic optimisations (mostly those regarding inlining): constant propagation, dead code elimination, value aliasing ... So there shouldn't be too much performance overhead. Is there anyone in the community interested in inlining plugin; otherwise we will make it closed source.

3. I know code analysis is a very cumbersome topic. I have been keeping track of fantastic project: LLVM (http://www.llvm.org). It has really cool (and a lot of) code analysis, with immediate representation compatible with both native and managed languages (they are running Java, sadly MSIL is still not implemented). I suggest you take a look at it, since their code representation is mature and very flexible. Maybe we could even "wrap" the project and use it's tools (but this is somewhat hard and not really nice for now).

4. We could call them green threads. All we wanted from PS would be to split method into managable chunk units. When chunk is over, it would return and thread control would decide, which thread to resume. We should probably study CLR hosting API first before we make a move, especially the threading bits.

5. Thanks for advice.

[gfraiteur]

4. We could call them green threads. All we wanted from PS would be to split method into managable chunk units. When chunk is over, it would return and thread control would decide, which thread to resume. We should probably study CLR hosting API first before we make a move, especially the threading bits.

I had the idea too. Basically it means working only with the heap and limiting the stack to a minimum.

1. Encapsulate all methods arguments and local variables into one class.
2. Put the call stack on the heap also.

The big problem there is CAS security and safety. In other words, it works only for public methods -- any method chunk will become a public method. A pretty mess! It will be a hell to debug, also.

[zigaosolin]

We could probably bypass CAS issues by CLR hosting. This is surely not optimal for all projects but we will need CLR hosting anyway at some point. Debugging is another issue, but I guess we could chunk the method only in release builds. There are also other difficulties, such as:

* how to partition for loops (which usually do a lot of work) - a solution might be to invoke a method that encapsulates one iteration many times, based on some external state
* how to efficiently decide approximatelly how many instructions will be used (and so optimal chunk size) - one way is with runtime profiling.
* how to decide which methods to chunk (we may get a delegate at runtime). Furthermore, we would need some sort of runtime chunking.
* how to evaluate how much time a chunk of instructions will actually take as a method call may take microseconds to hours

We will let you know if we have some results on our threading system extension. Otherwise, we will shortly begin with the inlining project.

On another note, it does seem as if you are under the impression that this project has a budget. Sadly, that is not the case and it will probably continue to be that way for quite a serious amount of time. Seeing as we might need a "commercial license" to link PS.Core, we'd like to get some insight into your opinions on the subject; We are somewhat able coders, so maybe we could compensate by co-ensuring that the 10th september deadline is met, maybe even with a few bonus features?

[gfraiteur]

You don't need a commercial license if you release to GPL (or another open source) what actually links to PostSharp.Core, which is what you planned to do, if I understood well.

I think inlining is perfectly doeable in rather little time once you know PostSharp Core.

Validation is more difficult, but doeable also. You will come into conflict with what I will start to develop... Some validators are already available on http://code.google.com/p/postsharp-user-plugins/ (not from me), but there is no logic to apply them on inheritance axis.

Chunking is quite savage. I would not give any estimate to that. As you mentioned, there are many open questions. Knowing where to put the split points is maybe the more difficult question... Another difficult question is to handle synchronous methods that should be executed asynchronously (because they involve I/O operations). I have no clue for that; actually, I would even not implement it this way. The proper way to implement that is in the virtual machine. It may even be wiser to branch Mono .

[zigaosolin]

At first, we were thinking of "only" writing plugins and putting them under GPL licence. However, as we have gone through your API, we found out that the code model is exactly what we need. Reflection API just isn't enough. We would like to use it not just as a post-compile step, but probably even at runtime. We could provide our own API and "wrap" yours inside it, but since yours is so well designed and not really easy to wrap (it is big), we could use it directly. Here are some things we would like to use PostSharp Core API for:
* install time code verification
* shader code to MSIL code coversion (emulation hardware shaders)
* proxy injection and generation at runtime
* ...

This probably means we would need licence.

The problem with Mono is that we are using Managed C++ for some parts of engine (mainly DX10 driver and database driver). We are also concerned about CLR hosting in such situations. Otherwise, I agree that Mono could be costumized for our needed. We could even employ our own optimizations (or those provided by LLVM) ...

[gfraiteur]

We could provide our own API and "wrap" yours inside it, but since yours is so well designed and not really easy to wrap (it is big), we could use it directly.

It would not solve the license problem, since your code would still link indirectly to PostSharp.Core. All the features that require PostSharp.Core, even indirectly, should be released as open source. If you have a plug-in host (say Visual Studio) and one of your plug-in uses PostSharp.Core, then the license is only viral to the plug-in. But you cannot develop a plug-in system just to circumvent the license, because in that case the plug-in becomes required for the whole system to work...

Anyhow.

Mono is supported -- as far as Mono supports PostSharp. I have a working version locally, and I will publish it later this month. There is also support for CF and WPF (runtime, not compile time).