Compatible Field Resolution (Now inside jlink)

Tue Dec 15 20:09:53 UTC 2015

Sorry, the link to the patches of the prototype is:
http://cr.openjdk.java.net/~sebastian/cfa/jlink/webrev.00/

Hope to get some feedback and/or questions.
--
Sebastian
On 12/15/2015 09:05 PM, Sebastian Sickelmann wrote:
> 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 theck 
> 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
>