原文

Mathis

马里奥说,Funkwerk一直有一些内存问题,并给其交MathisBeer了解细节.
Mathis说,从D2.096或2.100左右开始,Funkwerk一直在使用更多的内存.可惜,很难知道这是否是一个真正的问题.
他说,当你看到10GB进程时,很难判断这是因为大量的数据,或是时间问题,或是否有降级.
他提到在论坛上发布的一个运行一百个线程来创建哈希映射,然后显式删除它们或设置它们为null的测试用例.
它最终剩下200kb的GC内存和几百兆字节的残留,这并不令人满意.进程使用的内存只是不断增长.
他说,有时它会稳定,但只是因为GC太多,以至于CPU无法处理足够数据来进一步增长.在生产中必须定期重启才能控制内存使用.
他在std.json文档中添加了一个警告,有大量数据时,不要用它.如果每个JSON节点都有一个哈希映射,那会打击你.
在网络上取数百兆字节数据并处理,在线程系统中GC很难处理.使用移动收集器,可检查问题并增加内存,然后再次下降.
但这在D中从根本上是不可行的.除了警告,他无能为力.
Walter指出,D的GC在收集内存时,不会返回内存给操作系统.它只是在增加.Mathis说他们一直在手动调用最小化,但是如果池中有一两个错误的引用,则不行.
Walter同意移动收集器,但没有,因为无法可靠地找到所有引用或证明它们都是有效的引用.所以只能这样.
Mathis说,他一直在怀疑,在大型池中有些栈上挂起的无用引用.但不能证明.
它们存在,是因为它们在恰好调用函数时不会覆盖的某个8字节区域.他想知道是否有可在GC中断栈的给定点,获得栈的指针数据.
就像在给定点有每个寄存器做什么,每个字节做什么的细节.
Walter说,他们可以,对接近调用栈根的函数,一旦使用完内存,就可把引用设置为null.可帮助解决该问题,这是他唯一能想到的;
完成操作后,只需把引用设置为null,这样就不会在栈上徘徊.Mathis说,问题是关联数组没有这样做.他们可把引用设置为null,但运行时函数不会自行清理,从而悬挂引用.
Mathis说他们没有活变量.他们的理论是,进入GC时,会跳过在栈指针上方的东西.进入函数前,几乎可调用500字节或2kb的alloca来摆脱它.
Walter建议使用assert(0)来取栈跟踪,这样就可查看哪些函数仍在栈上,然后转到这些函数查找悬挂引用.

Igor

第一个问题与Funkwerk的问题有关.他们使用std.json来解析数百兆字节的JSON.在多线程应用中,它非常慢.
调查发现是由GC中的全局锁引起的.而文档中未提及这一点.这是个重要的性能属性,应明确记录.
方法切换std.json为另一个库,一切正常.

`C++`串

伊戈尔说,他们正在与许多C++的人工智能/机器学习库对接.可惜,D与C++的std::string的绑定仅限于旧的C++API.在新API中,std::string的内存布局有个内部指针.
D的运行时模型中不支持它,因此D无法绑定到新串.解决方法是用旧的C++API编译C++代码.这有效,但这很烦人,因为你必须全部编译所有源代码.

因此,如果有人提供了针对较新的C++API编译的预编译库,则不能直接使用它.如果可以,解决该问题会很好.
MathiasLang说C++串是引入复制构造器和弃用postblit的全部原因.

`C++`互操作文档

接着,Igor说D的C++接口文档不完整.如,他们不知道可在D中抓C++异常.
Walter说未文档化,是因为不适合某些C++编译器.与微软C编译器一样.无法抓他们的异常.

伊戈尔说没关系,因为他们使用的是Linux.沃尔特说他明白了.然后解释说,它不适合MS异常处理机制,因为他无法确定它工作原理.
他说,32位异常的文档一目了然,但他可让它工作.64位MS实现的文档非常令人困惑,他放弃了它.在POSIX系统上,它是相当标准化的,所以很容易弄清楚.
因此,只要你不使用MSC++,就可以.不过,应该更新文档以说明它适合Linux和POSIX系统.

MathiasLang问他们在Linux上使用哪个编译器.伊戈尔说.Mathias说,GDC和LDC会通过隐藏指针传递大量对象,因此会避免在互操作中遇见C++错误.
他建议继续使用LDC.

伊戈尔同意了.他说真应该更新有关此的文档,即使它不适合MS.这一点很重要,你可在Linux上轻松使用C++互操作,是个非常好的属性.
如果有可能在窗口上修复C++异常处理,也许是通过付钱给某人或通过GSOC或SAOC项目,那就太好了.对接C++.

vibe.d

伊戈尔说,使用vibe.d时,编译时会从vibe.d内部收到两个屏幕的弃用警告.他看到了一个Bugzilla问题和一个关于它的论坛帖子,这很好,但唯一的方法是全局禁止弃用警告.
但表明无法看到可修复代码的弃用警告.这有点烦人.

