Unity Future .NET Development Status

As far as I’m aware, IGC does all of its work on the main thread, while .net’s GC can perform a large portion of its work in the background. (Scroll down to the first image to see what I mean.)

There’s also a huge benefit to using a standardized GC that gets updated alongside the industry, whereas Unity may need a lot of time and effort to make changes to outdated systems (exactly what’s been happening in this thread from the start).

 

That is not entirely true, or, rather, not in a way you are trying to say ,NET GC is also "stop the world" and it has to be, by definition. Actual GC work has to be done during this pause.
But this is irrelevant to my question.

I'm not sure how any of this bears any relevance to my specific question or why did you feel the need to reply in a first place.

 

@JoshPeterson when the new sdk style csproj projects come would it be possible to use F# for Unity? I would understand that it would not be officially supported, but nothing would stop it from being usable?

 

Technically, you already can. You just need to compile it outside unity and bring it in as a dll.

 

I understand that gen 0 collections are extremely fast in .Net's GC, and that will greatly contribute to lessening GC-related frame spikes. However, I imagine typical Unity development will end up putting lots of objects into gen 1, which may be a bit more expensive to run than gen 0. That's where I think an incremental GC would still help, especially since the current incremental GC gets to run "for free" up to the target FPS.

Heck, even a gen 2 collection would help if it could be broken up across multiple frames. Gen 2 obviously runs much less often, but I can also see it causing the largest frame spike when it does run. [Edit] Reading more about it, it seems gen 2 always runs in the background. So that should be a non-issue unless it's on a single-threaded app/system (WebGL? But that can only use IL2CPP).

Also, are there any plans to update the GC used in IL2CPP?

 

If Unity does make it incremental eventually, it would be cool to see (a bulk of) its features made on the .Net repo so that the whole C# world gets to enjoy it.

Again though, it seems that background garbage collection already takes care of this, only stopping the main thread to collect a working set, then operating on that set in the background (different link). It seems incredibly scaleable and unlikely to benefit much from incremental gc if you ask me, but I could be wrong.

 

Did you mean Boehm ?

 

No

 

Could you please tell me what's difference between these 2 then ? I cannot find Beohm GC in google

 

Here's the source of the garbage collector Unity uses: https://github.com/Unity-Technologies/bdwgc

As you can see, it's called "Boehm-Demers-Weiser conservative C/C++ Garbage Collector", usually referred as just "Boehm" for short.

 

@JoshPeterson is there any consideration for adding .NET's gcAllowVeryLargeObjects? There are a lot of people now using Unity for "serious games" where 2Gb is not an unusual, or honestly even large, dataset.

