Compatible Field Resolution (Very first working prototype)

[Sebastian Sickelmann]

Hi,

the very first prototype implemented inside the vm (without byte code
instrumentation) is working.

For those who want to try it: the changes for this are based on the
hs-rt[5] repository and the patches can be found here [0] [1].

For making this first step easy for me it uses the following configure
parameters: --with-jvm-interpreter=cpp --with-jvm-variants=zero.

To try it out yourself compile the following two source files [2][3]
(with an arbitrary
java-compiler)<http://dict.leo.org/ende/index_de.html#/search=arbitrary&searchLoc=0&resultOrder=basic&multiwordShowSingle=on>

public class Example1 {
  public static void main(String[] args) {
    SubjectToChange stc = new SubjectToChange(5);
    System.out.println(stc.publicField);
    System.out.println(SubjectToChange.publicStaticField);
  }
}

public class SubjectToChange {
  public int publicField;
  public static int publicStaticField = 42;
  public SubjectToChange(int value) {
    this.publicField = value;
  }
}

After compiling you should try starting the Example1.
Then change just the class SubjectToChange to the following[4] implementation.

import java.lang.reflect.Accessor;
public class SubjectToChange {
  private int value;
  private static int staticValue = 43;
  public SubjectToChange(int value) {
    this.value = value;
  }
  @Accessor("publicStaticField")
  public static int getStatic() {
    return staticValue;
  }
  @Accessor("publicStaticField")
  public static void setStatic(int newValue) {
    staticValue = newValue;
  }
  @Accessor("publicField")
  public int getPublicField() {
    return value;
  }
  @Accessor("publicField")
  public void setPublicField(int value) {
    this.value = value;
  }
}

And simple compile only the class SubjectToChange (maybe you use another directory for compilation of the changed version)
You have to use the newly created jdk with the patches from [0] and [1]. There is no change in the javac, but you need the
implementation of the Accessor-Annotation to compile the changed version off SubjectToChange.
I use -source 1.6 -target 1.6 for this one, to later test it also with an older jvm.

If you now run the Example1 with the patches jdk9-vm it prints out 
5
43

If you run the Example1 with another jdk9 / or jdk8 jvm you get the following expected error:
java.lang.NoSuchFieldError: publicField



sebastian at Inspi:~/example1$ ~/jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp orig Example1
5
42
sebastian at Inspi:~/example1$ ~/jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp change:orig Example1
Exception in thread "main" java.lang.NoSuchFieldError: publicField
	at Example1.main(Example1.java:4)

sebastian at Inspi:~/example1$ ~/hs-rt2/build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -cp orig Example1
5
42
sebastian at Inspi:~/example1$ ~/hs-rt2/build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -cp change:orig Example1
5
43


Hope this gives an first idea what could be done with this. In a follow-up post I want to write some more about the implementation.
There are also other ways that should be explored to achieve the same result. Like static postprocessing of jars/modules. 

Brian mentioned that that there maybe some synergies between this idea and Valhalla. I see some common topics with VarHandles, 
do you see another special topic in project Valhalla that has something in common with this idea?

Hope to get some feedback
--
Sebastian

[0]
http://cr.openjdk.java.net/~sebastian/cfa/firstWorkingExample/jdk.00/
[1]
http://cr.openjdk.java.net/~sebastian/cfa/firstWorkingExample/hotspot.00/ [2]
https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/testsrc/incubator/tests/Example1.java
[3]
https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/libsrc/example1/SubjectToChange.java
[4]
https://github.com/picpromusic/incubator/blob/master/jdk/compatibleFieldAccess/libsrc1/example1/SubjectToChange.java
[5] http://hg.openjdk.java.net/jdk9/hs-rt/ On 12/01/2015 02:15 PM,
Sebastian Sickelmann wrote:
> adding valhalla-dev.
>
> Thanks to Brian pointing me in that direction.
>
> On 11/29/2015 05:08 PM, Brian Goetz wrote:
>> I think there may be some synergy between this idea and some of the work going on in project Valhalla.  So you should (also) bring those ideas there.  
>>
>> Also, you might consider jlink as a vehicle for doing such transformations.  
>>
>> Sent from my iPhone
>>
>>> On Nov 29, 2015, at 7:11 AM, Sebastian Sickelmann <sebastian.sickelmann at gmx.de> wrote:
>>>
>>> Hi,
>>>
>>> some time ago I started a discussion on jdk8-dev [0] about a change in
>>> field lookup and resolution to make changes to the visibility of fields
>>> possible without losing binary compatibility. In 2011 unfortunately I
>>> lost track to take my experiments[1] much further.
>>>
>>> Now that i get my feet wet again with some openjdk development and
>>> learned (hopefully) enough about debugging the jdk with gdb and the jdk
>>> itself, i started (a few days ago) my experiment again. This time in the
>>> jvm itself based on the cpp-interpreter (zero) of the jdk9/hs-rt repos.
>>> Hope to get a of this other type of proof of concept presentable soon.
>>>
>>> In the meantime I would love to get some thought about the following
>>> questions/topics:
>>>
>>> Q1: Do you think that java(the jvm) would benefit of some way to make
>>> changes to the visibility of fields in a binary compatible way?
>>> Q2: Do you think that this should be handled at runtime/link-time inside
>>> the vm?
>>> Q3: Or do you think that this should be handled as early as possible
>>> (load-time of classes) --> ex. by exchanging all field access to are not
>>> in the same class(/module??) to an indy-call?
>>> Q4: Or do you think that a "static prior runtime solution" should be
>>> created to update "old" jars/modules?
>>> Q5: If the runtime solution is your choice what to you think, should the
>>> runtime behavior(lookup and linking of field) of the byte-codes
>>> get,put,get-static,put-static also be changed for classes that are
>>> compiled for an older jvm and where the jars/modules are signed by an
>>> digital certificate?
>>> Q6: If not Q5. Should it be allowed by some security-related settings?
>>> Q7: What is about reflection functionality. Should this be changed to?
>>> Field-Lookups, set / get value of fields?
>>>
>>> Hope to get some discussion started. Feel free to answer to one or more
>>> from the questions / topics above.
>>> If you have more questions that should be handled, you are also welcome
>>> to post those.
>>> Every feedback is welcome, even those you say, all this is a really bad
>>> idea.
>>> At least for this last mentioned type of feedback I would prefer to get
>>> some reasons why you think so.
>>>
>>> --
>>> Sebastian
>>>
>>> [0] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html
>>> [1]
>>> https://github.com/picpromusic/incubator/tree/master/jdk/compatibleFieldAccess
>