845 // fully_initialized, the intializing_thread of the class becomes |
845 // fully_initialized, the intializing_thread of the class becomes |
846 // NULL, so the next thread to execute this code will fail the test, |
846 // NULL, so the next thread to execute this code will fail the test, |
847 // call into patch_code and complete the patching process by copying |
847 // call into patch_code and complete the patching process by copying |
848 // the patch body back into the main part of the nmethod and resume |
848 // the patch body back into the main part of the nmethod and resume |
849 // executing. |
849 // executing. |
850 // |
850 |
851 // |
851 // NB: |
|
852 // |
|
853 // Patchable instruction sequences inherently exhibit race conditions, |
|
854 // where thread A is patching an instruction at the same time thread B |
|
855 // is executing it. The algorithms we use ensure that any observation |
|
856 // that B can make on any intermediate states during A's patching will |
|
857 // always end up with a correct outcome. This is easiest if there are |
|
858 // few or no intermediate states. (Some inline caches have two |
|
859 // related instructions that must be patched in tandem. For those, |
|
860 // intermediate states seem to be unavoidable, but we will get the |
|
861 // right answer from all possible observation orders.) |
|
862 // |
|
863 // When patching the entry instruction at the head of a method, or a |
|
864 // linkable call instruction inside of a method, we try very hard to |
|
865 // use a patch sequence which executes as a single memory transaction. |
|
866 // This means, in practice, that when thread A patches an instruction, |
|
867 // it should patch a 32-bit or 64-bit word that somehow overlaps the |
|
868 // instruction or is contained in it. We believe that memory hardware |
|
869 // will never break up such a word write, if it is naturally aligned |
|
870 // for the word being written. We also know that some CPUs work very |
|
871 // hard to create atomic updates even of naturally unaligned words, |
|
872 // but we don't want to bet the farm on this always working. |
|
873 // |
|
874 // Therefore, if there is any chance of a race condition, we try to |
|
875 // patch only naturally aligned words, as single, full-word writes. |
852 |
876 |
853 JRT_ENTRY(void, Runtime1::patch_code(JavaThread* thread, Runtime1::StubID stub_id )) |
877 JRT_ENTRY(void, Runtime1::patch_code(JavaThread* thread, Runtime1::StubID stub_id )) |
854 NOT_PRODUCT(_patch_code_slowcase_cnt++;) |
878 NOT_PRODUCT(_patch_code_slowcase_cnt++;) |
855 |
879 |
856 ResourceMark rm(thread); |
880 ResourceMark rm(thread); |
905 // If we are patching a field which should be atomic, then |
929 // If we are patching a field which should be atomic, then |
906 // the generated code is not correct either, force deoptimizing. |
930 // the generated code is not correct either, force deoptimizing. |
907 // We need to only cover T_LONG and T_DOUBLE fields, as we can |
931 // We need to only cover T_LONG and T_DOUBLE fields, as we can |
908 // break access atomicity only for them. |
932 // break access atomicity only for them. |
909 |
933 |
910 // Strictly speaking, the deoptimizaation on 64-bit platforms |
934 // Strictly speaking, the deoptimization on 64-bit platforms |
911 // is unnecessary, and T_LONG stores on 32-bit platforms need |
935 // is unnecessary, and T_LONG stores on 32-bit platforms need |
912 // to be handled by special patching code when AlwaysAtomicAccesses |
936 // to be handled by special patching code when AlwaysAtomicAccesses |
913 // becomes product feature. At this point, we are still going |
937 // becomes product feature. At this point, we are still going |
914 // for the deoptimization for consistency against volatile |
938 // for the deoptimization for consistency against volatile |
915 // accesses. |
939 // accesses. |