沃尔特说,晚些时候会谈论弃用.MathiasLang指出,已在master中修复了Igor提到的指定vibe.d弃用,只是还没有新版本,Igor说这很漂亮.

MathisBeer表示,Funkwerk做了一些作弊的事情,并且有可能破坏:他们拆分弃用的库,并用弃用链接他们自己的代码.有模板时,这会破坏.

卡斯滕(Carsten)

遇见的唯一问题是移植加密库到Android和iOS时遇见了一些挑战,但现在已解决了该问题.他说,主要是因为他们不了解Android工作原理.
他们已构建了自己的系统,使用BDD(行为驱动开发)自动生成D代码,然后在那里编写单元测试.带单元测试的BDD工作流有效.

他们使用自己的受到BSON的启发叫HIBON(有不变二进制对象符号),而不是JSON的数据格式.使用HIBON,生成数据结构时,可保证加密类是相同的.
因此,字节组织方式与工作位置无关.

想发布HIBON,因为原则上可用来序化.他们已内置了它,且易于使用.多亏了内省,可插件一个HIBON记录,然后序化或构造类或构.
它使得更易使用流程.数据库中的所有内容都存储在HIBON中.他们甚至有个叫HIRPC的签名的远程过程调用.
也即,不是请求许可,而是对RPC签名,以便在收到它时知道你是否有权执行某些操作.
有时会遇见弃用问题,但他们只是解决了这些问题并继续前进.除此外,他们之前在单元测试中运行多线程时,确实遇见了问题,这可能不是个好主意.
有时,在多线程时测试会失败,且会泄漏到所有其他测试.但是自从转向使用BDD后,就没有该问题了.

atila说,并行运行单元测试可能很好,因为可发现是否做错了什么.他问如何并行运行它们.卡斯滕说,他们没有并行测试.
但是,如,如果有线程测试,比如并发测试或其他什么,且失败了,则实际似乎不可预测它.阿蒂拉说这是因为异常被吃了.Carsten说,他们还看过atila的单元线程库这里,并想在以后合并它.

纪尧姆

接着,说他分发共享库给很多客户.他想强调,自包含的共享库是D的有效用法.因为他不控制主机,所以这时,共享标准库和共享DRuntime可能是一个问题.
最后,他说想在所有D编译器中看到Objective-C支持.

沃尔特

Walter说,应该不弃用不会伤害语言的东西.不会仅因为它们是老式的,或因为有更好方法等而删除它们.该想法是向后兼容,因为人们讨厌获得试使用的旧D包,但屏幕充满了弃用消息.
所以必须停止这样做.
提出并部分实现的替代方法是用可为过时的东西打印警告的-wo开关.想法是,与弃用警告一样,这不是编译器默认的;
必须主动取消息.最好,人们不会因为改进语言而烦恼.仍编译过时功能,只有在请求时才会收到警告.
而不会受弃用消息困扰.只会弃用并删除真正有破坏性和有问题的内容.

还有个问题是,某些弃用针对导致代码不安全的功能.这里问题是编译器无法证明代码是安全的.不表明代码不安全或破坏.
因此,他计划修改它,以便只有在修复了有关传统行为的所有警告后,才能在@safe代码中获得编译器保证.这不会破坏现有的,有效的,经过调试的代码,但是如果想让编译器保证安全,必须打开-wo并修复它给你的警告.

同样,想法是让人们可继续使用较旧的,经过调试的工作库,而不会从编译器那里得到大量的抱怨.像vibe.d此项目不会在每次有新版本编译器时自动中断,或至少不会故意因充满弃用消息而中断.

使用vibe.d的人不必受编译vibe.d带来的弃用消息所困扰,是完全合理的,因为破坏了现有项目,给它留下了非常糟糕的印象和愤怒.

他已发送了一些来恢复一些不需要弃用的,但破坏人们代码的PR.他们没有伤害.还与丹尼斯说,要求他优先在类上恢复别名本(alias this)的弃用.
不必弃用它.在语言中使用它很烦人,但是人们不能简单替换它.因此,前进道路不是改进或修复它,这是无法做到的,也是首先弃用它的原因.而是鼓励人们不要使用它.
保留它,以便可工作,代码编译,但可让-wo开关警告它.

Carsten问是否可按模块级或包级设置标志以启用或禁止警告.开始了关于允许-wo=foo和/或-d=foo的相当长的讨论,及foo应该是模块还是包,还是文件系统上的目录.

Walter对-wo的意图是,允许在没有警告时编译旧代码,而无需用户更改.如果要求用户更改构建系统来禁止警告,则需要用户更改.

应该有比-wo更好的回应.它必须是w0=,然后是包名列表等.改良坏主意,可能是个好主意.看看保时捷911就知道了.早期原型是辆可怕的汽车.它只是丑陋.然后他们只是改变了pit,就变成了一辆很好的车.
最后,Walter说可增强-wo,给它适用的模块列表.这很合理.