OpenJDK实现System.arraycopy
在关于JVM基于char []实现字符串创建的方式的问题之后，我提到当char []被复制到新字符串的内部时不会发生迭代，因为System.arraycopy最终被调用，它使用诸如memcpy之类的函数在原生的，依赖于实现的级别（ 原始问题 ）复制所需的存储器。
我想亲自检查一下，所以我下载了Openjdk 7源代码并开始浏览它。 我在OpenJDK C ++源代码中找到了System.arraycopy的实现，在openjdx/hotspot/src/share/vm/oops/objArrayKlass.cpp ：
if (stype == bound || Klass::cast(stype)->is_subtype_of(bound)) { // elements are guaranteed to be subtypes, so no check necessary bs->write_ref_array_pre(dst, length); Copy::conjoint_oops_atomic(src, dst, length); } else { // slow case: need individual subtype checks
如果元素不需要类型检查（例如，原始数据类型数组的情况），则调用Copy :: conjoin_oops_atomic。
Copy::conjoint_oops_atomic函数位于’copy.hpp’中：
// overloaded for UseCompressedOops static void conjoint_oops_atomic(narrowOop* from, narrowOop* to, size_t count) { assert(sizeof(narrowOop) == sizeof(jint), "this cast is wrong"); assert_params_ok(from, to, LogBytesPerInt); pd_conjoint_jints_atomic((jint*)from, (jint*)to, count); }
现在我们依赖于平台，因为复制操作具有基于OS /体系结构的不同实现。 我将以Windows为例。 openjdk\hotspot\src\os_cpu\windows_x86\vm\copy_windows_x86.inline.hpp ：
static void pd_conjoint_oops_atomic(oop* from, oop* to, size_t count) { // Do better than this: inline memmove body NEEDS CLEANUP if (from > to) { while (count-- > 0) { // Copy forwards *to++ = *from++; } } else { from += count - 1; to += count - 1; while (count-- > 0) { // Copy backwards *to-- = *from--; } } }
而且……令我惊讶的是，它遍历元素（oop值），逐个复制它们（看似）。 有人可以通过迭代数组中的元素来解释为什么复制完成，即使在本机级别也是如此？
因为jint最接近地映射到int ，其最接近地映射到旧的硬件架构WORD ，其基本上与数据总线的宽度相同。
今天的存储器架构和CPU处理被设计为即使在高速缓存未命中的情况下也尝试处理，并且存储器位置倾向于预取块。 您正在考虑的代码在性能上并不像您想象的那么“糟糕”。 硬件更智能，如果你实际上没有配置文件，你的“智能”提取程序实际上可能不会添加任何东西（甚至减慢处理速度）。
当您了解硬件架构时，必须介绍简单的架构。 现代的做得更多，所以你不能认为看起来低效的代码实际上是低效的。 例如，当完成内存查找以评估if语句的条件时，通常在查找发生时执行if语句的两个分支，并且在数据可用于评估之后丢弃处理的“假”分支。条件。 如果您想要高效，则必须对配置文件数据进行概要分析，然后对其进行操作。
查看JVM操作码部分的分支。 您将看到（或者可能只是）ifdef宏奇怪支持（一次）跳转到处理操作码的代码的三种不同方式。 这是因为三种不同的方式实际上在不同的Windows，Linux和Solaris体系结构上产生了有意义的性能差异。
也许他们可能已经包含了MMX例程，但是他们没有告诉我，SUN并不认为现代硬件的性能提升足以让人担心。