Giters

dotnet / orleans

Cloud Native application framework for .NET

Home Page:https://docs.microsoft.com/dotnet/orleans

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Contribution idea: Port Orleans to coreclr

gabikliot opened this issue · comments

commented

Port the Orleans code to run on coreclr.
Some APIs from the full .NET got deprecated in coreclr (aka .NET Core), mainly around files and reflection, but at large the porting effort shouldn't be too big. This will allow to run Orleans efficiently across different platforms.

Tools:
Coreclr api search
.NET API Usage
.NET Portability Analyzer - download and Install
.NET Portability Analyzer Usage

Progress so far:
CoreCLR milestones
ApiPortabilityAnalysis result file for all projects (let's find an appropriate place to place updates of this file, please don't pollute the master branch with these big reports)

There are 2 types of issues:
(a) easy, just change an API - we have done all those.
(b) deeper profound issues where API was deprecated or changed significantly and we will need to investigate other ways to achieve the same functionality:

Need to investigate and consider profound rewrite - feel to open a GH issue with ideas on how to handle each one of those issues (separate issue for each) :
High priority

  • Create a v2 branch that changes target for Orleans to .NET Standard 1.6
  • Remove usage of App Domains for scanning https://github.com/dotnet/coreclr/issues/919
    • Revisit Assembly Loading (LoadFrom -> AsemblyLoadContext, Location,...) #2025
  • Provide an alternative fallback serializer (BinaryFormatter is not supported in .NET Core). The biggest concern is serializing exceptions, as they are not typically part of the grain interfaces, and we don't generate Orleans serializers for all exceptions in the system. We have a few workarounds in prototype that need to be enhanced.
  • PerformanceCounter - not supported in .NET Core.
  • Environment.UserName
  • CallContext.LogicalSetData - potentially replace with AsyncLocal<T>
  • Update codegen to be more aggressive and generate serializers for Exception types
  • SerializationInfo - not supported in .NET Core.

2nd priority

  • Compile time codegen working with new dotnet cli tooling (although be aware that the tooling will drop support for project.json once it RTMs, and we are not sure if the build tools will work once they start using csproj once again)
    • Avoid having OrleansCodeGenerator depend on Orleans project, since that creates a circular dependency to getting codegen to work easily (especially since Orleans.dll requires build time codegen). This is a nice to have, but not required if we solve the previous item in some other way.
  • Allow TestCluster to work without creating new AppDomains for each silo (for example, by leveraging containers, or spawning and managing new processes)

3rd priority

  • Separate test projects for each provider that brings in a new dependency (ideally even if that dependency is also supported in .NET Core, otherwise we would need to port the entire codebase before we can start testing each individual component we port)
  • CI servers run tests in many platforms
  • System.Runtime.Serialization.FormatterServices.GetUninitializedObject
  • System.Diagnostics.Process.Handle -> System.Diagnostics.Process.SafeHandle

Already done issues (for progress tracking):

  • Type.IsInterface-> Type.GetTypeInfo.IsInterface (IsClass, IsGenericType , IsAbstract, IsPrimitive, IsEnum).
  • Type -> TypeInfo for most members (in Orleans code, and code generated by OrleansCodeGenerator) #1783 #1894 #1997
  • TextReader.Close -> TextReader.Dispose #609 #2034
  • Socket.Close -> Socket.Dispose
  • Delegate.CreateDelegate -> MethodInfo.CreateDelegate
  • ApplicationException(string)
  • System.Data and System.Transactions - used in SQL utils. Create a separate OrleansSQLUtils project and move all Relational Storage code there.
  • XmlTextWriter and XMLNode.SelectNodes.
  • Dns.GetHostAddresses.
  • System.String.ToLower(CultureInfo.InvariantCulture) -> Use CultureInfo.TextInfo.ToLower(String) instead
  • System.UriTypeConverter.
  • System.CodeDom.CodeTypeParameter.
  • BinaryFormatter.Serialize - solved via #1047.
  • System.Management.ManagementObjectCollection - not supported in .NET Core. Investigate and propose alternative options (if ManagementObject itself is supported). We use it now in one place, to find TotalPhysicalMemory. Solved via #1048
commented

