Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8160527

Check for final instance field updates can be omitted



    • Bug
    • Status: Resolved
    • P3
    • Resolution: Fixed
    • 9
    • 9
    • hotspot
    • None
    • b129


      JDK-8157181 implemented a new check for final field update. The new check verifies if (static) final field are updated only in (class) initializers.

      In a comment added to JDK-8157181, John Rose has pointed out a flaw in the checking logic implemented by JDK-8157181. The flaw affects only instance field updates.

      Here are John's comments on the issue:

      "...there appears to be a hole in the JVM's logic which blocks non-<init> methods from running putfield on final fields. Probably you know about this, but I'll write it here just in case.

      Suppose the interpreter executes a putfield on a final field in an <init> method, which causes a call to LinkResolver::resolve_field_access that succeeds. At that point, InterpreterRuntime::resolve_get_put updates the CP cache entry for the field reference.

      Later on, with the CP cache initialized for "puts" to that field, a random method (not an <init> method) in the same class executes a putfield on that final field. The assembly code checks the CP cache and takes the fast path. The new logic in the changes for JDK-8157181 never gets executed, because it is on the slow path.

      The root issue is that the cached resolution information in the CP cache is shared between <init> and non-<init> methods.

      BTW, I like the fact that, whatever happens with resolution, the rewriter has already scanned for malformed puts to finals, and has set a bit telling the JIT to distrust those fields. This means we shouldn't have mis-optimization even if I'm right about the above weakness in resolution checking.

      Perhaps there is some way to have resolve_get_put refuse to "quicken" the CP cache for a put of a final field, *if* the "has_initialized_final_update" bit has been set by the rewriter. In that case, the slow path would get run all the time for resolution. However, I don't see a way to do this without significant changes to the assembly code."


        Issue Links



              zmajo Zoltan Majo (Inactive)
              zmajo Zoltan Majo (Inactive)
              0 Vote for this issue
              4 Start watching this issue