我正在整理一个 NLP 实验，其中概念是系统中的代理，旨在产生由新概念组成的涌现属性（这里是那些不知道涌现是什么的人的链接）。Smalltalk（特别是 Pharo 方言）似乎是此类应用程序的理想选择，因为我可以轻松创建完全封装的概念对象，这些对象作为独立代理相互关联，而且 SmallTalk 允许我检查系统运行时的状态。
我担心的是，如果存在太多对象并且所有对象都互相发送消息，系统是否会开始阻塞。从理论上讲，我的实现可能会产生数百万个概念对象，如果系统无法处理那么大的事情，我不想花时间在 SmallTalk 中解决这个问题。
SmallTalk 图像中活动对象的数量是否存在限制因素（软件因素，而不是硬件）？
系统能否处理具有数百万聊天对象的系统中存在的消息流量？
预先感谢您的帮助！
关于 1：对象的数量受到 VM 可用的虚拟地址空间的限制——在标准构建中，它只有几百 MB 大。我当前的 Squeak 图像包含超过 350 万个Object处于空闲状态的实例 - 这应该让您对什么是可能的有一个印象。
关于 2：我的 Squeak 图像在我不是那么最新的 Intel Core i7 2620M（当然只使用一个内核）上每秒发送大约 2600 万条消息。
但是，我怀疑您是否会对当前方法的结果感到满意。你谈到了检查系统的状态——这在 Squeak/Pharo 中真的很棒——但你不能（手动）检查数百万个对象的状态。但话又说回来，我不知道你到底在做什么；）
我相信 Pharo 中对象指针的内部工作大小仍然是 32 位。有 64b 版本的讨论，但在 64b 机器上运行 32b 虚拟机是一回事，而拥有真正的 64b 完整的虚拟机则是另一回事。
所以那里有一个隐含的限制，但仍有“数百万”个对象的空间。开始达到“100 的数百万”，你很可能会遇到一些限制。
最终拥有数百万个对象并不是一个真正的问题，现在它转移到了控制线程，而在这种情况下，Pharo 并没有做太多的线程。因此，真正的问题在于您将拥有多少实际不同的上下文，而不一定是对象本身。
拥有数百万个对象相互通信的链并不是什么大问题，您只需遇到底层 VM 中存在的任何消息传递开销来限制原始性能。Pharo 非常快，但它不是 Java 快。对你来说是否足够快由你来回答。
我也无法谈论 Pharo GC 处理数百万个活动对象的能力，我只能建议它是 2013 年，Squeak（Pharo 所基于的）自 90 年代中期就已经存在，GC 技术现在已经非常成熟，而且我不怀疑 Pharo 的 GC 在这方面非常糟糕。
我会简单地做一些微基准测试并自己尝试。