Ladybird browser to start using Swift language this fall

Swift async/await is quite nice.

The Actor stuff is IMO way oversold - reentrancy issues make it not actually useful for the things that they claim, like querying a database. It’s still a useful construct to have, you just need to be aware of what it does or doesn’t provide.

Here's the rough timeline of the work:

Initial issue https://github.com/dotnet/runtime/issues/11192 was submitted in 2018 and concerns general research direction on feasibility and profitability of EA.

At the time, the results were very unpromising given compiler throughput impact: there were very few objects that were not escaping due to inlining limitations and (relatively) rudimentary approach to EA. In addition, there obviously was no impact on performance sensitive code that just used structs instead that are not reliant on fragile optimizations like this one.

Here, I would like to add a personal note that .NET teams are exposed to a much more well-behaved code and there existed (and still exists to an extent) bias that overlooks the nastiest and worst codebases that, no matter their issues and unnecessary allocation on every step, are an important optimization target. I think today there is a good degree of awareness and understanding of this bias, which drives further compiler improvements.

Back to EA. After initial research was done, the relevant code was merged into JIT - the feature was added around .NET 5 but remained disabled by default. Later on, it was occasionally in a broken state and generally not well validated against, given nothing used it besides compiler tests.

This, however, has changed in .NET 9. In order to understand why we first have to consider what were the changes in .NET's compiler in the previous versions.

Before .NET 7 and 8, JIT had nice but limited capability to perform something Java calls "scalar replacement" except for structs, the .NET name for this is "struct promotion". This feature "promotes" constituent struct fields to individual local values which are then stored in CPU registers or individual stack locations instead of "together" and being copied every time. This also included other common cases like treating single-field structs as an underlying field (making such wrappers effectively free). At the time, this optimization was great but nevertheless limited - there were restrictions on the amount of fields which could have been "promoted" and "enregistered" (up to 4 I believe?) as well as the depth - the quality of compiled code could easily regress if the target of promotion was nested within another struct, etc etc.

In order to address this, a new handling of struct promotion was introduced - "physical promotion": https://github.com/dotnet/runtime/issues/76928. This did away with the limitations of the past and enabled significantly better[1] handling of structs, allowing them to be optimized away, promoted without depth and count restrictions, propagate constants and assertions through struct fields, CSE more expressions on struct and more. This was a significant overhaul which pushed .NET's compiler output quality concerning structs way closer to the kind of behavior you would usually expect from GCC and LLVM.

At this point, I think you have an idea where this is leading to. Come in https://github.com/dotnet/runtime/pull/102808, an unrelated change which enabled the compiler to reason about propagation of addresses (object references, byref and unmanaged pointers) through struct fields. However, the importance of this change is that Steve (hez2010) noticed[0] that it may have closed the critical gap that previously prevented generalized optimizations enabling optimal struct handling from being applied to objects allocated on the stack. Once it was merged, it made the simpler scenarios EA was working for to produce the same optimal codegen you would see from structs as of .NET 8.

This and related discussions prompted further work on analyzing the most common unescaped allocation patterns and resulted in https://github.com/dotnet/runtime/pull/103361 by Andy Ayers. Once it was merged, it extended supported cases by previously limited EA capability, tuned inlining heuristics to make it light up more often and proved that the way it was handled as of the change was noticeably more profitable. It was subsequently enabled for NativeAOT and R2R as well: https://github.com/dotnet/runtime/pull/104411

As a result, .NET 9 will come with improved escape analysis capability, now enabled by default. It is still fairly limited but nonetheless an another change that incrementally adds to the nice "free" performance improvements everyone has grown to expect from bumping up a TFM version with each release for the last 7 years or so.

Further EA work is planned https://github.com/dotnet/runtime/issues/104936 and there are already initial experiments for .NET 10 like this one https://github.com/dotnet/runtime/pull/104906

I don't claim this timeline/sequence of events is perfectly accurate but I hope it sheds light on how and why this optimization has been evolving in .NET so far.

[0]: https://github.com/dotnet/runtime/pull/102808#issuecomment-2...

[1]: https://devblogs.microsoft.com/dotnet/performance-improvemen...

So, as far as I understand it, gender pronouns are typically for referring to individuals. This means that whether to call a baby, or animal, by gender pronouns or object pronouns varies depending on the expectation.

('gender pronouns' includes singular they/them, which is a 'gender pronoun' in the way that it perhaps, if you will, implies the 'gender' of 'neuter'...)

I guess a generally understood term for this would be "humanization", although as someone who identifies non-human that still sounds somewhat exclusive, but regardless, that is what I generally observe to be the difference.

So, it's possible to refer to a baby or an animal as an object, if, in doing so, you intend not to assign that object any individuality; in other words, if you're referring to it in a non-individualistic way.

e.g. "I needed to change its diaper again today" ("dehumanizing"; I guess shows a lack of empathy, but not everyone necessarily feels empathy for the baby before it is more markedly an individual)

It's also possible to refer to a non-individual (such as an inanimate object) as an individual, which, in doing so, typically implies that the non-individual nonetheless has some sort of individuality or that you're specifically assigning it such.

e.g. referring to ships / other vehicles using 'she'; also, giving everyday objects individuality is a relatively common part of Japanese culture (which is part of why Apple's recent "Crush!" ad upset so many)

Typically, it's respectful to refer to people as individuals because they are. It is "dehumanizing" to suggest otherwise. (seriously, is there a better word for this?)

Some prefer to be referred to as objects instead, though; I know at least one like this. But those will typically specify it in some way, and it's rude not to refer to any one as an individual unless otherwise specified.