JIT: Optimize out write barriers for fields in ref-like structs by EgorBo · Pull Request #103503 · dotnet/runtime

EgorBo · 2024-06-15T05:06:01Z

Remove write barriers for fields of ref ByrefLikeStruct arguments since we know that such refs always point to stack, Example:

voidTest(refMyStructs,objecto1,objecto2){s.A=o1;s.B=o2;}refstructMyStruct{publicobjectA;publicobjectB;}

Codegen for Test(...) on Main:

; Method Prog:Test(byref,System.Object,System.Object):this (FullOpts)G_M1451_IG01:pushrsipushrbxmovrbx,rdxmovrsi,r9G_M1451_IG02:movrcx,rbxmovrdx,r8call CORINFO_HELP_CHECKED_ASSIGN_REFlearcx, bword ptr [rbx+0x08]movrdx,rsicall CORINFO_HELP_CHECKED_ASSIGN_REFnopG_M1451_IG03:poprbxpoprsiret; Total bytes of code: 35

This PR:

; Method Prog:Test(byref,System.Object,System.Object):this (FullOpts)G_M1451_IG01:G_M1451_IG02:mov gword ptr [rdx],r8mov gword ptr [rdx+0x08],r9G_M1451_IG03:ret; Total bytes of code: 8

Similar case when ref struct is "this":

