corlib and JIT updates #7

ncave · 2017-08-14T22:52:10Z

Here are a few fixes and updates to the corlib and JIT:

Better C# support (added some missing JIT features, some bug fixes and updates).
Added F# support (uses custom FSharp.Core, see here for a working example).
Tried my best to keep the corlib light, it's still around 260k (in release mode).
Release build assemblies now work too (after JIT bugfixes).

I see you added CLR debugging in the browser, that's awesome!

Terricide · 2017-08-17T01:19:56Z

This looks like a good pull request. I'm excited for this project

stavroskasidis · 2017-08-24T19:56:12Z

C# client side ??
DO WANT !!!

Seriously this looks great.

rvhuang · 2017-08-25T01:26:09Z

That's awesome! By the way, do we have Blazor on official Core 2.0 instead of preview version?

chris-ray · 2017-08-25T01:45:38Z

+1 adding my support for this project. Reaaaally want to see it come to fruition!

xiaowuchiu · 2017-08-25T07:15:20Z

How can one help with this project? Because I seriously want to see this getting bigger :)

stavroskasidis · 2017-08-25T09:02:14Z

+1 @Huarru I too would love to know how I can help.
This project needs to get a team behind it, Microsoft !!

I really think this can be a solution for the messed up, mangled mess that we today call web development. https://twitter.com/thomasfuchs/status/708675139253174273?lang=el

stavroskasidis · 2017-08-26T12:33:52Z

I tried implementing a new feature but the missing reflection features are blocking me. I tried using DNA from this PR but still there are a lot of basic reflection stuff missing.

I think the first thing to do should be extending DNA, although I am not sure if this is the way to go since Mono is also working to bring their runtime to wasm.

http://www.mono-project.com/news/2017/08/09/hello-webassembly/

Maybe switch to Mono runtime ? (when ready)

JohnGalt1717 · 2017-08-26T12:51:16Z

Here's why reflection in this type of project is not desirable:. Reflection prevents a linker from pruning code unless done very carefully.