We run the compatibility tool some time ago. There are a couple of unsupported APIs, mainly about files (need to use streams instead) and code gen. We don't think it would be too hard to do the port. Perhaps a good way to start is to re-evaluate what needs to be ported exactly and then do the port in small steps, one API at a time (as opposite to one huge PR). That would make it much easier to validate and accept it, and also other will be able to join in and help.

Can someone share the instructions of how to set up the compatibility tool locally?

commented

Hi
I think it is very important step and I would like to use Orleans client from the coreclr project.
Is there a working in progress branch for this?
Maybe I can contribute

commented

We do not have a progress branch for this yet.
In the meanwhile, we are doing a bunch of preparation work that will make the porting easier, such as reducing code generation (which is one of the biggest hurdles for coreclr port). This is tracked here: #474.

If you can contribute to the coreclr port, that would be wonderful! Perhaps a good first step is to precisely identify all pieces that need to be ported.

commented

No branch yet. We can create one for this.

commented

As I checked the code with the portability analyzer first step could be change of the usage of the Type class.
The analyzer suggests use TypeInfo instead of Type which is fine for the coreclr.
I assume that We don't need to change the CodeGeneration part because it will be deprecated and it has lot of Type usage. Will the CodeGeneration part be also deprecated in the Orleans.dll?

What do you think?

commented

I think most of the Orleans\CodeGeneration code will need to stay. We hope to significantly reduce the code in ClientGenerator.

commented

We can't tell for sure if ALL CodeGeneration would be deprecated. Certainly parts of it will be. But some parts maybe much harder to get rid off. So I would not rely on it 100% at least not in the short term.
Can definitely change usages of Type to TypeInfo.
What were the other parts?

commented

I see.
@gabikliot Not need to change everywhere. Type has some member which are not available in coreclr (e.g IsClass) but these are on exist on TypeInfo class.
There are some other things which are not available at all like ReflectionOnlyGetType() We need to find workaround.
Type stuff one of the biggest part because it is used a lot of places by Orleans.
Other tricky part will be the assembly loading and AppDomain things but I hope we can find something similar solution what asp.net does.
There are some other small things Environments, Serialization, etc. I think these are easiest part.
And finally there are some stuff what we need to remove from the Runtime and find platform independent solution like Performance Counters.

BTW Would be really helpful if somebody who is working on the aspnet 5 and can help us to review and give feedback about the changes.

commented

I would suggest to put Reflection-only stuff aside, as we most likely need a complete solution there. It'd be a bit ironic because we migrated to Reflection-only assembly loading only about a year ago. But that's okay if we need it for CoreCLR compatibility. One possible straightforward solution here is to switch to or add support for explicitly listing grain assemblies.

AppDomain is primarily used for code inspection and generation and workarounds for .NET's assembly loading peculiarities. Then there are a couple of global event handlers for unhandled exceptions and process exit - easy. The rest is used for testing, and we already support starting silos in separate processes instead of app domains there. Can be easily ifdef'ed I think.

Performance counters are already isolated in OrleansPerfCounterManager and statistics, so should be relatively easy to condition or retarget.

We can definitely get in touch with the CoreCLR and ASP.NET5 folks to get their feedback and advise. We'll arrange that.

I created a branch for this work - https://github.com/dotnet/orleans/tree/coreclr-compatibility. Let's get started.

commented

@sergeybykov Did you have a chance to talk to CoreCLR folks about this.
I'm just wondering where we can start and how.
Maybe we should put together a check list about the steps.
What do you think?

commented

I checked in the ApiPortabilityAnalysis result file for Orleans.dll here.

I also created a list of issues based on the analysis result in the top commet in this PR #368 (comment).
I suggest people just grab one issue at a time, fix it, submit a PR and that way, gradually, over multiple PRs we will get closer and closer to the goal. The majority of issues are minor, but there are a couple that we will need to look at more seriously and consider alternatives.
However, there are enough small/medium issues so anyone can make progress.

commented

@gabikliot @sergeybykov Could you please update the coreclr-compatibility.branch?

Here is my repo with some initial commits. I look forward your feedback. Thanks
https://github.com/pherbel/orleans/commits/coreclr_portability

