GraphScope analytics in Java：打破大规模图计算的跨语言障碍

本文中我们将分享大规模图计算上的跨语言探索，GraphScope 的高效图分析 Java 开发包 GRAPE-JDK。

1. 图分析上跨语言的需求与挑战

图分析是图计算任务中的重要场景，例如大家熟悉的单源最短路径就是一种常见的图分析算法。GraphScope 的图分析引擎源自于GRAPE[1]，其内置了常见的图分析算法如 SSSP，PageRank 等，用户可以直接进行调用。但在实际生产场景中，业务逻辑在通用算法上一般还有一些定制实现，而业务侧开发者往往在大数据生态中对 Java 更有经验。要求 Java 用户跨越 Java 与 C++ 之间的语言障碍来完成图计算业务逻辑的开发无疑增加了开发成本，提高了开发难度。如何平衡 Java 的灵活性和图计算 C++ 引擎的高效性？因此，允许用户使用 Java 进行自定义图算法的实现，并且高效地运行在 GraphScope 图分析引擎上，是一个十分现实的需求。

为了满足用户对于跨语言图分析的需求，我们需要在 C++ 实现的图分析引擎 GRAPE 基础上开发 Java SDK。在这样的场景下，使用 JVM 的标准的跨语言编程框架 Java Native Interface(JNI)[2] 是常见的方案。JNI 存在的原因是因为在 Java 中，我们无法像在 C++ 中那样以非常底层的方法访问系统的硬件资源，而为了能够使用这些硬件资源，我们就需要 Java 和 C++ 之间的桥接代码来使用 native library 中可执行代码。JNI 就是 JVM 上的 FFI (Foreign Function Interface) 标准框架。

JNI：让 Java 调用 native library

因此我们可以找到一种简单直观的解决方案：使用 Raw JNI 手写 Java 和 C++ 的桥接代码，将图计算引擎的 C++ 接口封装为 Java 接口，暴露给用户使用。 但是事实上这个 naive (baseline) 方案存在着各种问题，并不能够满足大规模图计算的实际需求，主要面临的挑战在以下三个方面：

挑战1: JNI编程的困难

直接基于 JNI 进行跨语言编程存在开发困难，调试困难和维护困难的问题。

• 开发困难：为了使得 Java 能够和 C++ 进行交互/通信，程序猿需要编写大量的机械单调，枯燥无味的 JNI 代码，如下图所示。JNI 代码中经常涉及到指针转换，更加增加了出错的风险。

JNIEXPORT void JNICALL Java_com_alibaba_graphscope_stdcxx_StdVector_1cxx_10x8cbe72bf_nativeClear(JNIEnv*, jclass, jlong ptr) {
    reinterpret_cast<std::vector<gs::VertexArrayDefault<double>>*>(ptr)->clear();
}

• 调试困难：编写出来的JNI代码需要通过c++/c编译器编译成动态库，以供JVM载入并调用其中定义的函数。JNI代码的编译调试也是较为痛苦的过程。

• 维护困难：维护JNI代码的成本也是较高昂的。由于JNI代码高度依赖于C++ native code，因此当图计算引擎的C++接口和实现发生变动时，程序猿必须手动更改JNI实现以进行适配。

挑战2: 跨语言访问的巨大开销

JNI 虽然提供了充足的 API 以供 Java 和 C++ 之间进行通信，但是由于其本身跨语言的特性，JNI 带来的开销也是巨大的。根据我们的调研，JNI 在实际大规模图计算场景中可能引入的开销主要来自于以下几个方面调用的开销。

• JNI 调用本身的开销[3]。在 JNI 函数中调用本身就有着较大开销，包括在 JNI 代码实现中访问 Java Object，都是导致非常耗时的操作。

• Java native 方法无法被 JVM inline。在 Java 中，对于代码的优化基本都来自于 JVM，对于高频调用的 Java 方法，JVM 可以通过 inline 来避免函数调用的开销。但是对于 JNI 实现的 native 方法，JVM 无法对其进行优化。而在图计算这样 data-in