Compatible Field Resolution (Now inside jlink)

Tue Dec 15 20:05:22 UTC 2015

Hi,

as written (see below) at the discuss[6] and the valhalla-dev[7]
mailing-lists i created
a first working prototype for an experiment "to remove public fields in
a binary
compatible way".

Thanks to Brain who gave me the hint to also experiment with this topic
inside of jlink.

For the jlink experiment I implemented a ClassOptimizer-Plugin which
exchanges the
bytecodes for GETFIELD,PUTFIELD,GETSTATIC,PUTSTATIC to the matching
INVOKEINTERFACE and INVOKESTATIC bytecodes.

I tried jlink with this prototype-patches:
http://cr.openjdk.java.net/~sebastian

I created three modules from the classes from the previous mails(see below).
a demo.app modules containing the unchanged Example1 class.
a demo.lib 1.0 containing the original SubjectToChange class.
a demo.lib 2.0 containing the changed SubjectToChange class.

After linking the demo.app with demo.lib 2.0 it works (same result as
with the runtime
vm-prototype from the mails below)

Hope to get some feedback. Next i will move back to the runtime-vm
experiment and
try to get it working with the templateInterpreter or the
cppInterpreter/x86.

-- Sebastian

[6] http://mail.openjdk.java.net/pipermail/discuss/2015-December/003852.html
[7]
http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-December/001599.html

On 12/05/2015 07:36 PM, Sebastian Sickelmann wrote:
> 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