refstructRefLike{publicobjecto;publicvoidTest(objecto){this.o=o;// Main: checked-write-barrier, PR: no-barrier}}

EgorBo · 2024-06-15T06:17:36Z

@MihuBot

EgorBo · 2024-06-15T07:28:14Z

@EgorBot

usingBenchmarkDotNet.Attributes;usingSystem.Runtime.CompilerServices;publicclassMyBench{[Benchmark]publicvoidBench(){MyStructs=default;Test(refs,null,null);}[MethodImpl(MethodImplOptions.NoInlining)]voidTest(refMyStructs,objecto1,objecto2){s.A=o1;s.B=o2;}refstructMyStruct{publicobjectA;publicobjectB;}}

EgorBot · 2024-06-15T07:43:28Z

Benchmark results on Intel

BenchmarkDotNet v0.13.12, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Intel Xeon Platinum 8370C CPU 2.80GHz, 1 CPU, 16 logical and 8 physical cores
Job-YFOKOK : .NET 9.0.0 (42.42.42.42424), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
Job-EVRGON : .NET 9.0.0 (42.42.42.42424), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI

Method	Toolchain	Mean	Error	Ratio
Bench	Main	4.631 ns	0.0076 ns	1.00
Bench	PR	1.720 ns	0.0002 ns	0.37

BDN_Artifacts.zip

hez2010 · 2024-06-15T07:46:03Z

I think we can also do this for objects allocated on the stack due to escape analysis.

EgorBo · 2024-06-15T07:48:37Z

I think this can also be done for objects allocated on the stack due to escape analysis.

We already do that where it's legal afair. Although, in some cases we have to switch to slower "checked" write barriers when "object on stack" feature is enabled since TYP_REF no longer gives the "always on heap" guarantees.

EgorBo · 2024-06-15T11:16:43Z

PTAL @jakobbotsch @AndyAyersMS cc @dotnet/jit-contrib (CI failures are unrelated). Diffs

EgorBo · 2024-06-15T14:39:08Z

@EgorBot -arm64 -profiler

usingBenchmarkDotNet.Attributes;usingSystem.Runtime.CompilerServices;publicclassMyBench{[Benchmark]publicvoidBench(){MyStructs=default;Test(refs,null,null);}[MethodImpl(MethodImplOptions.NoInlining)]voidTest(refMyStructs,objecto1,objecto2){s.A=o1;s.B=o2;}refstructMyStruct{publicobjectA;publicobjectB;}}

EgorBot · 2024-06-15T15:01:38Z

Benchmark results on Arm64

BenchmarkDotNet v0.13.12, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Unknown processor
Job-IRHBKJ : .NET 9.0.0 (42.42.42.42424), Arm64 RyuJIT AdvSIMD
Job-UINBZM : .NET 9.0.0 (42.42.42.42424), Arm64 RyuJIT AdvSIMD

Method	Toolchain	Mean	Error	Ratio
Bench	Main	3.982 ns	0.0029 ns	1.00
Bench	PR	2.696 ns	0.0425 ns	0.68

BDN_Artifacts.zip

Flame graphs: Main vs PR 🔥
Hot asm: Main vs PR
Hot functions: Main vs PR

For clean perf results, make sure you have just one [Benchmark] in your app.

jkotas · 2024-06-15T17:02:18Z


+ if (info.compMethodInfo->args.hasImplicitThis() && varNum == info.compThisArg)
+ {
+ // implicit this doesn't map to any IL arg


Suggested change
// implicit this doesn't map to any IL arg
// implicit this doesn't map to any method signature arg
assuming this change is otherwise correct that I am not sure about

I reverted those changes since compMap2ILvarNum is also used in debug info generation and I don't want to break it accidentally. I put the workaround directly to my function.

jakobbotsch

This change has the same change in our aliasing model as #97997 that we rejected did (relevant comment: #97997 (comment)).

Basically, before this change, it is ok in our aliasing model to write code like this:

structA{publicobjectX;}refstructB{publicobjectX;}voidFoo(B*b){((A*)b)->X="abc";}voidBar(A*a){Foo((B*)a);}

The optimization made by this PR is only valid if we consider this kind of aliasing to be UB. I am fine with doing that if the diffs justify it, but it is something to be aware about and explicit around if we take this change.

jakobbotsch · 2024-06-16T17:59:59Z

+ // Check if we deal with `ref ByrefLikeStruct` argument
+ unsigned lclNum = (unsigned)vnStore->CoercedConstantValue<ssize_t>(funcApp.m_args[0]);
+ assert(lclNum != BAD_VAR_NUM);
+ if (comp->lvaIsParameter(lclNum))
+ {
+ if (comp->info.compThisArg == lclNum)
+ {
+ // No barrier needed if current class is byref-like
+ // and the destination is an implicit "this"
+ return comp->eeIsByrefLike(comp->info.compClassHnd) ? GCInfo::WriteBarrierForm::WBF_NoBarrier
+ : GCInfo::WriteBarrierForm::WBF_BarrierUnknown;
+ }
+
+ // Find the corresponding argument index. Basically, we need to ignore the hidden args
+ // such as generic context, return buffer, etc..
+ unsigned ilArg = comp->compMap2ILvarNum(lclNum);
+ switch (static_cast<int>(ilArg))
+ {
+ // Ignore non-user args
+ case ICorDebugInfo::RETBUF_ILNUM:
+ case ICorDebugInfo::VARARGS_HND_ILNUM:
+ case ICorDebugInfo::TYPECTXT_ILNUM:
+ case ICorDebugInfo::UNKNOWN_ILNUM:
+ return GCInfo::WriteBarrierForm::WBF_BarrierUnknown;
+
+ default:
+ break;
+ }
+ assert(ilArg != BAD_VAR_NUM);
+
+ // A small inconsistency: various signature walking VM APIs (e.g. getArgClass)
+ // do not expose implicit "this" args, while compMap2ILvarNum does.
+ if (comp->info.compMethodInfo->args.hasImplicitThis())
+ {
+ assert(ilArg > 0);
+ ilArg--;
+ }
+
+ // First, get corresponding CORINFO_ARG_LIST_HANDLE arg data
+ CORINFO_ARG_LIST_HANDLE currentArg = comp->info.compMethodInfo->args.args;
+ for (unsigned i = 0; i < ilArg; i++)
+ {
+ currentArg = comp->info.compCompHnd->getArgNext(currentArg);
+ }
+
+ // Now get its type and strip `ref` so we can get CORINFO_CLASS_HANDLE of the
+ // underlying type
+ CORINFO_CLASS_HANDLE byrefCls = comp->eeGetArgClass(&comp->info.compMethodInfo->args, currentArg);
+ if (byrefCls != NO_CLASS_HANDLE)
+ {
+ CORINFO_CLASS_HANDLE actualCls;
+ CorInfoType actualClsType = comp->info.compCompHnd->getChildType(byrefCls, &actualCls);
+
+ // Only structs can be byref-like
+ if (actualClsType == CORINFO_TYPE_VALUECLASS)
+ {
+ assert(actualCls != NO_CLASS_HANDLE);
+ if (comp->eeIsByrefLike(actualCls))
+ {
+ // It's byref-like, barrier is not needed
+ return GCInfo::WriteBarrierForm::WBF_NoBarrier;
+ }
+ }
+ }
+ }
+ return GCInfo::WriteBarrierForm::WBF_BarrierUnknown;


This look potentially quite expensive. You may want to try running an SPMI collection on this PR to get more accurate diffs, there are a lot of misses.

jakobbotsch · 2024-06-16T18:02:13Z

+ // Now get its type and strip `ref` so we can get CORINFO_CLASS_HANDLE of the
+ // underlying type
+ CORINFO_CLASS_HANDLE byrefCls = comp->eeGetArgClass(&comp->info.compMethodInfo->args, currentArg);
+ if (byrefCls != NO_CLASS_HANDLE)


What is actually checking that this is a byref to that type? Would this potentially pass for an array as well?

The entire code sequence is a bit unfortunate... it would be much cleaner/less scary looking if we had just saved enough information in LclVarDsc (or a side table, similar to lvaParameterPassingInfo) to get the full class handle for the parameter. I suppose the main problem around that is that we don't actually call getArgClass on all parameters today, only on TYP_REF parameters.
I wonder if we should just bite the bullet and call getArgClass on all parameters, or perhaps change getArgType to unconditionally return a class handle (today it only returns the class handle for value classes).

Agree -- we should compute this early when we first process the method and local sigs and cache it on the local var.

jkotas · 2024-06-16T18:41:23Z

The optimization made by this PR is only valid if we consider this kind of aliasing to be UB.

I think it is fine to make this form of aliasing UB, in particular when it involves managed types.

EgorBo · 2024-06-16T23:44:29Z

if the diffs justify it

Current diffs are not too big, but I am wondering if we can, sort of, mark more internal structs as stack-only where it's allowed - I already tried that for CoreLib and found 50 structs eligable for it.

Also, perhaps, e.g. NativeAOT can do this as part of IL analysis as an optimization

EgorBo · 2024-06-16T23:44:35Z

@MihuBot

EgorBo · 2024-06-22T15:11:19Z

@EgorBot -profiler

usingBenchmarkDotNet.Attributes;usingSystem.Runtime.CompilerServices;publicclassMyBench{[Benchmark]publicvoidBench(){MyStructs=default;Test(refs,null,null);}[MethodImpl(MethodImplOptions.NoInlining)]voidTest(refMyStructs,objecto1,objecto2){s.A=o1;s.B=o2;}refstructMyStruct{publicobjectA;publicobjectB;}}

EgorBot · 2024-06-22T15:30:23Z

Benchmark results on Intel

BenchmarkDotNet v0.13.12, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Intel Xeon Platinum 8370C CPU 2.80GHz, 1 CPU, 16 logical and 8 physical cores
Job-VSVRXS : .NET 9.0.0 (42.42.42.42424), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
Job-CUMSFN : .NET 9.0.0 (42.42.42.42424), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI

Method	Toolchain	Mean	Error	Ratio
Bench	Main	4.366 ns	0.0080 ns	1.00
Bench	PR	1.437 ns	0.0006 ns	0.33

BDN_Artifacts.zip

Flame graphs: Main vs PR 🔥
Hot asm: Main vs PR
Hot functions: Main vs PR

For clean perf results, make sure you have just one [Benchmark] in your app.

AndyAyersMS

We might also be able to make the conservative VNs for these structs more aggressive (they can match the liberal vns), since they can't be modified cross-thread.

AndyAyersMS · 2024-06-24T15:40:42Z

+ // Now get its type and strip `ref` so we can get CORINFO_CLASS_HANDLE of the
+ // underlying type
+ CORINFO_CLASS_HANDLE byrefCls = comp->eeGetArgClass(&comp->info.compMethodInfo->args, currentArg);
+ if (byrefCls != NO_CLASS_HANDLE)


Agree -- we should compute this early when we first process the method and local sigs and cache it on the local var.

EgorBo · 2024-06-26T13:25:05Z

@jakobbotsch @AndyAyersMS can you take a look again? I ended up reserving a bitfield in LclVarDesc

win-x64 Release layout

4>class LclVarDsc	size(72):
4>	+---
4> 0.	| var_types lvType (bitstart=0,nbits=5)
4> 0.	| lvIsParam (bitstart=5,nbits=1)
4> 0.	| lvIsRegArg (bitstart=6,nbits=1)
4> 0.	| lvFramePointerBased (bitstart=7,nbits=1)
4> 1.	| lvOnFrame (bitstart=0,nbits=1)
4> 1.	| lvRegister (bitstart=1,nbits=1)
4> 1.	| lvTracked (bitstart=2,nbits=1)
4> 1.	| lvPinned (bitstart=3,nbits=1)
4> 1.	| lvMustInit (bitstart=4,nbits=1)
4> 1.	| m_addrExposed (bitstart=5,nbits=1)
4> 1.	| lvDoNotEnregister (bitstart=6,nbits=1)
4> 1.	| lvFieldAccessed (bitstart=7,nbits=1)
4> 2.	| lvLiveInOutOfHndlr (bitstart=0,nbits=1)
4> 2.	| lvInSsa (bitstart=1,nbits=1)
4> 2.	| lvIsCSE (bitstart=2,nbits=1)
4> 2.	| lvHasLdAddrOp (bitstart=3,nbits=1)
4> 2.	| lvHasILStoreOp (bitstart=4,nbits=1)
4> 2.	| lvHasMultipleILStoreOp (bitstart=5,nbits=1)
4> 2.	| lvIsTemp (bitstart=6,nbits=1)
4> 2.	| lvIsImplicitByRef (bitstart=7,nbits=1)
4> 3.	| lvIsLastUseCopyOmissionCandidate (bitstart=0,nbits=1)
4> 3.	| lvSingleDef (bitstart=1,nbits=1)
4> 3.	| lvSingleDefRegCandidate (bitstart=2,nbits=1)
4> 3.	| lvDisqualifySingleDefRegCandidate (bitstart=3,nbits=1)
4> 3.	| lvSpillAtSingleDef (bitstart=4,nbits=1)
4> 3.	| lvHasExceptionalUsesHint (bitstart=5,nbits=1)
4> 3.	| lvQuirkToLong (bitstart=6,nbits=1)
4> 3.	| lvIsPtr (bitstart=7,nbits=1)
4> 4.	| lvIsUnsafeBuffer (bitstart=0,nbits=1)
4> 4.	| lvPromoted (bitstart=1,nbits=1)
4> 4.	| lvIsStructField (bitstart=2,nbits=1)
4> 4.	| lvContainsHoles (bitstart=3,nbits=1)
4> 4.	| lvAnySignificantPadding (bitstart=4,nbits=1)
4> 4.	| lvIsMultiRegArg (bitstart=5,nbits=1)
4> 4.	| lvIsMultiRegRet (bitstart=6,nbits=1)
4> 4.	| lvLRACandidate (bitstart=7,nbits=1)
4> 5.	| lvUsedInSIMDIntrinsic (bitstart=0,nbits=1)
4> 5.	| lvRegStruct (bitstart=1,nbits=1)
4> 5.	| lvClassIsExact (bitstart=2,nbits=1)
4> 5.	| lvImplicitlyReferenced (bitstart=3,nbits=1)
4> 5.	| lvSuppressedZeroInit (bitstart=4,nbits=1)
4> 5.	| lvHasExplicitInit (bitstart=5,nbits=1)
4> 5.	| lvIsOSRLocal (bitstart=6,nbits=1)
4> 5.	| lvIsOSRExposedLocal (bitstart=7,nbits=1)
4> 6.	| lvRedefinedInEmbeddedStatement (bitstart=0,nbits=1)
4> 6.	| lvIsNeverNegative (bitstart=1,nbits=1)
4> 6.	| lvIsSpan (bitstart=2,nbits=1)
4> | <alignment member> (size=1) <-------------------- HERE!
4> 8	| lvFieldLclStart
4> 8	| lvParentLcl
4>12	| lvFieldCnt
4>13	| lvFldOffset
4>14	| lvFldOrdinal
4>15.	| lvAllDefsAreNoGc (bitstart=0,nbits=1)
4>16	| _lvRegNum
4>17	| _lvArgReg
4>18	| _lvArgInitReg
4> | <alignment member> (size=1)
4>20	| lvVarIndex
4>22	| m_lvRefCnt
4>24	| m_lvRefCntWtd
4>32	| lvStkOffs
4>36	| lvSlotNum
4>40	| lvClassHnd
4>48	| m_layout
4>56	| ?$SsaDefArray@VLclSsaVarDsc@@ lvPerSsaData
4>	+---

I also considered re-using lvClassHnd or m_Layout fields for it, but that required a bit more changes. Same Diffs with many missing contexts (jit-diff is the same).
I was thinking to play with "interproc" analysis and mark more structs as "never leave stack" to get bigger diffs (there are many cases), but will do it separately

jakobbotsch · 2024-06-26T13:38:28Z

+ case ELEMENT_TYPE_BYREF:
+ typeHnd = ptr.GetTypeHandleThrowing(pModule, &typeContext);
+ break;


Can we do it for all types? If not, can we at least do it for ELEMENT_TYPE_PTR as well?
The documentation of the JIT-EE API should be updated (vcTypeRet should probably be renamed too). Also, what about crossgen2/NAOT implementations of this API?

Does doing this cause the operand type of the byref/pointer to be loaded eagerly?

Also, what about crossgen2/NAOT implementations of this API?
They seem to already always return it, so my test snippet is optimized there too

Does doing this cause the operand type of the byref/pointer to be loaded eagerly?
How do I check that? I presume since it's a parameter it's going to be loaded anyway?

Can we do it for all types?
Any particular reason to do that? Isn't, like you mentioned, it might lead to redundant type load events we don't need?

How do I check that? I presume since it's a parameter it's going to be loaded anyway?
Maybe @jkotas can answer this question?
Any particular reason to do that? Isn't, like you mentioned, it might lead to redundant type load events we don't need?
The reason would be to make the JIT-EE API more regular in its contract, and avoid us having to call back to the EE side in the other cases too (e.g. we want this information for class types as well, and we currently do another JIT-EE call to get it). We could remove getArgClass entirely if getArgType just returned the class handle always.

it might lead to redundant type load events we don't need?
Once we load the type, the future attempts to load the type are cheap. There is not such a thing as "redundant type load events".
The point is to avoid loading the type in the first place. As you can see in the ELEMENT_TYPE_PTR comment below, eagerly loading types that do not need to be loaded can even break stuff. Avoiding unnecessary type loading is goodness for startup.
I think the JIT should never need to load the unmanaged pointer types. It should treat all unmanaged pointers as opaque void*.
This optimization should be based on the type provided in the stfld metadata token.

This optimization should be based on the type provided in the stfld metadata token.
Actually, this might simplify changes a lot, let me try

This optimization should be based on the type provided in the stfld metadata token.
This would also be much more in line with how our normal modelling of aliasing and stores/loads work and effectively would mean that we aren't changing the aliasing model, so if we can do that it seems like it would be much cleaner overall.

jakobbotsch · 2024-06-26T13:42:10Z

 CORINFO_CLASS_HANDLE clsHnd = info.compCompHnd->getArgClass(&info.compMethodInfo->args, argLst);
 lvaSetClass(varDscInfo->varNum, clsHnd);
 }
+ else if (type == CORINFO_TYPE_BYREF)


Do we already avoid the write barrier if this was an unmanaged pointer?

Do you mean something like this:
unsafevoidTest(string*a,stringb){*a=b;}
isn't it not safe to remove WB here? And, hopefully, nobody does this anyway 🙂
Currenly it does emit a checked WB.

Yes, it would be unsafe to remove the write barrier there.
I think it means we should make this feature work for CORINFO_TYPE_PTR too, for parity between managed and unmanaged pointers. E.g.
[MethodImpl(MethodImplOptions.NoInlining)] void Test(MyStruct* s, object o1, object o2) { s->A = o1; s->B = o2; } ref struct MyStruct { public object A; public object B; }
should avoid the write barrier as well, like if it was a managed pointer.

NOTE that MyStruct* s is issueing a warning in Roslyn as an attempt to take an address of a managed type. Do we want to also eagerly load all types under unmanaged pointers in hope somebody do this (I presume it's rare/never).
cc @jkotas

I think it is fine to assume that both ref MyByRefLikeStruct and MyByRefLikeStruct* never point into GC heap here.

What I'm after is that we have consistency in optimizations like these. Switching a byref to a pointer because the target is on the stack should not come with surprising perf regressions like new write barriers.

EgorBo · 2024-06-26T15:05:23Z

@MihuBot

EgorBo · 2024-06-26T15:42:36Z

@MihuBot

EgorBo · 2024-06-26T16:07:23Z

Thanks for reviews and the suggestion, stsfld really eliminated all the complexity, no idea why I never thought about it 🙂

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 15, 2024

dotnet-policy-serviceBot assigned EgorBo Jun 15, 2024

MihuBot mentioned this pull request Jun 15, 2024
[X64] [EgorBo] JIT: Optimize out write barriers for fields in ref-like structs MihuBot/runtime-utils#415
Open

dotnet deleted a comment from EgorBot Jun 15, 2024

build-analysisBot mentioned this pull request Jun 15, 2024
GC/Regressions/v2.0-beta2/452950 failed in CI #103494
Closed

EgorBo marked this pull request as ready for review June 15, 2024 09:11

EgorBo requested review from AndyAyersMS and jakobbotsch June 15, 2024 11:16

jkotas reviewed Jun 15, 2024
View reviewed changes

Comment threadsrc/coreclr/inc/cordebuginfo.h Outdated

jkotas reviewed Jun 15, 2024
View reviewed changes

Comment threadsrc/coreclr/jit/lclvars.cpp Outdated

jkotas reviewed Jun 15, 2024
View reviewed changes

jakobbotsch reviewed Jun 16, 2024
View reviewed changes

MihuBot mentioned this pull request Jun 16, 2024
[X64] [EgorBo] JIT: Optimize out write barriers for fields in ref-like structs MihuBot/runtime-utils#443
Open

AndyAyersMS reviewed Jun 24, 2024
View reviewed changes

This was referenced Jun 26, 2024
TimeProviderTests.TestProviderTimer failed in CI #103459
Closed
The "RestoreTask" task returned false but did not log an error dotnet/dnceng#3100
Closed

jakobbotsch reviewed Jun 26, 2024
View reviewed changes

Simpler fix
ace3a9d

EgorBo force-pushed the optimize-byref-structs branch from 5436aba to ace3a9dCompare June 26, 2024 15:04

MihuBot mentioned this pull request Jun 26, 2024
[X64] [EgorBo] JIT: Optimize out write barriers for fields in ref-like structs MihuBot/runtime-utils#468
Open

jakobbotsch approved these changes Jun 26, 2024
View reviewed changes

fix typo
a8f35a4

MihuBot mentioned this pull request Jun 26, 2024
[X64] [EgorBo] JIT: Optimize out write barriers for fields in ref-like structs MihuBot/runtime-utils#469
Open

This was referenced Jun 26, 2024
Test failure: GC\\Scenarios\\FinalizeTimeout\\FinalizeTimeout\\FinalizeTimeout.cmd #103874
Closed
The job running on agent NetCore-Public ran longer than the maximum time #104044
Closed

EgorBo merged commit 520af01 into dotnet:mainJun 27, 2024

EgorBo deleted the optimize-byref-structs branch June 27, 2024 19:27

github-actionsBot locked and limited conversation to collaborators Jul 28, 2024

	// implicit this doesn't map to any IL arg
	// implicit this doesn't map to any method signature arg

Uh oh!

Conversation

EgorBo commented Jun 15, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EgorBo commented Jun 15, 2024

Uh oh!

EgorBo commented Jun 15, 2024

Uh oh!

EgorBot commented Jun 15, 2024

Uh oh!

hez2010 commented Jun 15, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EgorBo commented Jun 15, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EgorBo commented Jun 15, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EgorBo commented Jun 15, 2024

Uh oh!

EgorBot commented Jun 15, 2024

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotas commented Jun 16, 2024

Uh oh!

EgorBo commented Jun 16, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EgorBo commented Jun 16, 2024

Uh oh!

EgorBo commented Jun 22, 2024

Uh oh!

EgorBot commented Jun 22, 2024

Uh oh!

AndyAyersMS left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EgorBo commented Jun 26, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkotasJun 26, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

EgorBo commented Jun 15, 2024•
edited
Loading

hez2010 commented Jun 15, 2024•
edited
Loading

EgorBo commented Jun 15, 2024•
edited
Loading

EgorBo commented Jun 15, 2024•
edited
Loading

jakobbotsch left a comment •
edited
Loading

EgorBo commented Jun 16, 2024•
edited
Loading

EgorBo commented Jun 26, 2024•
edited
Loading

jkotasJun 26, 2024•
edited
Loading

EgorBoJun 26, 2024•
edited
Loading

jkotasJun 26, 2024•
edited
Loading