commented

@gabikliot would be glad to help out in anyway I can; loving the work the team is doing and would love to be a part of this.

commented

Hi @grahamehorner. Your help would be great!
We already have a first PR in this direction (#590 by @pherbel), which we are going to test and hopefully accept.
There is more things that need to be ported. I would suggest just to pick one issue at a time from this list (https://github.com/dotnet/orleans/blob/master/misc/ApiPortabilityAnalysis-Orleans.dll-June.30.2015.htm) and submit a PR to master branch with that change. We prefer a number of smaller, independent, self contained PRs over one big PR with lots of different unrelated porting issues. It helps us test and make sure the existing code is operational all the time.

commented

@grahamehorner Great!
@gabikliot SerializationAttirbute and the BinarySerialization will not be supported in the coreclr So we need to figure out how we can change it.

I found these related to serialization:
Coreclr issue 1347
Coreclr issue 1203

Also there is a useful link to search the coreclr api and package
Coreclr api search

commented

This is probably a heresy question, but here goes anyway ;)

If CoreClr is so far removed from .NET 4.5 requiring all these non backward compatible code changes, then what are the advantages of trying to be compatible with CoreClr rather than instead targeting Mono [on Linux + OS-X] as the "cross-platform" runtime?

All the portability analysis reports to date show that Orleans code base is more compatible with Mono than CoreClr.

For example, if we remove [Serializable] from all Exception classes then this code branch is unusable with "old" test host / suite which uses AppDomain and MarshellByRefObject in several important places.
We will need to give quite a lot of thought to how to port the current test environment over to CoreClr.

We will effectively have created a one-way code fork, and two increasingly divergent code bases.

Having to we use lots of #if blocks to keep a single code base seems like a bad code smell to me, but so does two divergent code bases!

Thoughts?

Update: My Bad on the TypeInfo API changes. I updated my post above to reflect that new info. Type.GetTypeInfo is available in .NET 4.5 as an extension method in System.Refection namespace, but we don't import that everywhere, so VS IntellisSense sometimes can't see it. :(

commented

I updated my comment above after I found that GetTypeInfo is available as an extension method in System.Reflection namespace in .NET 4.5. My bad.

Given that, can we package up the CoreClr compat changes into those API changes that are already supported in 4.5 and which we can apply to the master branch, and have this coreclr branch for changes that are only applicable to CoreClr going forward?

If we end up with only a very small delta between the 4.5 master branch and the coreclr branch, then most of my meta-concerns might go away completely.

commented

I would like to use Orleans client from the coreclr project.

If we take a step back and re-exampine @pherbel stated requirement, then the initial focus should be on client access from CoreClr.

We don't necessarily need to port the whole of OrleansRuntime.dll to CoreClr immediately to help @pherbel do what he wants to do.

So initially targeting changes to Orleans.dll creates a good Minimal Viable Product deliverable and gets us to First Base with coreclr compat.

commented

I think we don't need a separate coreclr branch at all.
I recommend doing all porting efforts on the master branch. Fix a porting issue, submit a PR against master, we will test its correctness and perf. That way there will not be, by definition, "We will effectively have created a one-way code fork, and two increasingly divergent code bases." I am for one always-correct and operational code base.

Clearly, after we do all "easy" porting fixes we will remain with unsupported features, which we will need to look at one at a time. My recommendation is to do as much as we can first, without breaking changes, and then re-evaluate.

@pherbel , thanks for the links. Super useful!

commented

@jthelin I think ultimately coreclr is the target we should be aiming for as coreclr this designed specifically for cloud applications; and orleans is a cloud application, this would also allow Orleans to run on nano server, Linux, mac OSes and windows IoT; rather than targeting the mono framework which won't run on nano server or windows IoT given the reduced OS footprint.

Also while I would opt for the creation of a set of windows universal components for the orleans client functionality; so these can run across all OS and device/processor platforms. Phone/Mobile, Table/Xbox, Desktop/Server

commented

@gabikliot I'm just configuring my Orleans dev laptop with Windows10, VS2015 RC & GIT, once done I'll pick up the two items:-

TextReader.Close -> TextReader.Dispose
Socket.Close -> Socket.Dispose

and when complete submit a PR

commented

@gabikliot FYI, I've switched accounts new account

commented

@grahamehorner , what is GabrielCloudSystems? My name is Gabriel and I am definitely involved with Cloud Systems. :-)

commented

Gabriel Cloud Systems LTD is my company name, We are doing development in the #IoT space & .NET
consultancy work in the north east of England for a number of clients (I own the company) :D but I/we
also do open source and community forums/projects

Gabriel = Angel – Cloud and the Cloud is all about communications
which just so happens that the patron saint is St. Gabriel and is the
street name where we have our offices :D

commented

Well, now you just need more Gabriels working for your company (or change your name) and you've got it all! ;-)

commented

@gabikliot I'd offer to hire you; but I'm sure you'd be out of my budget ;) (but worth every penny and more I suspect) lolz

commented

@gabikliot I agree to use master branch. Did you have a chance to check my PR? I will rebase it on the current master branch. In my PR there is a vNext project which is very helpful to check the real compatibility (It could be tricky if you are just using the 4.5.1 build). Maybe the vNext project is not fit to the master branch.

commented

@grahamehorner Great PRs! 😄

commented

should Orleans using NewtonSoft,Json to perform BSON serialization given the BinaryFormatter.Serialize is not supported in coreclr; would be a breaking change and/or
require a tool to perform a one time conversion of serialized and persisted object.

commented

@pherbel small but sweet ;) glad to help out anyway I can :D

