背景 随着业务的复杂性增长，现在很多程序同时包含 cpu 代码和 gpu 代码。 一个典型场景为：cpu 读取远程数据，转换成 gpu 算子处理格式，运行 gpu 算子，拿到 gpu 算子处理的结果之后再发送到下游。 现在的 gpu 的工具体系，例如 nsight全家桶，PyTorch Profil
现在的软件开发场景中，涉及多语言开发是很常见的，其中最常见的交叉就是java和c/c++的相互调用，这给java程序员、c/c++程序员都带来了问题排障的交叉痛苦。 对java程序员来说，引入动态库加速，一旦遇到内存泄漏，高cpu场景，java的一套工具链无法拿到native的数据。 对c/c++程
背景 用户 jvm 进程偶发 crash，报错信息如下 G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*) ()
根据堆栈来看，G1 gc 在 ygc过程中内存访问错误，这个是进程挂掉的
背景 heapdump 分析 是 java 堆内存泄漏常见的方法。以 mat 为例，这种分析方法有如下的限制。 有内存要求。mat 的内存一般为 heapdump 文件的 1.5 倍，低于这个比率有概率 mat 自身 OOME。 分析时间和对象数成正比。mat 为每个对象做索引计算支配树，对象越多分
背景 用户咨询了一个内存资源利用的场景。场景如下： 他们的 java服务主要是白天有访问，晚上量很少。 有一些零散的任务需要运行。 他们的想法是把这些零散的任务在晚上放在 java 服务的机器上运行，这样就可以在不买新的机器的情况下，处理的事情更多了。 他们在实施上遇到了问题：java 服务为什么不
背景 用户发现 java 进程内存在持续增长，通过 pmap查看到了大量接近 64m 的内存块，判断为 glibc 的问题导致了内存增长，修改MALLOC_ARENA_MAX 重启进程。运行一周后发现内存持续增长现象还在，尝试更换分配库依旧无效，最后通过抓取分配确认问题为特殊条件下代码的内存泄漏，修
背景 用户咨询了一个java中cpu缓存伪共享场景， 他通过padding多个long 字段隔离 2 个volatile字段，但是实测效果没有提升。 这是个比较有趣的场景，在 jdk8 有更稳定的方案去解决伪共享带来的性能问题。 下面我们展开介绍 伪共享问题是什么 用户padding方案为何失效 j