[Mono] Implement eager finalization of WeakReference

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!

[filipnavara]

No description provided.

[naricc]

I'm not sure I understand what is happening here. What does making finalization eager actually mean for WeakRefs? What is the behavior supposed to be?

[VSadov]

WeakReference types are finalizable types. Weak references could be used in big quantities and that can have bad effects on finalization queue.
The finalization of weak references is very trivial though - it is basically closing the underlying handle. It is generally cheaper to just close the handle when GC finds unreachable weak reference object, instead of posting it to the finalization queue.

The eager approach also has some reliability advantages. Since eager finalization happens when managed threads are stopped, there is no chance of getting into races between finalization and concurrent use of the weak references from other threads.

CoreCLR had eager finalization of weak references for a long time. NativeAOT has added that recently - #75436

Another advantage is that if Mono implements eager finalization, it would be able to use the shared implementation of WeakReference and WeakReference<T> without any ifdefs.

[filipnavara]

Thanks @VSadov for explaining it better than I would 👍

[lambdageek]

lgtm. although i'm not sure we should put weakreference into mono_defaults

[BrzVlad]

This change could further be improved by avoiding a useless object allocation. In sgen_finalize_in_range, copy_func is used to promote / mark the object, since it still needs to be alive to be passed as this to the finalizer. This should no longer be needed if it's eagerly finalized.

[VSadov]

@BrzVlad As I understand the suggestion, we need to move the specialcasing of weak references a bit earlier - from sgen_queue_finalization_entry up into sgen_finalize_in_range. Basically instead of copy_func (&copy, queue); we can just SGEN_HASH_TABLE_FOREACH_REMOVE (TRUE); and continue.

Is this the idea?

[BrzVlad]

@VSadov Yes, that is correct

[filipnavara]

Thanks for taking care of the last feedback, @VSadov!

[VSadov]

I assume the change addresses the suggestions and once llvmfullaot finishes we can merge the change.

[uweigand]

As of this commit, I'm now seeing failures when running the libs.tests suite on s390x (Mono-based runtime):

 Process terminated. Assertion failed.
WeakReference<T> finalizer should never run

Any suggestions what this could be, or how to further debug?

[BrzVlad]

I remember seeing this assertion locally but I didn't get to investigate it. I'll see if I can repro this week

[filipnavara]

@uweigand Do you have any details about which test is failing?

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

[uweigand]

Also interesting is that for some unknown reason, I'm not seeing any of these failures in the CI here:
https://dev.azure.com/dnceng-public/public/_build?definitionId=148
(which is doing a cross-build followed by native execution), but I'm seeing the failures all the time when building + testing fully natively on my own s390x machine.

[BrzVlad]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

[uweigand]

@uweigand Do you have any details about which test is failing?

It varies, I've seen multiple different tests failing. One that seems to fail most of the time is System.IO.FileSystem.Watcher.Tests.

I can reproduce, will take a look later

@BrzVlad did you have a chance to look into this?

[BrzVlad]

@uweigand Should be fixed by #77170

[filipnavara]

Thanks a lot!

[uweigand]

Yes, this has fixed the test suite on s390x. Thanks!