Smalltalk图像中对象的数量是否有上限？

我正在做一个NLP实验，在这个实验中，概念是一个系统中的代理，该系统旨在产生由新概念组成的涌现属性（对于那些不知道涌现是什么的人）。Smalltalk（特别是Pharo方言）似乎是此类应用程序的理想选择，因为我可以轻松创建作为独立代理相互关联的完全封装的概念对象，而且Smalltalk允许我在系统运行时检查系统的状态

我关心的是，如果存在太多对象，并且所有对象都在相互发送消息，系统是否会开始阻塞。理论上，我的实现可能会产生数百万个概念对象，如果系统不能处理这么大的事情，我不想在SmallTalk中花时间解决这个问题

是否存在限制因素（软件因素，而非硬件） 关于SmallTalk图像中活动对象的数量

系统能否处理将出现的消息流量 在一个拥有数百万聊天对象的系统中

---

提前感谢您的帮助

关于1：对象的数量受到虚拟机可用的虚拟地址空间的限制，在标准构建中，虚拟机只有几百MB大。我当前的Squeak图像包含350多万个处于空闲状态的

对象

实例，这应该会给你一个可能的印象

关于2:My Squeak image在并非最新的Intel Core i7 2620M上每秒发送约2600万条消息（当然，只使用一个Core）

---

然而，我怀疑你是否会对你目前做法的结果感到满意。您谈到了检查系统的状态——这在Squeak/Pharo中真的非常棒——但是您不能（手动）检查数百万对象的状态。但话说回来，我不知道你到底在干什么；）

我相信Pharo中对象指针的内部工作大小仍然是32位。人们一直在谈论64b版本，但在64b机器上运行32b虚拟机是一回事，而实际的64b直通虚拟机又是另一回事

所以这里有一个隐含的限制，但仍然有容纳“数百万”对象的空间。开始接触“一亿”，你很可能会遇到一些限制

最终拥有数百万个对象并不是一个真正的问题，现在它转移到控制线程，而Pharo在这种情况下不做太多线程处理。因此，它真正涉及到如何计算您将拥有多少实际的不同上下文，而不一定是对象本身

拥有一个由数百万个对象组成的通信链并不是什么大问题，您只需在底层VM中运行任何消息传递开销，以限制原始性能。Pharo相当快，但它不是Java快。对你来说是否足够快由你来回答

我也不能说Pharo GC处理数百万个活动对象的能力有多好，我只能说2013年，Squeak（Pharo的基础）从90年代中期就已经存在，GC技术现在已经相当成熟，我不怀疑Pharo的GC在这方面非常糟糕

---

我只需要做一些微基准测试，然后自己试试。

w00t-t/y，快速回复！正如几年后的更新一样，Squeak（和Pharo，以及Cuis）以64位指针的形式提供。正如VisualWorks、GemTalk和其他可能的实现一样。因此，耗尽对象标识的可能性很低。而且，以目前的RAM价格，拥有足够的存储空间来解决问题的可能性是最小的。t/y以及如此快速地跳到这一步！仅供参考-我不想一次检查所有的对象-但我确实需要检查概念结构（概念可以自我复制，产生更复杂的形式，它们仍然连接在一起），以查看正在制作什么，如何制作，以及是什么导致制作。只要我能做到，我就是gtg。