引用:

原帖由 流浪的枪骑兵 于 2019-8-8 21:58 发表
posted by wap, platform: 小米
真要是这样，这工作量确实无法想象
光前端就很麻烦了，这中间代码得复杂成什么样
另外这种做法不知道会不会影响java的一些特殊特性，比如反射之类

华为毕竟不是慈善院，养那么多科学家和工程师不是吃白饭的，开发那么久肯定要有些成果。
但是也不是不能理解，毕竟llvm已经可以做到多语言融合了，看看方舟能够比之进步多少了。
另外把java的动态特性转为静态确实是这次的关键技术及亮点，就看开源后大佬们的分析了。
再另外，也别把工作量想得那么大，华为本身只是对多种编程语言（我认为主要是java/c/c++）的分析和融合，但是华为本身无需对多cpu指令集（涉及实际编译出来的机器码）进行综合，它只需对自家的麒麟芯片负责就好了，它开源出来，其他体系的需要的话自然会去扩展。

posted by wap, platform: Android
昨天看完也没看懂多少东西

原博总结

posted by wap, platform: Samsung

引用:

原帖由 @masterfish  于 2019-8-9 06:49 发表
1、动态语义分析可以说是这次最有看头的地方，等开源了看大佬分析了，毕竟确实做出来了；
2、引用计数我认为远比java的暂停回收式gc好用多了，对内存的利用效率高多了。对于鸿蒙系统（方舟肯定是为鸿蒙服务的）这样的实时系统来说，几乎是唯一适合的gc模型。唯一的问题是循环引用的问题，但这其实是少数情况，可以单独处理。python是采用这样的，rust也是这种。
3、方舟我认为最牛逼的还是对多语言的融合，这个我觉得不会是完全创新，应该有llvm的底子，但是能够融合java、c/c++等，抛开傻逼透顶的jni，可以说功德无量了，同样，等开源了看大佬的分析。

看不懂，引用计数是标记垃圾的方法，和暂停回收有啥关系？

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2019-8-9 11:46 发表
看不懂，引用计数是标记垃圾的方法，和暂停回收有啥关系？

引用计数和标记是两种不同的垃圾回收机制。

引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就计数器继续+1，如果这些指向内存的变量指向其他位置，或者被删除了，那么就计数器-1，计数器变为0，就表示没有任何变量指向这块内存，那么就可以删除这块内存了。这整个过程不需要停下任何其他程序，资源损耗非常小。
引用计数的问题，是如果有两个指针互相循环引用，那末就会出现永远不会减到0的情况，造成内存泄露。
内存标记是java采用的垃圾回收机制，就是后台独立运行一个监控程序，监控所有的申请的内存是否被变量引用，一旦没有被引用，就证明这块内存可以回收，但是为了回收内存，监控程序会暂停所有的程序，然后将内存进行回收顺便处理碎片，所以会有卡顿，但不会有循环引用无法回收的问题。
现在python这类的语言，主要采用的是二者的综合，99%的内存是采用引用计数进行回收，剩下极少数循环引用的设置监控程序来处理。

posted by wap, platform: Samsung

引用:

原帖由 @masterfish  于 2019-8-9 12:37 发表
引用计数和标记是两种不同的垃圾回收机制。

引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就计数器继续+1，如果这些指向内存的变量指向其他位置，或者被删除了，那么就计数器1，计数器变为0，就表示没有任何变量指向这块内存，那么就可以删除这块内存了。这整个过程不需要停下任何其他程序，资源损耗非常小。
引用计数的问题，是如果有两个指针互相循环引用，那末就会出现永远不会减到0的情况，造成内存泄露。
内存标记是java采用的垃圾回收机制，就是后台独立运行一个监控程序，监控所有的申请的内存是否被变量引用，一旦没有被引用，就证明这块内存可以回收，但是为了回收内存，监控程序会暂停所有的程序，然后将内存进行回收顺便处理碎片，所以会有卡顿，但不会有循环引用无法回收的问题。
现在python这类的语言，主要采用的是二者的综合，99%的内存是采用引用计数进行回收，剩下极少数循环引用的设置监控程序来处理。

你不要瞎说好么……
整天复制别人的装懂也是够了……

本帖最后由 yfl2 于 2019-8-9 13:11 通过手机版编辑

虚拟机的好处是抽象硬件。
去掉虚拟机话， 那么app适配放到开发端，那兼容问题是不是就会放大？

IOS运行速度快，是因为只用适配自己的系统就好了。那在开发编译时期就已经适配了，当然运行速度会好。

[ 本帖最后由 wingfay 于 2019-8-9 13:33 编辑 ]

引用:

原帖由 masterfish 于 2019-8-9 12:37 发表
posted by wap, platform: Android
引用计数和标记是两种不同的垃圾回收机制。

引用计数是如果一个变量一个分配的内存空间，会给一个计数器＋1，当另一个变量也指向这块内存，就计数器继续+1，如果这些指向内存的 ...

???
引用计数法和可达性分析都只是判断对象是否可以回收的办法, 只能算垃圾回收机制中的一小部分东西


这篇文章讲得很含糊,具体细节还是只能等开发者大会和日后的开源了
个人猜测,看起来像是把java代码翻译成llvm,然后gc的话用类似苹果那套arc机制?
不过这块实在是不懂,不清楚华为要怎么搞才能解决其中的那些技术难点