commented

@gabikliot @pherbel personally I'd keep the Orleans.vNext in the master branch as well, the .cs files should be shared across the solutions in matching vNext projects eg. OrleansRuntime.vNext and the targets in the vNext project.json should be net45, dnx451, dnxcore 😄

commented

@grahamehorner Yeah. That was the original idea. Actually it doesn't bother the current project structure. And later we can drop the old projects.
The Serialization will be a tricky part.

commented

@pherbel, I have looked the PR already, but I still need to test it more thoroughly for perf as well, in our internal vso test suite. Just want to make sure all those different reflection APIs did not hurt perf.
We were a bit busy last days with 1.0.9 and other internal priorities, so it got pushed a bit. I will be on it in the next days.
Yes, please ebase it, it would be great.
Re vNext - I don't think there is any problem keeping it.
Re serialization - this is a bigger issue. We need to consider #37. So I suggest we delay it for a bit, and hopefully will figure out a solution for pluggable serialization format to solve #37 which will also solve coreclr issue.

commented

@gabikliot Thanks it makes sense

commented

http://dotnetstatus.azurewebsites.net/usage

I still have a really hard time getting my head around the fact that there is more red in the ASP.NET 5 column than in the Mono column! It is a big step function change in .NET APIs :(

Re serialization - this is a bigger issue.

It does seem like [Serializable] is going to be one of the largest disruption areas, so agree with @gabikliot that we should take step back and re-evaluate the big-picture requirements around serialization functionality before we dive in.

One embryonic concern I have is that as Orleans moves towards more runtime codegen approaches, it might make integrating with "pre-generated" serialization mechanisms like Bond or ProtoBuf more difficult, but we will need to look at that space in more detail to be able to form a concrete opinion.

commented

I agree serialization is going to be a issue; however abstract serialization away and allow a dependency injection of the serialization functionality it allows implementations that can be swapped in according to the target platform requirements/compatibility until such time a universal serialization implementation is developed or chosen.

commented

@gabikliot @jthelin re-evaluation of the serialization requirements is a good plan, as this could firm up the interface contract for a dependency injected serialization component and/or serialization component providers.

commented

Current status: ManagementObjectCollection and ManagementObject aren't supported in coreclr, and I haven't found replacement for it yet, AsyncLocal can be used instead of CallContext.LogicalSetData and Trace.CorrelationManager but it isn't available in .Net 4.5, as well as System.Diagnostics.Process.SafeHandle.

commented

Dns.GetHostAddresses - not supported in .NET Core. Investigate and propose alternative options to find DNS name. We only use it for logging now, no logic relies on it.

could be resolved by using the libuv http://docs.libuv.org/en/latest/dns.html in a similar way the ASP.NET team do with Kestrel

commented

@grahamehorner Thanks for advise, but this one was already resolved by using Dns.GetHostAddressesAsync

commented

Just to let every1 know, since there was no progress being made on the Type -> TypeInfo since august, I'm working on it now and will submit a PR soon.

Thanks

commented

FYI: Currently I'm working on CallContext.LogicalSetData.

Thanks

commented

Good! I'll be catching the first(easy) list, and them will move to the assembly load stuff... Lets keep in touch on Gitter :)

commented

@dVakulen ok; didn't spot that, thanks for pointing this out

commented

would anyone have any objections to wrapping/replacing the creating an abstraction layer for Orleans PerformanceCounters with an implementation that uses ApplicationInsights

commented

Go for it! No objections.

commented

@grahamehorner that is something we need not just for PerformanceCounters, but for whole instrumentation. AI must be somehow a Plugin... Maybe we can have an interface like ITelemetryProvider and have many providers for many diff APM tools like NewRelic, ApplicationInsights and so on and use DI to inject the configured one... Do you mind create another issue for that so we can discuss it there? Performance Counters here are not actually something that is blocking this port to coreclr since it is already an external project. Thanks!

commented

@galvesribeiro Do you have a rough idea of when CoreCLR support will be ready for me to test? Is there anything left that I can pick up and help with? Otherwise I look forward to testing for cross-plat :)

