jvm中clone的native方法

  假设有一个类Apple(Apple的colne只是简单的调用super.clone), 当我clone一个Apple对象时，首先可以通过在Apple的构造函数中加上输出证明Apple的构造器是不会被调用到的。但是如何证明Object的构造器也不会被调用到呢? 有没有什么工具或方法去证明clone是不会调用Object的clone方法的 

  我跟踪了colne这个native方法, 并下载了hotspot的源代码, 在jvm.cpp中发现了clone方法的实现。

JVM_ENTRY(jobject, JVM_Clone(JNIEnv* env, jobject handle))  JVMWrapper("JVM_Clone");  Handle obj(THREAD, JNIHandles::resolve_non_null(handle));  const KlassHandle klass (THREAD, obj->klass());  JvmtiVMObjectAllocEventCollector oam;#ifdef ASSERT  // Just checking that the cloneable flag is set correct  if (obj->is_javaArray()) {    guarantee(klass->is_cloneable(), "all arrays are cloneable");  } else {    guarantee(obj->is_instance(), "should be instanceOop");    bool cloneable = klass->is_subtype_of(SystemDictionary::Cloneable_klass());    guarantee(cloneable == klass->is_cloneable(), "incorrect cloneable flag");  }#endif  // Check if class of obj supports the Cloneable interface.  // All arrays are considered to be cloneable (See JLS 20.1.5)  if (!klass->is_cloneable()) {    ResourceMark rm(THREAD);    THROW_MSG_0(vmSymbols::java_lang_CloneNotSupportedException(), klass->external_name());  }  // Make shallow object copy  const int size = obj->size();  oop new_obj = NULL;  if (obj->is_javaArray()) {    const int length = ((arrayOop)obj())->length();    new_obj = CollectedHeap::array_allocate(klass, size, length, CHECK_NULL);  } else {    new_obj = CollectedHeap::obj_allocate(klass, size, CHECK_NULL);  }  // 4839641 (4840070): We must do an oop-atomic copy, because if another thread  // is modifying a reference field in the clonee, a non-oop-atomic copy might  // be suspended in the middle of copying the pointer and end up with parts  // of two different pointers in the field.  Subsequent dereferences will crash.  // 4846409: an oop-copy of objects with long or double fields or arrays of same  // won't copy the longs/doubles atomically in 32-bit vm's, so we copy jlongs instead  // of oops.  We know objects are aligned on a minimum of an jlong boundary.  // The same is true of StubRoutines::object_copy and the various oop_copy  // variants, and of the code generated by the inline_native_clone intrinsic.  assert(MinObjAlignmentInBytes >= BytesPerLong, "objects misaligned");  Copy::conjoint_jlongs_atomic((jlong*)obj(), (jlong*)new_obj,                               (size_t)align_object_size(size) / HeapWordsPerLong);  // Clear the header  new_obj->init_mark();  // Store check (mark entire object and let gc sort it out)  BarrierSet* bs = Universe::heap()->barrier_set();  assert(bs->has_write_region_opt(), "Barrier set does not have write_region");  bs->write_region(MemRegion((HeapWord*)new_obj, size));  // Caution: this involves a java upcall, so the clone should be  // "gc-robust" by this stage.  if (klass->has_finalizer()) {    assert(obj->is_instance(), "should be instanceOop");    new_obj = instanceKlass::register_finalizer(instanceOop(new_obj), CHECK_NULL);  }  return JNIHandles::make_local(env, oop(new_obj));JVM_END