(Side note: Yes, making your own NativeLongArray seems like a good option here until you try it and realize none of the examples compile (the docs team knows...) and updating even the simplest NativeContainer examples from the internet which no longer compile with 2021.2 isn't trivial. I'm gave up and just went back to naked pointers... And even if you do that there's plenty of code you end up wanting to use which isn't DOTS, and it's usually less hassle to just work in C++ than to drag non-NativeArray C# to native collections. Plus, thanks to size_t, most C++ code works with large objects, wherease C# always has bits of int in a loop counter or something.)

 

@JoshPeterson I have found that running roslyn analyzers in unity increases the compilation time significantly. I have summarized my findings here https://github.com/needle-tools/compilation-visualizer/issues/7 Should I create a ticket about this or is this expected?

 

Having managed arrays/objects larger than 2 gigabytes is a really bad idea, it would significantly hamper the garbage collector's ability to compact the heap. If you need to store that much data, you should store it in unmanaged memory which does not get moved or controlled by the GC. You can see more information about this in a related discussion on the .NET runtime repository here.

 

OK I'm convinced handling this as a managed feature is a bad idea. I do think all native containers and systems that operate on them (IJobParallelFor etc) should start being tested with 64 bit indices though. Sorry, will stop hijacking this thread, but you're right.

 

It's probably too early yet but let me ask anyway.

Are u already measuring any performance increase (mainly for the editor itself)?

The last 3/4 years have put a lot of pressure on the aging editor architecture with a ton of new packages and features to the point using the editor (even after the recent improvements) is a bit frustrating :S

 

Hi all,

Is pattern matching from C#9 supported?

When I write this in Rider:

Code (CSharp):

1.  
2. switch (horizontalAxis)
3. {
4.     case > 0:

Unity responds with an error:

 error CS1525: Invalid expression term '<'

Shall I enable C#9 explicitly for the project?

 

I've posted issues with gRPC for .NET in issues with gRPC for .NET and Protobuf.

Unity support #1309
https://github.com/grpc/grpc-dotnet/issues/1309

FileNotFoundException with gRRC_for_.NET on Unity when using NuGetForUnity #9618
https://github.com/protocolbuffers/protobuf/issues/9618

 

@JoshPeterson thanks for all the work and effort towards a more standardized .NET experience.
Is there going to be an option to livestream your GDC talk next Monday?

 

Could the slide deck be uploaded here along with speaker notes after GDC but before the blog post? Really excited for this

 

Hi,

I have two questions.

1. Is there a plan to apply nullable reference annotations to the Unity API? Like

public System.Reflection.FieldInfo? GetField (string name);

E.g. the

public Component GetComponent(Type type);

can returns NULL.
If the annotation is correct

public Component? GetComponent(Type type);

and the nullable is enabled then:

Code (CSharp):

1. var com = GetComponent<SomeComponent>();
2. // The compiler warnings: Dereference of a possibly null reference. [Assembly-CSharp]csharp(CS8602)
3. var go = com.gameObject;

I suppose (hope) there are a lot of developers who want to write a high quality code. Nullable reference types help to atchieve this goal.

2. Is there a plan to support enabling of nullable for a Assembly Definition? Now we have to manually enable nullable for every single file.
We cannot enable nullable for whole project due to use a vendor code.

Thanks

 

If assembly definitions are to be replaced with .csproj, I suppose this would be possible out of the box?

 

You can also just add -nullable to the compiler arguments in the project settings and it will be enabled for the whole project. (as a workaround for now)

 

Just add a csc.rsp with -nullable as content if you want errors as well just do -warnaserror+ also. This needs to be done for every asmdef separately as csc.rsp are local to their containing asmdef.

 

Your solution is worse than adding it as an compiler argument.

 

This is exactly that. Adding it as a compiler argument but only for certain assemblies. Usually especially during a transition period you have code that has nullable enabled and code that doesn't. This allows you to fine tune which parts of your project are affected.

A lot of the Unity packages for example will error out on enabling nullables together with warnaserror.

 

Hi,

1. I understand that Unity API is large. Maybe more iterations will be required to apply all nullable annotations. Starts with Object, MonoBehaviour, ... which are the daily bread.
What I do not understand is For some projects enabling warning as errors, it would also introduce breaking changes.
Enabling nullable does not produce any error but only warnings. And warnings for nullable can be muted.
In the C#, only the question mark is added to type-hint definitions. I do not see to Unity internals so maybe it is not simple as I imagine.

2. I know about the "-nullable" compiler argument, but as I wrote, we cannot enable nullable for whole project due to use a vendor code. We do not want to see a bambilion warnings.
In an Assembly Definition we can check the Allow 'unsafe' Code option to generate <AllowUnsafeBlocks>True</AllowUnsafeBlocks>.
I suppose that adding of Allow Nullable for generating of <Nullable>enable</Nullable> should be easy.
But if there is a plan to replace the Assembly Definition system by something else in a reasonable time, we can wait.

 

2 - 'reasonable time' most likely not in the next 2 years.
2 - why don't you use the csc.rcp file solution then?

1 - the problem with annotating unity types / methods with nullability is that unity types themselves have special null behaviour. they practically never return true null but unity's fake Null. but it would be incredible if unity added nullability annotations to the unity api, though they will need to redo the null behaviour of unity objects for true null.
please unity, let us catch up to the standard.

 

Hi,

1. The Unity internal functionality is absolute irrelevant for this case. Nullable reference annotations are only for compiler and IDE warnings and do not have any effect to compiler result.
2. Because I do not how. I must study about csc.rsp first. One checkbox in the Assembly definition is more convenient.

 

1 - but if unity only returns fake Null, how are you then annotating the types / methods? as nullable? which would make them elegible to be checked with correct null checks aka variable is null instead of == (and also eligible for null coaelceon) which would break behaviour OR you don't annotate them because they are never null, then you should not check for null anywhere (which will then also break behaviour because they are still fake Null)

 

GameObject.GetComponent

Declaration
public Component GetComponent(Type type);

Description
Returns the component of Type type if the game object has one attached, null if it doesn't.

Code (CSharp):

1. private void Awake()
2. {
3.     var com = GetComponent<SampleMonoBehaviour>();
4.  
5.     // If the gameObject does not have assigned the SampleMonoBehaviour then
6.     // NullReferenceException: Object reference not set to an instance of an object
7.     var type = com.GetType();
8. }
9.  

If the API will have correct type-hint

public Component? GetComponent(Type type);

then the compiler and an IDE produce warning "Dereference of a possibly null reference. [Assembly-CSharp]csharp(CS8602)". The vscode will underlines the appropriate code. So a programmer will be informed that null check should be used.

The API doc tells us that the method can returns null. The code throws the exeption if null. The nullable annotation should be used.

 

It still stands that this may not be true behaviour for any unity method.

 

Keep in mind that in the editor, GetComponent will not actually return null. It will return a "fake" object that throws a NullReferenceException when accessing many of its members. This complicates using nullability analysis, because "obj is not null" will return true, while "obj != null" will return false. Similarly, unassigned serialized fields of Unity object types will also be assigned a "fake null" object.

Worse so, this "fake null" system does not exist in a build, so both "is not null" and "!= null" will return the same value for a component retrieved via GetComponent, leading to further inconsistencies and hard-to-diagnose issues.

 

That's exactly what i was talking about. Unity needs to rework this whole system please to support actual good nullability annotation / nullability analysis.

 

Wait what? The editor behaviour is different than the runtime behaviour here? I didn't know that. Just tested it and wow, that is completely unexpected. The Debugger even shows the objects as "null" but that's just its ToString representation.

This is really mind boggling why this is done. Most likely so there can be some nice custom error messages when it is accessed in editor. But this again just shows that for any unity object you need to always do a != null check on use even if its nullable. But yeah definitely second that this behaviour should change and at least methods that can return true null _should_ return true null whenever possible and never "fake" nulls.

This blog post from 2014 goes into detail about the fake null in editor: https://blog.unity.com/technology/custom-operator-should-we-keep-it

Interesting that apparently the end result of that discussion was "keep the custom null operator and fake null objects"

Is the custom null check of Unity Objects at least high performance when its actually comparing a null reference on one side?

Honestly I'm still shocked about this behaviour. Why would a system go against its own documentation and do things that only happen in one state (editor). As someone that tries to avoid working with GameObjects and MonoBehaviours as much as possible (and therefore is quite happy that true null exists in the space beyond those) it baffles me that this is still unchanged 8 years after it was already discussed as an issue. Especially because it goes against the actual documentation of the method. Unless I'm mistaken this is arcane knowledge that you just "have to know about" as its not properly documented.

 

The GetComponent version of fake null could be left in a dumpster. It's not helping anyone, and the difference between editor and runtime behavior is problematic.

Then again, we have shipped a bunch of games and that editor/runtime difference isn't something we have actually encountered, it's just something we know about as a curio.


The reason why this doesn't get changed is the behavior around destroying objects. The discussion has been had (or rather raged) quite a few times over the years, but what it comes down to is that since we're able to destroy objects, we have to check for if objects are destroyed. In almost all instances where we want to do that, we also want to check if it is null. So we'd have to introduce some extension method that does exactly the same thing as the current == null check, and then end up where we were, just slightly more theoretically correct and very much not backwards compatible.

 

And imo that would be beneficial to all going forward instead of keeping this arcane behaviour around any longer.

 

I think the problem with the current == null check is that in c# there are other ways to check for null that simply aren't covered by the custom == such as is null or ?? or even just ?.

Any modern null propagation feature croaks on the custom null behaviour unfortunately. I'd even be down with really just holding a wrapper to gameobjects that then have a property "actualObject" that could be either null or not (truly null) which can be set by the engine, and anyone holding a reference to the GameObject itself would have to deal with == null anyone holding a reference to the wrapper could be assured that actualObject is truly null vs fake null.

 

As a temporary workaround, we are only using our own extension methods when calling unity methods.

Code (CSharp):

1. public static T? GetComponentNullable<T>(this GameObject gameObject) where T : Component
2. {
3.         T comp = gameObject.GetComponent<T>();
4.         return comp == null ? null : comp;
5. }

but that still doesn't cover the possibility that the object itself could become null while executing other code. (by being Destroy() ed or similar)