641 // There are two types of intrinsic methods: (1) Library intrinsics and (2) bytecode intrinsics.
642 //
643 // (1) A library intrinsic method may be replaced with hand-crafted assembly code,
644 // with hand-crafted compiler IR, or with a combination of the two. The semantics
645 // of the replacement code may differ from the semantics of the replaced code.
646 //
647 // (2) Bytecode intrinsic methods are not replaced by special code, but they are
648 // treated in some other special way by the compiler. For example, the compiler
649 // may delay inlining for some String-related intrinsic methods (e.g., some methods
650 // defined in the StringBuilder and StringBuffer classes, see
651 // Compile::should_delay_string_inlining() for more details).
652 //
653 // Due to the difference between the semantics of an intrinsic method as defined
654 // in the (Java) source code and the semantics of the method as defined
655 // by the code in the VM, intrinsic methods must be explicitly marked.
656 //
657 // Intrinsic methods are marked by the jdk.internal.HotSpotIntrinsicCandidate
658 // annotation. If CheckIntrinsics is enabled, the VM performs the following
659 // checks when a class C is loaded: (1) all intrinsics defined by the VM for
660 // class C are present in the loaded class file and are marked;
661 // (2) an intrinsic is defined by the VM for all marked methods of class C.
662 //
663 // If a mismatch is detected for a method, the VM behaves differently depending
664 // on the type of build. A fastdebug build exits and reports an error on a mismatch.
665 // A product build will not replace an unmarked library intrinsic method with
666 // hand-crafted code, that is, unmarked library intrinsics are treated as ordinary
667 // methods in a product build. The special treatment of a bytecode intrinsic method
668 // persists even if the method not marked.
669 //
670 // When adding an intrinsic for a method, please make sure to appropriately
671 // annotate the method in the source code. The list below contains all
672 // library intrinsics followed by bytecode intrinsics. Please also make sure to
673 // add the declaration of the intrinsic to the approriate section of the list.
674 #define VM_INTRINSICS_DO(do_intrinsic, do_class, do_name, do_signature, do_alias) \
675 /* (1) Library intrinsics */ \
676 do_intrinsic(_hashCode, java_lang_Object, hashCode_name, void_int_signature, F_R) \
677 do_name( hashCode_name, "hashCode") \
678 do_intrinsic(_getClass, java_lang_Object, getClass_name, void_class_signature, F_R) \
679 do_name( getClass_name, "getClass") \
680 do_intrinsic(_clone, java_lang_Object, clone_name, void_object_signature, F_R) \
681 do_name( clone_name, "clone") \
|
641 // There are two types of intrinsic methods: (1) Library intrinsics and (2) bytecode intrinsics.
642 //
643 // (1) A library intrinsic method may be replaced with hand-crafted assembly code,
644 // with hand-crafted compiler IR, or with a combination of the two. The semantics
645 // of the replacement code may differ from the semantics of the replaced code.
646 //
647 // (2) Bytecode intrinsic methods are not replaced by special code, but they are
648 // treated in some other special way by the compiler. For example, the compiler
649 // may delay inlining for some String-related intrinsic methods (e.g., some methods
650 // defined in the StringBuilder and StringBuffer classes, see
651 // Compile::should_delay_string_inlining() for more details).
652 //
653 // Due to the difference between the semantics of an intrinsic method as defined
654 // in the (Java) source code and the semantics of the method as defined
655 // by the code in the VM, intrinsic methods must be explicitly marked.
656 //
657 // Intrinsic methods are marked by the jdk.internal.HotSpotIntrinsicCandidate
658 // annotation. If CheckIntrinsics is enabled, the VM performs the following
659 // checks when a class C is loaded: (1) all intrinsics defined by the VM for
660 // class C are present in the loaded class file and are marked;
661 // (2) an intrinsic is defined by the VM for all marked methods of class C;
662 // (3) check for orphan methods in class C (i.e., methods for which the VM
663 // declares an intrinsic but that are not declared for the loaded class C.
664 // Check (3) is available only in debug builds.
665 //
666 // If a mismatch is detected for a method, the VM behaves differently depending
667 // on the type of build. A fastdebug build exits and reports an error on a mismatch.
668 // A product build will not replace an unmarked library intrinsic method with
669 // hand-crafted code, that is, unmarked library intrinsics are treated as ordinary
670 // methods in a product build. The special treatment of a bytecode intrinsic method
671 // persists even if the method not marked.
672 //
673 // When adding an intrinsic for a method, please make sure to appropriately
674 // annotate the method in the source code. The list below contains all
675 // library intrinsics followed by bytecode intrinsics. Please also make sure to
676 // add the declaration of the intrinsic to the approriate section of the list.
677 #define VM_INTRINSICS_DO(do_intrinsic, do_class, do_name, do_signature, do_alias) \
678 /* (1) Library intrinsics */ \
679 do_intrinsic(_hashCode, java_lang_Object, hashCode_name, void_int_signature, F_R) \
680 do_name( hashCode_name, "hashCode") \
681 do_intrinsic(_getClass, java_lang_Object, getClass_name, void_class_signature, F_R) \
682 do_name( getClass_name, "getClass") \
683 do_intrinsic(_clone, java_lang_Object, clone_name, void_object_signature, F_R) \
684 do_name( clone_name, "clone") \
|