Thursday, May 27, 2004

More On The New CLR Hosting Interface

In my previous "Five things I love about VS 2005 (from a performance perspective)" post, I briefly mentioned some of the new hosting interfaces in .NET 2.0. I've been digging into these interfaces a bit deeper for a piece I'm doing on Visual Studio 2005 that the Australian .NET MVPs are producing under the inspiration and guidance of Nick Randolph. Some of the more interesting interfaces that have been added include:

IHostMemoryManager


This interface, when implemented by the host, allows the host to control memory allocation requests. In .NET 1.1, memory requests are handled internally by the CLR, which calls directly into the Window's VirtualAlloc function when more heap space is required. The IGCHostControl interface that exists in .NET 1.x allowed the host to deny the CLR requests for memory allocation above a certain limit (see my book for a more detailed disucssion of this, including a sample implementation), but IGCHostControl has no ability to interact in a fine-grained manner with the CLR to govern memory allocation. The full interface definition for IHostMemoryManager is:

interface IHostMemoryManager : IUnknown
{
HRESULT CreateMalloc([in] BOOL fThreadSafe,
[out] IHostMalloc **ppMalloc);


HRESULT VirtualAlloc([in] void* pAddress,
[in] SIZE_T dwSize,
[in] DWORD flAllocationType,
[in] DWORD flProtect,
[in] EMemoryCriticalLevel eCriticalLevel,
[out] void** ppMem);


HRESULT VirtualFree([in] LPVOID lpAddress,
[in] SIZE_T dwSize,
[in] DWORD dwFreeType);


HRESULT VirtualQuery([in] void * lpAddress,
[out] void* lpBuffer,
[in] SIZE_T dwLength,
[out] SIZE_T * pResult);


HRESULT VirtualProtect([in] void * lpAddress,
[in] SIZE_T dwSize,
[in] DWORD flNewProtect,
[out] DWORD * pflOldProtect);


HRESULT GetMemoryLoad([out] DWORD* pMemoryLoad,
[out] SIZE_T *pAvailableBytes);


HRESULT RegisterMemoryNotificationCallback([in] ICLRMemoryNotificationCallback * pCallback);

}

For those familar with IDL, it is quite apparent the level of fine-grained control that it offers. I haven't build a sample host that implements this interface yet (stay tuned for this ...), but I'd imagine IHostControl.SetAppDomainManager would be the way to hook this interface up.

ICorSvcWorker



ICorSvcWorker, shown in full below, allows the CLR host to interact with the native image cache. As .NET matures and native images start to become significantly more optimized than their JIT equivalent, native images will become a bigger deal, and this interfaces allows the host much simpler control over native images compared to enumerating modules loaded in memory or using the poorly documented Zap APIs.

typedef enum

{
ScenarioDefault = 0x0, // No special scenario flags

ScenarioAll = 0x1, // All scenarios (used to indicate all configurations)

ScenarioDebug = 0x2, // Debuggable code

ScenarioDebugOptimize = 0x4, // Optimized code with debug infomration

ScenarioProfile = 0x8, // Used for profiling (enter/leave notifications)

ScenarioShared = 0x10, // Shared code

ScenarioTuningDataCollection = 0x20, // Used to gather IBC data

ScenarioLegacy = 0x40 // Follow hard dependencies only

} OptimizationScenario;



interface ICorSvcWorker : IUnknown

{
HRESULT OptimizeAssembly(
[in] BSTR pAssemblyName,
[in] BSTR pApplicationName,
[in] OptimizationScenario scenario,
[in] SAFEARRAY(BSTR) loadAlwaysList,
[in] SAFEARRAY(BSTR) loadSometimesList,
[in] SAFEARRAY(BSTR) loadNeverList,
//HostConfig hostConfig,
[out] BSTR *pNativeImageIdentity
);


HRESULT DeleteNativeImage(
[in] BSTR pAssemblyName,
[in] BSTR pNativeImage
);


HRESULT DisplayNativeImages(
[in] BSTR pAssemblyName
);


HRESULT GetCorSvcDependencies(
[in] BSTR pAssemblyName,
[out] ICorSvcDependencies **pCorSvcDependencies
);


HRESULT Stop(
);

}

0 Comments:

Post a Comment

<< Home