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@Inspi:~/example1$ > ~/jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java > -cp orig Example1 > 5 > 42 > sebastian@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@Inspi:~/example1$ > ~/hs-rt2/build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -cp > orig Example1 > 5 > 42 > sebastian@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 >>>> <[email protected]> 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