commented

Hello @KodrAus

We can't commit on a timeline but trust me, I want it done ASAP :)

You can try investigate the System.Management.ManagementObjectCollection replacement. It is used to read the machine available memory but it is not available on coreclr anymore.

You can fork and submit a PR to the coreclr branch.

After the Telemetry API that I'm working and @dVakulen fallback serializer changes are done, we are almost ready. As soon as I finish Telemetry API I'll check the AppDomain removal/replacement so we can start the tests.

Thanks

commented

@galvesribeiro Sounds good. Should I base from your coreclr-compatibility branch?

commented

Submit a PR against master unless there is something that prevents that.

commented

@KodrAus go for the master one unless this PR is a breaking change for the non-coreclr code. Thanks! :)

commented

Hey all, how's this travelling? Is there any more that can be done?

commented

@KodrAus We need port the tests to n/xUnity... Can you help with that?

I'm trying to get MSTest with the team to be up-to-date to rc1... So far, It only works with beta7 so we can't wait on that... Would be good if we have all tests finally ported to either x o nUnity.

commented

Sure I can help out with that. I personally prefer xunit over nunit, and feel it's functionally a bit closer to MSTest. Shall I open/find an issue about CoreCLR testing and work there?

commented

@KodrAus hold on for a bit...

We recently received the announcement of VS Update 1 RTM... With that, MSTest is now supporting CoreCLR:

MSTest and CodeCoverage support for ASP.NET 5. The Visual Studio testing tools now support MSTest framework-based tests for ASP.NET 5 applications and add support for CodeCoverage with ASP.NET 5 on x86/x64 platforms targeting the CoreCLR/CLR. The MSTest framework components are available from the NuGet gallery.

I'm right now updating my VS(takes ages!) here to check if it is really working. If yes, that means we could hold on the port of the tests, and we will remove this blocker so I can move forward.

Will update everyone here after I got it done.

Thanks!

commented

@KodrAus wrote:

Shall I open/find an issue about CoreCLR testing and work there?

@galvesribeiro, If an issue does not exist, do you have any objections to @KobrAus opening one regarding testing Orleans CoreClr? The conclusion in that thread may be that we stick with MSTest, but there is value in having this discussion on its own thread, correct?

commented

@jason-bragg That's what I think. It's easy to have a focussed discussion in a dedicated issue and reference it from this general one so people can still follow

commented

@jason-bragg no objections at all! 😄 Go for it!

There is an issue already opened and closed by @jthelin on #574 for that matter.