It is imparitive that blazor implements a linker to shrink the size and using DNA keeps the monster size of mono out of this. (see how large the same app is for xamarin Android versus Java if you have any questions and that's with a linker)

On the web all you need is event handling, http requesting, and operations in the Dom (and cookies, storage I etc) all with strong typing. Essentially everything else is noise that should be done server side.

If a model that uses razor syntax for binding with eventing can be created that matches angular but does so with dnx and web assembly using mvc pages and mvc routing we'd have a massive win and would forever change web development, which is a disaster right now) for the better.

And as an aside, Al of this has the benefit of being natively executable for server side pre-rendered for SEO with seamless handoff and no nodejs involved which is another HUGE win.

stavroskasidis · 2017-08-26T14:17:24Z

@JohnGalt1717 Ok, that makes sense

pineywoods · 2017-08-26T14:57:36Z

+1 for this project. I'm waiting with baited breath.

RonPenton · 2017-08-26T15:41:31Z

I get that reflection is tricky when it comes to dead code elimination, but it's also an integral part of many codebases.

Perhaps an approach like .NET Native's "Runtime Directives" can be used?

https://docs.microsoft.com/en-us/dotnet/framework/net-native/reflection-and-net-native

RonPenton · 2017-08-26T15:42:18Z

PS if anyone needs an extra hand for this, sign me up.

yanglee · 2017-08-26T16:46:48Z

What kind of knowledge is required to contribute to this project? Does anyone have any recommendations on which books I should read?

I think rather than wasting countless hours writing awkward JavaScript/TypeScript code, I would rather spend those hours contribute to this project.

ncave · 2017-08-26T17:13:17Z

@SteveSanderson Separated the Blazor-Hackaton baseline to help the review.

csells · 2017-08-26T17:18:58Z

"I think rather than wasting countless hours writing awkward JavaScript/TypeScript code, I would rather spend those hours contribute to this project.” Amen to that.

TylerBrinkley · 2017-08-30T17:15:16Z

Just saw the announcement of an official .NET IL Linker at dotnet/core#915. That seems like great news for this project to reduce code size!

chrisdunelm

Nothing in-depth, just some minor comments having skimmed the code...

chrisdunelm · 2017-09-02T23:17:03Z

src/DNA/corlib/System/String.cs

+			return tmp;
+		}
+
+		public static string Join<T>(string separator, T[] values) {


Not sure if I'm missing something here, but Join<T>(string, T[]) isn't a standard member of string (see MS doc); the required method is Join(string, string[]).

Also with the following method

chrisdunelm · 2017-09-02T23:20:10Z

src/DNA/corlib/System/String.cs

+		#region IEquatable<string> Members
+
+		[MethodImpl(MethodImplOptions.InternalCall)]
+		extern public double ToDouble();


I'm not convinced this is a member of IEquatable<string> ;) or is even a public member of string at all...

chrisdunelm · 2017-09-02T23:50:36Z

src/DNA/native/src/Generics.c

@@ -112,7 +120,7 @@ tMD_TypeDef* Generics_GetGenericTypeFromCoreType(tMD_TypeDef *pCoreType, U32 num
 	memset(pTypeDef, 0, sizeof(tMD_TypeDef));
 	// Make the name of the instantiation.
 	strcpy(name, pCoreType->name);
-	strcat(name, "[");


[ is, I think, more correct that the proposed <. The code here doesn't very accurately follow the way generic types are meant to be named, but .NET (real) does use [, ] as the generic container. See the second example in the MS docs here.

@chrisdunelm I know, but it's very confusing to see [ and ] instead of < and > when types are printed out. It's also mainly cosmetic, so it shouldn't matter. And it's easy to change back if needed.

chrisdunelm · 2017-09-02T23:58:48Z

src/DNA/native/src/Heap.c

-									moreRootsAdded = 1;
-								}
+							if (pType != types[TYPE_SYSTEM_WEAKREFERENCE]) {
+								Heap_SetRoots(&heapRoots, pNode->memory, GetSize(pNode));


Use pNode->totalSize instead of GetSize()?

chrisdunelm · 2017-09-03T00:01:56Z

src/DNA/native/src/Heap.c

@@ -72,6 +72,8 @@ struct tHeapEntry_ {
 	// unused
 	U8 padding;

+	U32 totalSize;


Is this just for speed? To avoid the cost of a GetSize() call? It uses another 32-bits for every heap entry, which isn't disastrous, but isn't great either.

@chrisdunelm Thanks, I really appreciate your input. Yes, this is mainly for speed at the price of one more int per heap entry. It does help a little but it's not a huge win in release mode. I'll hide that behind ifdef so that it is configurable.

@ncave Have you profiled this? I'm just curious what difference it makes?
Mind you, the whole heap code really needs a rewrite to reduce per-object memory overhead, and to remove the need for the binary tree of allocations. Not really thinking of a generational GC, that would probably add to much code. This was something I vaguely intended to do, but never got around to.
The current heap code was just the simplest thing to get GC working quickly.
The very initial implementation did no GC at all. It was beautifully fast, but ran out of memory rather too quickly.

@chrisdunelm
Yes I have, it does make a difference in debug mode (obviously) and much smaller (but still measurable) difference in release mode. I've disabled it for now, but leaving it as configurable option.

The heap is great for what it is (non-generational) and it works well, as long as the alloc pressure is not too heavy, that's why I have increased the limits a bit. Obviously it would be nice to have a better one eventually, since it can eat a lot of the performance in heavy alloc scenarios.

LOL at the no GC allocator, seems to be a fad lately.

chrisdunelm · 2017-09-03T00:14:40Z

src/DNA/native/src/JIT_Execute.c

@@ -106,7 +109,7 @@ tJITCodeInfo jitCodeGoNext;
 // Set the new method state (for use when the method state changes - in calls mainly)
 #define SAVE_METHOD_STATE() \
 	pCurrentMethodState->stackOfs = (U32)(pCurEvalStack - pCurrentMethodState->pEvalStack); \
-	pCurrentMethodState->ipOffset = (U32)(pCurOp - pOps)
+	pCurrentMethodState->ipOffset = (U32)(pCurOp - pOps); \


Tailing ; \ can be removed?

chrisdunelm · 2017-09-03T00:35:48Z

src/DNA/native/src/Heap.c

@@ -473,8 +473,8 @@ HEAP_PTR Heap_Alloc(tMD_TypeDef *pTypeDef, U32 size) {
 		}
 	}

-	pHeapEntry = (tHeapEntry*)malloc(totalSize);
-	memset(pHeapEntry, 0, totalSize);
+	pHeapEntry = (tHeapEntry*)calloc(totalSize, 1);


(1, totalsize)?

davidfowl · 2017-09-03T05:41:58Z

src/DNA/corlib/System.Collections.Generic/IReadOnlyCollection.cs

@@ -0,0 +1,33 @@
+//
+// IReadOnlyCollection.cs


Why copy from mono instead of corefx?

No particular reason, this interface is the same either way. Perhaps one reason, the original DNA seem to be based on mono (although I can't be 100% sure), and the mono implementation is usually a bit smaller and simpler. In any case, I have refrained from copying too much, only the bare essentials to get things going.

Yes, DNA originally used Mono code for classes that didn't require any integration into the C interpreter, and I didn't have the time/inclination to write from scratch. Clearly corefx didn't exist at the time!
Note that the classes I wrote were generally written to be small, rather than performant; the platform I originally wrote this for was very resource limited. Although this was all so long ago I can't really remember details.
Switching to using corefx code might now make some sense.

ncave · 2017-09-05T19:11:20Z

@SteveSandersonMS Rebased to latest.

arpadbarta · 2017-09-17T10:19:48Z

Love the project and eager to experiment with some ideas, but there are quite few outstanding PR's that contain a lot of changes. Could some of the PR-s be merged?

SteveSanderson · 2017-09-20T12:25:17Z

@arpadbarta I know it's taking a while to merge this, and apologies for that. But please don't expect this repo to be a typical open-source project in a normal phase of maintenance. Instead, this repo is an experiment, not intended to have any particular level of support. Future plans are still being worked out.

TylerBrinkley · 2017-09-20T12:38:49Z

Future plans are still being worked out.

I like the sound of that, given the Blazor-Hackathon on the official ASP.NET github org I'm hoping this may mean official Microsoft support!

MaverickMartyn · 2017-09-20T12:40:37Z

I can't wait to see what this becomes. I am getting all giddy. XD

ebekker · 2017-09-20T13:28:43Z

I'm hoping collaboration with mono-wasm can speed things along by sharing resources, and advancing both experiments to an officially supported set of tools. Each project has a different architectural approach (e.g. client-side Razor vs. browser-targeting XAML), but so much of the underlying core and foundation would be common and sharable by both teams.

gulshan · 2017-09-20T14:11:14Z

And there's also this- dotnet/corert#4480

JohnGalt1717 · 2017-09-20T14:17:36Z

Microsoft really really really needs to take command of this, make it official and pull all of these initiatives together and get a cohesive whole that has 2 paths:

HTML with angular/razor style markup that generates an SPA
XAML SPA

Pick which you want to use. In either case, both should automatically become a best of breed UWP application when targeted at the store with additional functionality available.

And they should direct compile to iOS and Android as well. (without a requirement for a mac, meaning MS has to put the build and test stuff in the cloud for iOS and give it away free to devs so they have no reason to ever use a mac)

stavroskasidis · 2017-10-09T19:09:00Z

Every single time I fire up a "React getting started" tutorial with typescript, webpack and redux, 5 minutes later I have stopped reading in frustration and I find myself back to this repo, gazing at the "what-could-be" future.

I have done the "Todo List" sample in Blazor multiple times by now, demoing it to some colleagues, and every time it reminds me how easy and natural it feels writing in it.

The timing is right. I believe that web assembly will even the playing field. It's time to seize this opportunity and make C# the go-to language for full stack web development.

Please make this happen !! T_T

SteveSandersonMS · 2017-10-30T14:57:34Z

Thanks @ncave for continuing to contribute to this! Just so you know, our hope is to move away from the DNA runtime shortly and replace it with a more full-featured one. If this works out (no guarantees yet though) then you could absolutely still continue to develop DNA (and there might indeed be demand for that as it might always be the smallest .NET runtime there is), but it would be good to move that over to another repo under your control. Does that sound OK?

ncave · 2017-10-30T15:10:43Z

@SteveSandersonMS Thanks Steve, I figured you guys are up to something, and that's awesome, can't wait to see it. I already have another DNA development repo, that's where the updates are coming from.

mattwarren · 2017-10-30T15:26:41Z

BTW In case you haven't seen it, I wrote a post to try and let more people know about DNA, see DotNetAnywhere: An Alternative .NET Runtime.

There's also some interesting follow-up discussions, see HackerNews and /r/programming (including comments from @chrisdunelm)

ncave · 2017-10-30T15:34:29Z

@mattwarren Of course I've seen it, great write-up, so much depth and detail. Thanks for the links!

Postlagerkarte · 2017-10-30T17:30:28Z

It is so great that this thing keeps moving! Can't wait to see it happen.

While waiting I enjoyed browsing the following three repositories:

CoreRT

WebAssembly is a new technology for running code at near-native speed in browsers. A group of folks on the .NET team worked together to see what WebAssembly might look like using CoreRT.

They also issued a call for help dotnet/corert#4659

I have seen several pull requested merged in the last few days. So there is some action going on there.

WebSharp

This project is intended to support running .NET code as an Electron Plugin, running code using the Mono runtime, side-by-side the V8 engine and to provide both C# API bindings to Electron's plugin API as well as the Web browser API.

Last commit was 6 weeks ago. Seems like no public action going on here anymore.

MonoWasm

This project is a proof-of-concept aiming at building C# applications into WebAssembly, by using Mono and compiling/linking everything statically into one .wasm file that can be easily delivered to browsers

This repository is owned by Laurent Sansonetti who works for Microsoft in Belgium. Steve and Laurent exchanged some emails and they tried to get it running with Blazor.

Last commit was 10 days ago.

Terricide · 2017-10-30T17:39:52Z

In excited for the debugging support that blazor is doing. Hopefully it will be useful for the other frameworks.

stavroskasidis · 2017-11-06T09:55:07Z

Moved to mono runtime!
Awesome

wanton7 · 2017-12-05T23:35:35Z

Not sure if this is correct place to ask. But after browsing ClientServerApp sample I noticed it uses bootstrap that uses jQuery. How does Blazor work with jQuery without memory leaks? What I mean is, lets say you have following

<div id="foobar">
  <a id="my">Click me</a>
</div>
<script>
$("#my").on("click", function () { console.log("clicked"); });
$("#my").data("foo", "bar");
$("#foobar").html("");
</script>

In this situation jQuery automatically removes events and element data attached to #my from memory. But if you replace $("#foobar").html("") with document.getElementById("foobar").innerHTML = "" it doesn't remove them and this causes memory leak.

api.jquery.com/html

Also about Bootstrap modal that is used in sample, when you open a bootstrap modal it appends elements to end of body that need additional cleanup to remove completely. With Bootstrap 3 it's harder to clean up. With Bootstrap 4 you can use .modal('dispose').

How can you remove jQuery components properly with Blazor? This applies to vanilla JavaScript components as well that need cleanup. Angular 2+ has ngOnDestroy, React has componentWillUnmount and VueJS has beforeDestroy events for that.

ChicagoDave · 2017-12-18T06:37:50Z

Wish list:
basic XAML (doesn't need to be all of WPF), canvas, controls, layout, and styles first...animation later
full HttpClient

ncave mentioned this pull request Aug 14, 2017

ncave's JIT and corlib updates #6

Open

chrisdunelm reviewed Sep 3, 2017

View reviewed changes

davidfowl reviewed Sep 3, 2017

View reviewed changes

corlib and JIT updates

fe8e672

corlib and JIT updates 2

56d1733

corlib and JIT updates 3

c14ddb5

stavroskasidis mentioned this pull request Sep 22, 2017

Implemented "FromAttribute" for component parameters #11

Open

corlib and JIT updates 4

716e324

ncave mentioned this pull request Oct 30, 2017

What about tailcalls? chrisdunelm/DotNetAnywhere#8

Closed

corlib and JIT updates #7

Are you sure you want to change the base?

corlib and JIT updates #7

Conversation

ncave commented Aug 14, 2017 • edited Loading

Terricide commented Aug 17, 2017

stavroskasidis commented Aug 24, 2017

rvhuang commented Aug 25, 2017

chris-ray commented Aug 25, 2017

xiaowuchiu commented Aug 25, 2017

stavroskasidis commented Aug 25, 2017

stavroskasidis commented Aug 26, 2017 • edited Loading

JohnGalt1717 commented Aug 26, 2017

stavroskasidis commented Aug 26, 2017 • edited Loading

pineywoods commented Aug 26, 2017

RonPenton commented Aug 26, 2017

RonPenton commented Aug 26, 2017

yanglee commented Aug 26, 2017

ncave commented Aug 26, 2017

csells commented Aug 26, 2017 via email

TylerBrinkley commented Aug 30, 2017 • edited Loading

chrisdunelm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ncave Sep 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ncave commented Sep 5, 2017

arpadbarta commented Sep 17, 2017

SteveSanderson commented Sep 20, 2017

TylerBrinkley commented Sep 20, 2017 • edited Loading

MaverickMartyn commented Sep 20, 2017

ebekker commented Sep 20, 2017

gulshan commented Sep 20, 2017

JohnGalt1717 commented Sep 20, 2017

stavroskasidis commented Oct 9, 2017

SteveSandersonMS commented Oct 30, 2017

ncave commented Oct 30, 2017

mattwarren commented Oct 30, 2017

ncave commented Oct 30, 2017 • edited Loading

Postlagerkarte commented Oct 30, 2017 • edited Loading

Terricide commented Oct 30, 2017

stavroskasidis commented Nov 6, 2017

wanton7 commented Dec 5, 2017

ChicagoDave commented Dec 18, 2017

ncave commented Aug 14, 2017 •

edited

Loading

stavroskasidis commented Aug 26, 2017 •

edited

Loading

stavroskasidis commented Aug 26, 2017 •

edited

Loading

TylerBrinkley commented Aug 30, 2017 •

edited

Loading

ncave Sep 3, 2017 •

edited

Loading

TylerBrinkley commented Sep 20, 2017 •

edited

Loading

ncave commented Oct 30, 2017 •

edited

Loading

Postlagerkarte commented Oct 30, 2017 •

edited

Loading