GC: make gcLock.lock/unlock inlinable

[rainers]

While looking at the disassembly for #1147 I noticed that lock/unlock on GCMutex are still called through the virtual function table, even though GCMutex is declared as final.
Calling Mutex.lock/unlock through a final method in GCMutex fails to inline, so I made final versions of the methods in Mutex.
In addition, making gcLock a property instead of a pointer avoids an indirection.

This change caused a 0-5% speedup for the benchmarks.

[MartinNowak]

That's fairly ugly to change the API, and you can't use package protection here.
Maybe we just copy over the implementation to the GC?

[MartinNowak]

And someone should fix the DMD bug, is it reported in Bugzilla?

[rainers]

And someone should fix the DMD bug, is it reported in Bugzilla?

I added https://issues.dlang.org/show_bug.cgi?id=14211

[MartinNowak]

Nice

[MartinNowak]

Yeah, a struct with the implementation from core sync mutex would be best, because I want to replace it with a spinlock anyhow.

[rainers]

Yeah, a struct with the implementation from core sync mutex would be best, because I want to replace it with a spinlock anyhow.

Good idea, done that.

[MartinNowak]

Looks like destroying the mutex fails because of an unbalanced calls to unlock.
c++ - pthread_mutex_destroy: why is it returning EBUSY?
Happens for rt.lifetime which tests FinalizeErrors. As we've learned during the spinlock pull, those don't perform proper cleanup in the GC. Maybe we should move the FinalizeError tests to an external test program that actually dies correctly.

[rainers]

Thanks for the info. I'm not sure why this works with the original GCMutex, though.

We could also add some minimalistic cleanup in case of a finalization error:

• add try/catch to Gcx.sweep
• cleanup code: running = false; gcLock.unlock(); throw ex;

[rainers]

dlang/dmd#4427 added the devirtualization, so this PR is obsolete.

[MartinNowak]

Nice