Talking with @sergeybykov today, we agreed that the problem was not just make the test run on x/nUnit. This @jthelin already made a full PR about it (#575). The problem is to make it work on Jenkins CI from .Net Foundation as is or to convince them to change the build environment to add x/nUnit runner and Jenkins plugin for it.

I think if MSTest is OK for coreCLR, we should stick with it for now as it is will not be a blocker anymore.

commented

@galvesribeiro If MSTest indeed works for CoreCLR, that will make the test question much more flexible and much less immediate.

commented

Absolutelly @sergeybykov!

I've reached the MSTest team again asking where the update to coreclr RC1 is. So far, Nuget only has the current beta7-8 version of it:

image

Lets hope they reply soon...

commented

Just to update everyone, just spoke with MSTest team an hour ago and they just released the Test Runner for CoreCLR.
https://www.nuget.org/packages/MSTest.Runner.Dnx/1.0.0-rc1
So, we are unblocked!

Let's stick with MSTest for now. Later on without rush, we can see how we can migrate the tests.

commented

Ok, just more updates... We found out that MSTests doesn't really unblocked us for .Net core and we didn't saw on the past months much news from them. We just got merged the migration of all tests from MSTest to xunit (#1288 and #1540) and now we are free to move forward!

We will now work on get all projects migrated to .xproj/project.json but keep targeting .Net 4.5.1. That will remove all our dependencies on old MSBuild build system and .csproj projects.

With all that in place, we can safely move forward and implement the rest of the compatibility issues which requires targeting higher platforms.

More on that soon...

commented

Great progress @galvesribeiro !

commented

Any updates?

commented

We just got the RC2 release Today and since there are LOTs of changes from RC1/DNX, I'll re-run the analyzer and evaluate again what is missing. There is an known issue that is the lack of binary serializer but we already have a workaround and it will finally fixed on .Net Core RTM. Stay tunned, more soon! ;)

commented

Just to update everyone...

We got the solution to build again using RC2 tooling after some changes. We are working now on get Codegen to work with the "new" build system. Tests still not passing due to the missing types that should be generated by codegen.

We tried to build on netstandard1.5 moniker and we captured all the missing failures... We address almost everything from @gabikliot initial list already (thanks for every1 who contributed to that) and the remaining cases are related to serialization classes missing that we should get a workaround soon.

More updates soon...

commented

Exciting ! Great progress!

commented

BTW, don't trust on Portability Analyzer Extension anymore... It looks (very) outdated and don't detect our changes... For instance, it still complain that we are using GetType().Something while we checked the code and we are using GetType().GetTypeInfo().Something instead...

commented

@galvesribeiro Just wondering you are targeting the most higher version (ns1.5) which means having most recent features and least support everywhere.

commented

@xied75 we didn't decided which netstandard we will target in the end... We are testing the more restrictive possible since we are going to run it on NanoServers... The idea today is to have the Nuget cross-compiled to net451 and netstandard1.5. After that work, we should make all efforts to remove net451 and target a single netstandardX.X which feels confortable to our users that don't want to go to .Net Core...

commented

Actually, we have A TON of usages of Type where we should be useing TypeInfo instead, so the portability tool was not wrong there. I'm trying to get Orleans.dll to compile on .NET core, but this is by far the biggest "noise", followed by our statistics (which use perf counters). Of course these are not necessarily the biggest issues to get a CoreCLR port, since assembly loading and serialization are the hardest issues to solve.

Also codegen currently creates new usages of Type.GetField()

Any kind soul that wants to take a look at migrating our usages of Type instead of TypeInfo? Ping me through gitter (or here if you aren't there).

commented

Do we have the timeline, when Orleans will work in core clr?

commented

No timeline yet, especially considering the recent changes in the CoreCLR plans.

commented

I think it is very important that port the Orleans code to run on coreclr. if it is done, there are more people to use it.

commented

@samuelyao314 We think the same, and we are working towards that. Serialization is the biggest hurdle at the moment.

commented

Updates...

  • Revisit Assembly Loading (LoadFrom -> AsemblyLoadContext, Location,...)

that would be handled with #2025 but it should only be merged on master along with the other changes on dotnet-cli branch

commented

Looking at the LogicalCallContext removal but the .NET Core replacement is AsyncLocal and I can't have net451 coexist with netstandard1.3 in a single PR because of build issues. They're mostly centered around the serialization.

Is there a PR around serialization being worked on? I know Wire was referred to as an option.

commented

@adamhathcock the AsyncLocal is 4.6+ and about Serialization, if you are interested, would be good to have a POC with Wire so we can make benchmarks and check on the serialization behavior

commented

@galvesribeiro yeah...I didn't change the net level (I have CallContext on a compiler flag on net451 with AsyncLocal on netstandard1.3) but I didn't want to submit a broken PR as binary serialization is in the way of having a netstandard target

I'll play around with Wire :)

commented

@adamhathcock I had change with AsyncLocal on the shelf for ~ half a year, (#368 (comment)), but if you did it too - feel free to submit PR with your implementation.

commented

oh! yeah I forgot that @dVakulen. And the very reason it wasn't merged is the upgrade on the framework version...

But nevertheless... We will need to upgrade to 4.6.1 anyway when doing the .net core port otherwise we will blow the code with tons of #IFs

commented

Oh nice. Even easier to test out with.

Would Wire replace the default binary serialization on .NET Core if acceptable?

commented

Actually we want to try to replace Orleans codegened serialization with it as well.

commented

There's no doubt that wire will be faster than .Net binary one.

commented

The idea is to replace Orleans codegened serializers with Wire, and get Orleans out of the serialization business altogether.

The question about .NET binary serializer is trickier. I believe it's the same challenge for Wire as for current Orleans serializer - private types aren't accessible for our serializers, and exceptions are nearly impossible to pre-generate serializers for because technically any exception type can be thrown by any piece of code, as it may call a bunch of libraries underneath.

That's why we today fall back to .NET binary serializer where we don't have a codegened one. This won't work anymore in the current .NET Core. But the .NET binary serializer is expected to be added back to .NET Core in Q1-Q2 2017.

/cc @rogeralsing

commented

Glad to hear that you guys are considering Wire.
Some notes, the adapter in https://github.com/rogeralsing/OrleansWireSerializer is a very naive PoC to leverage the ExternalSerializer capabilities in Orleans.
This is faster than the built in support, but there is still a lot of overhead of the default Orleans serialization pipeline here.

If you want to get as much perf out of this as possible, here are the two major perf bottlenecks that I've seen so far:

1
There is a thread static serialization context for tracking object identities.
I get why it exists, but its a really expensive call to interact with thread statics.

2
There are a lot of allocations going on for no real reason, e.g. ArraySegment<byte> are being created as an array wrapper in a some places.
IMO, just go for Stream as the interface of writing data instead and get rid of the extra allocations.

commented

@rogeralsing Thank you for suggestions. I've already removed ArraySegment allocations, but there's still remains static context and value types boxing, which would be hard to get rid of.

commented

@rogeralsing @dVakulen I am a bit confused, ArraySegment is a struct unless its being boxed. Using it as an array wrapper is perfectly valid.

commented

@gregoryyoung yes, after checking the actual usages of it these seems to be the things that has the real cost.
Fetching the byte arrays from the BufferPool, which uses a BlockingCollection to store free arrays.
Copying data to and from arrays.
There are a few non buffered byte array allocations too.
So it is not the actual ArraySegment itself that makes up the cost but rather the use of its content.

commented

True lacking context. Normally the byte arrays would be reused though (one
of the benefits of using ArraySegment<>).

On Fri, Aug 19, 2016 at 4:46 AM, Roger Johansson notifications@github.com
wrote:

@gregoryyoung https://github.com/gregoryyoung allocating the byte array
that it wraps is not free. and writing the the data to the temp byte array
first and then copying it to the output stream is also not free.
So even though you are correct that ArraySegment is a struct, you are
lacking context.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#368 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAXRWnMcwzsGsRVu8oVNMuUIpkl3vL_uks5qhSctgaJpZM4EM_Au
.

Studying for the Turing test

commented

Actually ArraySegment is Orleans serialization was used in very hot path, so that removal of it's construction and properties accessing increased deserialization perfomance by 15 %.

commented

Also, BlockingCollection was replaced with ConcurrentBag.

commented

BTW, did anyone started with the Wire test in Orleans? If not, I can try that.

commented

@galvesribeiro @rogeralsing prototyped Wire as an external serializer, which is just a PoC. I don't think anybody looked at a full blown integration yet. I'm especially interested in making it run for compile time codegen.