每个CLR或每个进程有一个托管堆吗? [英] Is there one managed heap per CLR or per process?

查看:84
本文介绍了每个CLR或每个进程有一个托管堆吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我所知,在 .NET 4.0 之前很简单:一个进程只能托管一个 CLR

As far as I know, before .NET 4.0 things were simple: one process could only host one CLR.

但是从版本4.0开始,一个进程可以承载多个CLR。

But from version 4.0 a process can host more than one CLR.

在这种情况下,我猜有每个CLR都有一个堆,因为每个CLR都有自己的状态和自己的GC,以及自己的内存管理方式和收集周期,因此共享内存似乎是不可能的。

In this case, I guess there is one heap per CLR, because each CLR has its own state and its own GC with its own way of managing memory and its own collection cycles, so sharing memory just seems impossible.

1)您能否确定确实是这种情况或更微妙?

1) Could you confirm that this is conclusively the case or is it more subtle?

2)是在同一进程中托管的两个CLR是否被严格隔离或他们可以分享任何东西吗?
(特别是如果它们具有相同的版本,他们是否可以彼此了解)

2) Are two CLR's hosted in the same process strictly isolated or can they share anything? (particularly if they have the same version, could they be aware of each other)

我想答案是肯定的,是的(隔离),但是我'想确定。

I guess the answers are yes and yes (isolated), but I'd like to be sure.

感谢您的见解。

推荐答案

我们需要做的第一件事-是整理或映射一般情况:

The first thing we need - is to sort out or map what is happening in a general:

您执行exe文件->该文件要求输入.NET CLR-> CLR流程-托管您的执行。

you execute your exe file -> the file asks for a .NET CLR -> the CLR Process - hosts your execution.

为了简单起见,我将其简化一下:

So to be brief, I'll draw it shorter:

这是4.0之前的版本:

执行File1.exe-> CLR进程->主机(.net File1.exe)=>在这里,我假设file1.exe是.net1

执行File2.exe-> CLR Process2->主机(.net File2.exe)=>这里我假设file2.exe是.net2

执行File3.exe-> CLR Process3->主机(.net File3.exe)=>这里我假设file3.exe是.net3

This is what was happening in previous to 4.0:
Execute File1.exe -> CLR Process -> hosts (.net File1.exe) => here I assume file1.exe is .net1
Execute File2.exe -> CLR Process2 -> hosts (.net File2.exe) => here I assume file2.exe is .net2
Execute File3.exe -> CLR Process3 -> hosts (.net File3.exe) =>here I assume file3.exe is .net3

在上述示例中,我假设.net 3安装在机器,这就是.net3 CLR是进程的原因-的确,它被加载了3次!但是,由于DLL是相同的,因此DLL窗口可以共享它,就好像它仅被加载一次一样。但是在内存中-使用了3个不同的指令指针,每个进程都有自己独立的堆。

In the above examples I assume .net 3 is installed on the machine and that is why .net3 CLR is the process - and true - it was loaded 3 times! however since the DLL is the same DLL windows may share it making it as if it was loaded just once. but in memory - 3 different instruction pointers are used on it and each process has its own separated heap.

而这是4.0和4.5发生的情况:

执行File4.exe-> CLR Process45->主机(.net File4.exe)=>这里我假设file4.exe是.net4

执行File45 .exe-> CLR Process45->也托管(.net File45)=>这里我假设file45.exe是.net4.5

And this is what happening with 4.0 and 4.5:
Execute File4.exe -> CLR Process45 -> hosts (.net File4.exe) =>here I assume file4.exe is .net4
Execute File45.exe -> CLR Process45 -> also hosts (.net File45) =>here I assume file45.exe is .net4.5

在上述示例中,我假定计算机上安装了.net 45,因此.net CLR4是仅被加载一次的进程(而不是两次加载!如先前示例逻辑所预期的那样)

In the above examples I assume .net 45 is installed on the machine, so .net CLR4 is the process which was loaded just once (and not twice! as would expected from previous examples logic)

您可以在答案的结尾处提供的链接中阅读更多信息,以了解哪些版本可以一起坐着-并非所有版本都可以与所有版本并列。

You can read more in the links I provide in the end of my answer to learn what versions can "sit" together - not all version can sit side by side with all versions.

我的答案的第二部分与您确切询问的内容更相关:

任何进程都具有单个堆-不能更改,因为哈尔dware可以工作。
(无论从什么意义上讲CLR只是另一个过程可以做什么)

但是为了能够为托管的每个exe提供堆,他们发明了一个名为 blob-heap,放置在CLR进程的堆中。

CLR中的每个托管应用程序都有其自己的GC,它们是独立的,彼此之间并不了解。

据我了解,.NET4仅使用一个CLR,它可以管理许多主机项或应用程序。这意味着许多应用程序之间的潜力会彼此放慢,但即使使用 Multi-CLR方法也是如此。.更严重的问题是,如果CLR本身停止运行...所有托管的应用程序将停止以它。我不知道如何或是否可以在体系结构中解决这种潜在问题。

The second part of my answer is of more relevancy to what you ask in exact:
Any Process has a single heap - that can not be changed as it is how the hardware works.
(regardless of what CLR which is just another process in that sense can do)
But in order to be able to provide a heap per exe being hosted they invented a concept named "blob-heap" Which is placed in the heap of the CLR process. so many blob heaps can be managed at once.
Each hosted app in the CLR has its own GC and they are Isolated and do not aware of each other.
To my understanding just a single CLR is being used in .NET4 which is able to manage many host items or apps. This implies that many apps will slow down each other in potential but that was true even if "Multi-CLR" approach were used instead.. the more acute problem is that if CLR itself stopped running... all hosted apps would stop running with it. I have no idea how or if that kind of potential problem is solved in the architecture.

我从所有这些来源中读来汇编此答案:

公共语言运行时(CLR)

ECMA C#和通用语言基础结构标准

公共语言基础设施( CLI)将I分区为VI(第六版)

并行处理

加载多个CLR运行时(InProc SxS)–示例代码

I read from all those sources to assemble this answer:
Common Language Runtime (CLR)
ECMA C# and Common Language Infrastructure Standards
Common Language Infrastructure (CLI) Partitions I to VI (6th edition)
In-Process Side-by-Side
Loading multiple CLR Runtimes (InProc SxS) – Sample Code

这篇关于每个CLR或每个进程有一个托管堆吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