zefengsysu
zefengsysu
Android 6级以上 "dalvik.vm.heapsize" property值不大于（大多数都为小于）虚拟机堆内存大小。 这个是实际测试得到的结论吗？从源码看应该dalvik.vm.heapsize就是对应Heap的capacity_的吧
> > Android 6级以上 "dalvik.vm.heapsize" property值不大于（大多数都为小于）虚拟机堆内存大小。 这个是实际测试得到的结论吗？从源码看应该dalvik.vm.heapsize就是对应Heap的capacity_的吧 > > 实际测试得出的结论： 比如： Android 6.0 VIVO Y67A型号 vmHeapSize: 268435456, actual_space1: 134217728, actual_space2: 134217728 > > Android 6.0 SONY F3111型号 vmHeapSize: 268435456, actual_space1:...
> 因为 adnroid 12 以上在 fork 的子进程里面，调用 DumpHeap ，里面的 ScopedSuspendAll 会卡死，得做些处理 > > https://cs.android.com/android/platform/superproject/main/+/main:art/runtime/hprof/hprof.cc;drc=78f3c72e8948087352788997a70854dee613352c;l=1604 是用 koom 验证的吗？当前的实现上有在 fork 前 unlock art::Locks::mutator_lock_ 避免死锁的；之前本地测试没有复现卡死的情况
> > > 因为 adnroid 12 以上在 fork 的子进程里面，调用 DumpHeap ，里面的 ScopedSuspendAll 会卡死，得做些处理 > > > https://cs.android.com/android/platform/superproject/main/+/main:art/runtime/hprof/hprof.cc;drc=78f3c72e8948087352788997a70854dee613352c;l=1604 > > > > > > 是用 koom 验证的吗？当前的实现上有在 fork 前 unlock art::Locks::mutator_lock_...
> > > > > 因为 adnroid 12 以上在 fork 的子进程里面，调用 DumpHeap ，里面的 ScopedSuspendAll 会卡死，得做些处理 > > > > > https://cs.android.com/android/platform/superproject/main/+/main:art/runtime/hprof/hprof.cc;drc=78f3c72e8948087352788997a70854dee613352c;l=1604 > > > > > > > > >...
https://github.com/KwaiAppTeam/KOOM/releases/tag/v2.2.2 2.2.2 版本已经发布，fast dump 支持已经放开到 Android 34（Android 14）
和 #265 实际是同一个问题吧？KOOM 内部会通过 reanalysis 机制（镜像分析失败情况二次启动时会再进行一次镜像分析）来提升成功率。我们线上观察到确实有相当多的情况是通过 reanalysis 分析成功上报的，这里我考虑下怎么做优化，但整体策略上，还是需要类似 HeapAnalysisService 这样的非高优独立进程来进行分析（避免影响主进程）。
提供下复现 app 的完整日志我确认下
已知 fork dump 在子进程可能会有偶现的 crash；快手最新线上跑的版本已经去掉了子进程的 jni 调用，预期应该可以解决现在这个子进程 crash，内部验证稳定后会合回到 koom 上