[ 本帖最后由 cj2047 于 2019-8-9 13:41 编辑 ]

posted by wap, platform: Samsung

引用:

原帖由 @cj2047  于 2019-8-9 13:33 发表
???
引用计数法和可达性分析都只是判断对象是否可以回收的办法, 只能算垃圾回收机制中的一部分内容

他错误百出，啥都不懂，只是装逼罢了

引用:

原帖由 yfl2 于 2019-8-9 13:10 发表
posted by wap, platform: Samsung
你不要瞎说好么……
整天复制别人的装懂也是够了……

本帖最后由 yfl2 于 2019-8-9 13:11 通过手机版编辑  

你有什么料露出来看看？

posted by wap, platform: Samsung

引用:

原帖由 @masterfish  于 2019-8-9 13:38 发表
你有什么料露出来看看？

没，只是看到你扯的实在太傻太low

posted by wap, platform: Samsung
我跟你讲，大陆人写的关于程序方面的书，内容，99%是翻译发行版里的说明

posted by wap, platform: Android
我也转发一个酷安上的评论，这个比较好懂

在微博上看到钟文泽转了这篇长文，居然是关于造势很久的方舟，看完之后就在想酷安估计也该有人在讨论了。当然，在未开源之前细节未可知，我只是想说一些从文字中看到的东西。
emmm，还是说一下，本人是不知名985计科在读，专业课程和知识体系相关，所以不是小白评专业，当然说这个也不意味着要开始科普，只是说明一下我的看法是基于我的知识储备从文中总结，不是章口就莱…
直接先划重点吧…
第一，绕过虚拟机带来的资源消耗，将代码直接转为机器码。一看到这个我就想，这不是把编译汇编一起干了，技术细节未知，但文章告诉我们，方舟在编译和运行阶段解决了很大一部分动态语义的编译，也就是完成了带来不确定性的文法的编译工作（非常难），注意，这一部分，是华为设计拥有的一项核心专利。
第二，绕过JNI带来的开销的同时解决不同开发语言的互通问题。使用统一的IR来表示不同语言，编译成华为自己开发的一套机器码，注意，这一部分，依然是核心专利。
第三，代码优化部分，更倾向于让开发者使用方舟提供的预置工具和调度建议去调整代码，强调不改变开发者编码习惯，效果如何，开源后用了才知道，至于云端优化，先往后捎捎。
第四，引用计数法和消除环算法来避免安卓内存回收机制带来的很多卡顿，未强调专利，这部分算法应该是可以给大家观摩学习甚至优化的。
这四点其实原博下给了总结，所以我只是添了些细节，我真正想说的是，编译这项工作是十分繁杂且逻辑极其严谨的，看看文中对项目工程师的描述可见一斑，描述的绝对不会夸张。它的地位虽然不可动摇，但从事计算机相关工作的少有深入编译原理的，就算是学院派出身也少有投入编译怀抱的，它不像热门技术那样风光无限，受人欢宠，所以华为肯做这个项目且开源使用，无论其出发点是什么，对这项技术的发展和这方面人才的需求培养是有益的。另一方面，关键技术上华为拥有着核心专利，这个确实顶，佩服。至于效果好不好，谁用谁知道。[机智]

其实没多少意料之外的东西，多语言编译成IR再通过不同后端对应不同平台，AOT编译同时支持部分动态语义，独立的垃圾回收器这些，其实都不是新鲜的东西。就好像几年前u3d的那个IL2CPP就是个类似的东西。

引用:

原帖由 hourousha 于 2019-8-9 15:42 发表
其实没多少意料之外的东西，多语言编译成IR再通过不同后端对应不同平台，AOT编译同时支持部分动态语义，独立的垃圾回收器这些，其实都不是新鲜的东西。就好像几年前u3d的那个IL2CPP就是个类似的东西。

还没看到方舟的源码。看介绍感觉就是这个

从软件行业从业人员的角度来说这个事。这个事在软件行业是编译原理方向，这个方向很成熟，但也很少有人懂的很深。因为一般没需求。

所以，这个方向如果有新东西出来，一般都是很nb的。

稍微往细里说一点，听起来源代码编成IR再编成机器码，逻辑挺清楚的。但实际上不是那么简单。因为java的动态特性，代码在运行期是可以修改自身的。这是java的nb之处。我对编译原理的理解也有限，不知道IR能不能做到这一点。

说实话，我觉得华为支持的“java编译成机器码”，这里的java不是完整的java，而是java语言的子集。假如真的是这样，即使只是java子集，也是很nb的想法。不过这样就有可能会出现这几种情况：1. 部分应用无法编译；2. 部分应用编译后不能正常运行； 3. 部分应用需要特定修改以绕开编译器缺陷。而这几种情况，会严重影响编译器的推广。

而且，我曾经看过“很吓人的GPU Turbo"的详细分析，https://zhuanlan.zhihu.com/p/43887961 ，华为在技术营销方面是有前科的，也就是过份夸大自己的技术优势，而选择性忽略技术的缺陷。

所以，我觉得，只能等着时间和源码来证明华为到底做了些什么吧。