问题描述
我正在Windows 7下在具有16gb RAM的64位处理器上运行64位版本的GhostScript（9.50）。
当我尝试分配一个太多的数组，总计超过2 GB的RAM时，GhostScript返回一条随机的错误消息（它将告诉我在array命令中有类型错误）。
要清楚，我正在观察Windows Task Monitor中内存使用量的增长情况，而不是在GhostScript中
我想知道为什么会这样。
更重要的是，我想知道是否可以覆盖此行为。
/TL 25000 def
/TL- TL 1 sub def
/G TL array def
0 1 TL- { dup == flush G exch TL array put }for
错误看起来像这样：这是我收到的消息的最后一位
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
Unrecoverable error: typecheck in array
Operand stack: --nostringval-- ---
Begin offending input ---
/TL 25000 def /TL- TL 1 sub def /G TL array def 0 1 TL- { dup == flush G exch TL array put }for --- End offending input --- file offset = 0 gsapi_run_string_continue returns -20
解决方法
几乎可以肯定的是，RAM的数量不是限制因素，但是如果您发布实际的错误消息，它将有所帮助。对于您来说，这可能是“随机的”，但对于使用PostScript进行编程的人来说，这很有意义。
您很有可能超出了其他一些内部限制，例如操作数堆栈大小，但没有看到PostScript程序或错误消息，我只能说更多。我可以说（64位）Ghostscript将愉快地处理超过2GB的RAM，上周我运行的文件中的Ghostscript使用的是8.1GB。
请注意，PostScript本身基本上是32位语言。尽管Ghostscript扩展了PostScript语言参考手册中记录的许多体系结构限制（例如数组和字符串中的64K元素）超出32位限制，但实际上并没有规定。
关于您是否可以更改行为，这完全取决于问题所在，而我无法从这里说出什么来。
编辑
这是Ghostscript运行测试文件完成的屏幕快照，以及“任务管理器”屏幕显示进程正在使用的内存量。之后未显示我从PostScript环境运行的vmstatus。这表明Ghostscript认为它使用的是10,010,729,850字节，最大为10,012,037,312。我的计算器说，9,562.8MB的空间为10,027,322,572.4字节，非常匹配。
要回答评论中的要点，这是（您可能知道）在具有大量内存的64位Windows 10安装上。
几乎可以肯定，差异是自9.52发布以来已修复的问题。在（对我来说）5360次迭代之后，9.52 64位二进制文件的确退出并带有VMerror。显然，尝试使用大量的 PostScript 内存（而不是画布内存）并不常见，这不仅是因为许多PostScript解释器根本不允许这样做，所以这是不可行的。多运动。
如果您要检查提交并尝试找出导致更改的原因，则Ghostscript Git存储库为here。您只需要回到今年3月，在3月19日之前的任何时间都应该在9.52。
除了简单的好奇心外，是否有理由尝试耗尽PostScript中的内存负载？
