| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This compat quirk is increasingly more broken since the framework is generally not compatible with, and we have not heard anybody actually using it.
Changed Environment.HasShutdownStarted to unconditionally return false. It does not make sense for it to ever return true with shutdown finalization disabled.
|
|
- Remove concept of AppDomain from object api in VM
- Various infrastructure around entering/leaving appdomains is removed
- Add small implementation of GetAppDomain for use by DAC (to match existing behavior)
- Simplify finalizer thread operations
- Eliminate AppDomain::Terminate
- Remove use of ADID from stresslog
- Remove thread enter/leave tracking from AppDomain
- Remove unused asm constants across all architectures
- Re-order header inclusion order to put gcenv.h before handletable
- Remove retail only sync block code involving appdomain index
|
|
|
|
The cost of doing this is showing up in the TechEmpower profiles. There is a lot of thread locale state in unmanaged libraries and OS APIs that the threadpool friendly code has to be aware off. It does not make sense to keep reseting just the Locale.
|
|
* Reorder extern "C" and visibility statements
In file included from coreclr/src/pal/inc/pal.h:70:0,
coreclr/src/pal/inc/pal_mstypes.h:30:25: error: expected unqualified-id
before string constant
#define EXTERN_C extern "C"
^
coreclr/src/pal/inc/rt/palrt.h:216:30: note:
in expansion of macro 'EXTERN_C'
#define STDAPI_(type) EXTERN_C type STDAPICALLTYPE
* Need double quotes around single quotes in error statements
fix error statements
Can't have ' character in error statement
* Abstract __declspec(noinline)
Generate compiler independent macros for noinline request.
* Remove unused DBG_NOINLINE_X86__RET_INLINE
* Abstract __declspec(nothrow)
|
|
|
|
* Delete vm/context.*
Leftover from remoting
|
|
|
|
* Remove AppDomain unload
This change removes all code in AppDomain that's related to AppDomain
unloading which is obsolete in CoreCLR. It also removes all calls to the
removed methods.
In few places, I have made the change simpler by taking into account the
fact that there is always just one AppDomain.
|
|
Fixes #3408
|
|
There was already some support for labeling threads using the Window SetThreadDescription API, however it was missing some important cases (like labeling the ThreadPool and GC server and Background threads). Fix this. Also make the naming consistant (they all start with .NET).
These names show up in PerfView traces and can be used by debuggers or other profilers as well.
|
|
Removed all usages of AppDomainLeaks configuration option and
CHECK_APP_DOMAIN_LEAKS feature
Fix #12094
|
|
Move initialization of YieldProcessorNormalized to the finalizer thread
Fixes https://github.com/dotnet/coreclr/issues/13984
- Also moved relevant functions out of the Thread class as requested in the issue
- For some reason, after moving the functions out of the Thread class, YieldProcessorNormalized was not getting inlined anymore. It seems to be important to have it be inlined such that the memory loads are hoisted out of outer loops. To remove the dependency on the compiler to do it (even with forceinline it's not possible to hoist sometimes, for instance InterlockedCompareExchnage loops), changed the signatures to do what is intended.
|
|
* Added SetThreadDescription to set the unmanaged thread name as well when a managed thread name was set.
This will show up in future debuggers which know how to read that information or in ETW traces in the Thread Name column.
* use printf instead of wprintf which exists on all platforms.
* Removed printf
Ensure that GetProceAddress is only called once to when the method is not present.
Potential perf hit should be negligible since setting a thread name can only happen once per managed thread.
* - Moved SetThreadName code to winfix.cpp as proposed
- Finalizer and threadpool threads get their name
- GCToEEInterface::CreateBackgroundThread is also named
- but regular GC threads have no name because when I included utilcode.h things did break apart.
* Fix for data race in g_pfnSetThreadDescription
* Fix string literals on unix builds.
* Fixed nits
Settled thread name on ".NET Core ThreadPool"
|
|
interface (#10463)
* [Local GC] BOOL -> bool on IGCHeap
* [Local GC] size_t -> void* on IGCHeap
* [Local GC] Silence warnings by being explicit about BOOl -> bool conversions
* Address code review feedback: FinalizeAppDomain BOOL -> bool
* Fix warnings
* Address code review feedback:
1) Fix a missed default parameter (FALSE) on a parameter of type bool,
2) Fix invocations of the diagnostic callbacks to use boolean literals
instead of TRUE and FALSE,
3) Fix various invocations of GC interface methods in the VM to use
boolean literals instead of TRUE and FALSE
* Address code review feedback: fix inconsistency
|
|
(#10413)
Add heuristic to trigger GC to finalize dead threads and clean up handles and memory
A thread that is started allocates some handles in Thread::AllocHandles(). After it terminates, the managed thread object needs to be collected by a GC for the handles to be released. Some applications that are mostly idle but have a timer ticking periodically will cause a thread pool thread to be created on each tick, since the thread pool preserves threads for a maximum of 20 seconds currently. Over time the number of handles accumulates to a high value. Thread creation adds some memory pressure, but that does not force a GC until a sufficiently large handle count, and for some mostly idle apps, that can be very long. The same issue arises with directly starting threads as well.
Fixes #6602:
- Track a dead thread count separately from the current dead thread count. This is the count that will contribute to triggering a GC, once it reaches a threshold. The count is tracked separately so that it may be reset to zero when a max-generation GC occurs, preventing dead threads that survive a GC due to references from contributing to triggering a GC again in this fashion.
- If the count exceeds a threshold, enumerate dead threads to see which GC generation the corresponding managed thread objects are in. If the duration of time since the last GC of the desired generation also exceeds a threshold, trigger a preferably non-blocking GC on the finalizer thread.
- Removed a couple of handles and some code paths specific to user-requested thread suspension, which is not supported on CoreCLR
|
|
* [x86/Linux] CDECL as default P/Invoke Calling Convetion
|
|
* Remove CLRIoCompletionHosted as it always returns false.
* Remove CLRSyncHosted as it always returns false.
* Remove CLRMemoryHosted as it always returns false.
* Remove CLRTaskHosted as it always returns false.
* Remove CLRAssemblyHosted, CLRGCHosted,and CLRSecurityHosted.
They are not called.
* Remove IsThreadPoolHosted as it always returns false.
* Remove EnterRuntime and LeaveRuntime, as they do nothing.
* Add back calls to RevertIfImpersonated and GCX_PREEMP.
I accidentally deleted the call to RevertIfImpersonated instead of just
removing an extra parameter.
When I removed the HR_LEAVE_RUNTIME_HOLDER macro from windowsruntime.h,
I not only removed a LeaveRuntimeHolder but also a GCX_PREEMP. So I added
it back. The holder and GCX_PREEMP where only inserted when the
FEATURE_LEAVE_RUNTIME_HOLDER macro was defined. Since it is always defined,
I removed it. Also as I understand it, you would always want to have a
GCX_PREEMP before calling into the Windows API as not to block the GC,
so I'm not sure why you would want to disable it.
|
|
|
|
|
|
* Add three finalization-related operations to GCToEEInterface and utilize them from the GC
* Code review feedback
* Code review feedback
* Fix standalone GC build break
* Repair the standalone GC build
|
|
modifying the VM to utilize this interface.
Introduce an interface separating the GC and the rest of the VM
Remove static members of both IGCHeap and IGCHeapInternal and move the management of the singular GC heap to the VM.
Rename uses of IGCHeap in the VM to GCHeapHolder, as well as other misc. renames throughout the VM and GC.
Split each interface function into categories, document them, use consistent formatting across the interface
Undo some accidental find/replace collateral damage
Remove all ifdefs from the GC interface
Deduplicate function declarations between IGCHeap and IGCHeapInternal, expose AllocAlign8 through the interface and the reference to alloc_context to repair the ARM build
Paper cut: false -> nullptr
Repair the ARM and x86 builds
Rename GCHeapHolder -> GCHeapUtilities and address documentation feedback
Rebase against master
Rename gcholder.h/cpp -> gcheaputilities.h/cpp
Fix an uninitialized field on alloc_context causing test failures on clang
Rename the include guard for gcheaputilities.h
Un-breaks SOS by making the following changes:
1) Instructs the DAC to look for IGCHeap::gcHeapType by name,
instead of assuming that it exists near g_pGCHeap,
2) Eliminate all virtual calls on IGCHeap in the DAC, since we cannot
dispatch on an object in another process,
3) Because of 2, expose the number of generations past the GC interface
using a static variable on IGCHeap that the DAC can read directly.
repair the Windows build
|
|
This change fixes a problem that happened when the `gc_heap::create_bgc_thread`
calls SetupUnstartedThread and it fails to allocate a Thread object and throws.
The GC doesn't expect that and so when the stack is unwound, the `gc_heap::gc_started`
stays set. Now we try to allocate memory for the Throwable for the exception, so we go
to GC heap and since there is not enough space, we end up calling
`gc_heap::try_allocate_more_space`, which calls `gc_heap::wait_for_gc_done`.
And that’s the end of it, since the `gc_started` is still set and we wait forever.
The fix is to catch exception from the SetupUnstartedThread. I have also fixed couple of
places where this method was being called and the exception was not expected.
As an additional cleanup, I have moved the thread creation in GC to the GCToEEInterface.
|
|
This commit tries to disable heap dump on linux if FEATURE_EVENT_TRACE
is not set in order to fix #5546.
|
|
commit 45d11dde6acdc3def0a13302c527e3c7a662b009
Author: David Mason <davmason@microsoft.com>
Date: Wed May 25 19:00:10 2016 -0700
Squashed commit of the following:
commit f586c5552d8225f13b5a0476f5bdf9362ba9ee8d
Author: Lee Culver <leculver@microsoft.com>
Date: Wed May 25 14:17:45 2016 -0700
Fix heap dump GC type to be Induced
Previously we didn't set the GC type to be "Induced" when collecting a heap dump. This would cause perfview to ignore the GC.
commit 78866dfdcc15ebade0a2faeb6af9a5b7f5e0a170
Author: Lee Culver <leculver@microsoft.com>
Date: Wed May 25 13:18:41 2016 -0700
Enable LTTng events for creating a gcdump
There were a handful of events that were not properly enabled on linux. This change adds enables the remaining events to allow heap dumps.
commit 04d3d6c3d9a1c87e88bc1db91f717481f21874bc
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 24 12:57:16 2016 -0700
Fix BulkTypeEvents
The buffer used for BulkTypeEvents was defined as a BYTE** instead of BYTE*. This lead to incorrectly written BulkTypeEvents.
commit 8ceab5828e8101b134beb0175b1842487607636c
Author: David Mason <davmason@microsoft.com>
Date: Wed May 18 11:21:12 2016 -0700
Add logic for finalizer thread to check to see if a heap dump is required.
commit cd64b4884d639ce90e4192975533f5e873bd1cb3
Author: Lee Culver <leculver@microsoft.com>
Date: Thu May 19 14:24:01 2016 -0700
Special case BulkType LTTng event
The BulkType LTTng event does not have a real element size. Instead each element is variable length. This change updates the FireBulkType method to allow us to pass the correct size to LTTng.
commit f8ab762106188bc124af802ec0490ef8375412b5
Merge: 77495aa f0d9ab4
Author: Lee Culver <leculver@microsoft.com>
Date: Thu May 19 13:49:43 2016 -0700
Merge branch 'gc-events' of github.com:leculver/coreclr into gc-events
commit f0d9ab4e52c69b45d2d169983c23ab5263edb5c0
Author: Lee Culver <leculver@microsoft.com>
Date: Thu May 19 12:51:01 2016 -0700
Enable BulkType LTTng events on linux
Emit calls to FireBulkType events on linux. This commit enables the code, but currently the wrong size is used in the etw subsystem (this function must be special cased).
commit 25c682ce49f51298f011046faa50443c569943b7
Author: Lee Culver <leculver@microsoft.com>
Date: Wed May 18 12:06:05 2016 -0700
Fix multiple LTTng issues
- Only emit LTTng events when LTTng is enabled. We now use the tracepoint_enabled macro to check if an event is enabled...when the version of lttng is installed that supports it.
- Unsplit LTTng events. Previously we split LTTng events when they exceeded the field limit of LTTng. Now we emit those events as a raw byte array so that it matches their windows ETW counterparts byte-for-byte.
- Emit any event with a struct or embedded array as a raw byte array too. The structure of memory that LTTng emits is incompatible with our ETW parsing. Changing events with struct/array fields greatly simplifies the parsing of events.
commit 77495aa1b3415dcee8d4b6e8eb1d0b5cb921f821
Merge: 754596d f77577c
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 18:24:55 2016 -0700
Merge branch 'master' of github.com:leculver/coreclr
commit 754596d9c51d07db9267148a20f81c786f719312
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 18:21:54 2016 -0700
Squashed commit of the following:
commit f77577c1d7c552de9e75f6fb98a656a1d09bf8b2
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 18:04:18 2016 -0700
Properly handle arrays in LTTng
Arrays were not being properly handled by the LTTng code generator.
commit 390e998719e050a4e61b29bef4c8f8ecbff3423f
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 11:21:07 2016 -0700
Manually write events with structs
Manually write events to LTTng which have structs embedded in them.
commit 54ae7c79f3c96987504cece302513ac9215afbfe
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 09:12:45 2016 -0700
Fix issue with struct sizes
Struct sizes were not properly calculated for manually saved events.
commit d4e59b1b8b18822e551e585ebe006e5b66066bf8
Author: Lee Culver <leculver@microsoft.com>
Date: Mon May 16 20:57:33 2016 -0700
Fix tests
Tests were not being generated properly, as they skipped a parameter.
This is now fixed.
commit 91d68c7ee36f28b1d9de8d0242edcd078416dc80
Author: Lee Culver <leculver@microsoft.com>
Date: Wed May 11 17:41:23 2016 -0700
Remove excess fields in LTTng stream
Extra fields were inserted into LTTng to calculate the size of struct
pointers. Now this calculation is done natively without needing to
insert the extra fields.
commit 3bf826f5e36637ff5188d0205510d7236458075a
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 10 10:00:39 2016 -0700
Re-enable dynamic linking to fix a load issue
Was getting a loader issue on startup, disabling static linking for now.
commit aacb45ff675d2299df938493416f875096ec446c
Author: Lee Culver <leculver@microsoft.com>
Date: Thu Apr 28 20:56:01 2016 -0700
Unsplit lttng events
LTTng has a limitation in that it cannot emit events with more than 9
parameters. Previously we would split these events into multiple
events. However this proves to be very difficult to consume with
TraceEvent. Instead we now pack the parameters into a byte array an
emit the byte array + length as a single event, avoiding the need to
recombine events later.
commit a9a630da28d42132c2e8929909e86545fbe630c9
Author: Lee Culver <leculver@microsoft.com>
Date: Wed Apr 20 13:31:33 2016 -0700
Only emit LTTng events when they are enabeld.
This changes adds a check for tracepoint_enabled (when that feature is available).
This change also statically compiles against the LTTng libraries (instead of dynamically) to avoid using entrypoints that may not be there if compiled against a different lttng that lacks the tracepoint_enabled entrypoint.
commit f77577c1d7c552de9e75f6fb98a656a1d09bf8b2
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 18:04:18 2016 -0700
Properly handle arrays in LTTng
Arrays were not being properly handled by the LTTng code generator.
commit 390e998719e050a4e61b29bef4c8f8ecbff3423f
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 11:21:07 2016 -0700
Manually write events with structs
Manually write events to LTTng which have structs embedded in them.
commit 54ae7c79f3c96987504cece302513ac9215afbfe
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 17 09:12:45 2016 -0700
Fix issue with struct sizes
Struct sizes were not properly calculated for manually saved events.
commit d4e59b1b8b18822e551e585ebe006e5b66066bf8
Author: Lee Culver <leculver@microsoft.com>
Date: Mon May 16 20:57:33 2016 -0700
Fix tests
Tests were not being generated properly, as they skipped a parameter.
This is now fixed.
commit 91d68c7ee36f28b1d9de8d0242edcd078416dc80
Author: Lee Culver <leculver@microsoft.com>
Date: Wed May 11 17:41:23 2016 -0700
Remove excess fields in LTTng stream
Extra fields were inserted into LTTng to calculate the size of struct
pointers. Now this calculation is done natively without needing to
insert the extra fields.
commit 3bf826f5e36637ff5188d0205510d7236458075a
Author: Lee Culver <leculver@microsoft.com>
Date: Tue May 10 10:00:39 2016 -0700
Re-enable dynamic linking to fix a load issue
Was getting a loader issue on startup, disabling static linking for now.
commit aacb45ff675d2299df938493416f875096ec446c
Author: Lee Culver <leculver@microsoft.com>
Date: Thu Apr 28 20:56:01 2016 -0700
Unsplit lttng events
LTTng has a limitation in that it cannot emit events with more than 9
parameters. Previously we would split these events into multiple
events. However this proves to be very difficult to consume with
TraceEvent. Instead we now pack the parameters into a byte array an
emit the byte array + length as a single event, avoiding the need to
recombine events later.
commit a9a630da28d42132c2e8929909e86545fbe630c9
Author: Lee Culver <leculver@microsoft.com>
Date: Wed Apr 20 13:31:33 2016 -0700
Only emit LTTng events when they are enabeld.
This changes adds a check for tracepoint_enabled (when that feature is available).
This change also statically compiles against the LTTng libraries (instead of dynamically) to avoid using entrypoints that may not be there if compiled against a different lttng that lacks the tracepoint_enabled entrypoint.
|
|
|
|
When unhandled exception happens in a finalizer thread and there are
no managed frames till the bottom of the stack,
the Thread::VirtualUnwindToFirstManagedCallFrame then fails fast.
The fix is to make the Thread::VirtualUnwindToFirstManagedCallFrame to
return even in case no managed frame is called, which is indicated by
its returning 0 as the resulting IP address. The DispatchManagedException
then checks that and rethrows the exception instead of trying to call
UnwindManagedExceptionPass1.
I have also added INSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP to the
FinalizerThread::FinalizerThreadStart so that the unhandled exception
doesn't escape the stack.
And I also needed to modify the UNINSTALL_UNHANDLED_MANAGED_EXCEPTION_TRAP
to detect case when the unhandled exception filter was already executed so
that it doesn't double-report the unhandled exception.
|
|
To enable a workaround to restore the previous behavior before finalizers stopped running on shutdown by default
|
|
Merge changes from TFS
|
|
|
|
API review: https://github.com/dotnet/corefx/issues/5205
This change implements the proposal in the API review above:
- Don't block threads for shutdown
- Don't run finalizers on shutdown (for both reachable and unreachable objects)
- Provide a public AssemblyLoadContext.Unloading event that can be handled to clean up global resources in an assembly
- As unloading an AssemblyLoadContext is not yet implemented, the event will for the time being be raised shortly prior to shutdown
[tfs-changeset: 1569451]
|
|
Reverting commit b18d2a7e30a0d7066d2c09711de07488a7dec475 (PR #2207) due to issue dotnet/corefx#4899, while investigating the issue, to unblock the CI.
|
|
The main thread does not time out waiting for the finalizer thread to complete during shutdown. Cases examined had the main thread blocked waiting for the finalizer thread to complete its work. The finalizer thread was blocked on either the "waiting for GC completion" event or one of the the GC spinlocks. Another thread was blocked for shutdown after entering the spinlock while allocating, or during GC. Allowing other threads to suspend for shutdown could cause the finalizer thread to block indefinitely, leading to a deadlock.
|
|
[tfs-changeset: 1407945]
|
