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@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 >
