From sebastian.sickelmann at gmx.de Tue Dec 1 13:15:31 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 1 Dec 2015 14:15:31 +0100 Subject: Compatible Field Resolution In-Reply-To: <33F75FAA-1BE7-470E-9629-4C78B7AF9B77@oracle.com> References: <565AEB85.7020105@gmx.de> <33F75FAA-1BE7-470E-9629-4C78B7AF9B77@oracle.com> Message-ID: <565D9D73.3000206@gmx.de> 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 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 From mohamed.m.m.hafez at gmail.com Wed Dec 2 15:56:04 2015 From: mohamed.m.m.hafez at gmail.com (Mohamed Hafez) Date: Wed, 2 Dec 2015 07:56:04 -0800 Subject: is the openjdk-r ppa trustworthy? Message-ID: I've seen a ton of blogs saying Java 8 is now available to Ubuntu 12.04 & 14.04 through the ppa openjdk-r. My question is how trustworthy is this ppa? Is it run by people from openjdk or ubuntu or something, or is it just some random source? Looking at https://launchpad.net/~openjdk-r it looks official-ish... From martinrb at google.com Wed Dec 2 17:37:50 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 2 Dec 2015 09:37:50 -0800 Subject: is the openjdk-r ppa trustworthy? In-Reply-To: References: Message-ID: (adding the people who would know) I don't think any Ubuntu backport is official until it shows up in e.g. trusty-backports (and it's not there (yet)) http://packages.ubuntu.com/search?keywords=openjdk-8&searchon=names&suite=all§ion=all On Wed, Dec 2, 2015 at 7:56 AM, Mohamed Hafez wrote: > I've seen a ton of blogs saying Java 8 is now available to Ubuntu 12.04 & > 14.04 through the ppa openjdk-r. My question is how trustworthy is this > ppa? Is it run by people from openjdk or ubuntu or something, or is it just > some random source? Looking at https://launchpad.net/~openjdk-r it looks > official-ish... > From mohamed.m.m.hafez at gmail.com Wed Dec 2 17:46:50 2015 From: mohamed.m.m.hafez at gmail.com (Mohamed Hafez) Date: Wed, 2 Dec 2015 09:46:50 -0800 Subject: is the openjdk-r ppa trustworthy? In-Reply-To: References: Message-ID: Looks like one of the people you added is listed as the owner of the ppa, so I'm going to take that as a "yes its trustworthy":) Thanks! On Wed, Dec 2, 2015 at 9:37 AM, Martin Buchholz wrote: > (adding the people who would know) > I don't think any Ubuntu backport is official until it shows up in e.g. > trusty-backports (and it's not there (yet)) > > http://packages.ubuntu.com/search?keywords=openjdk-8&searchon=names&suite=all§ion=all > > On Wed, Dec 2, 2015 at 7:56 AM, Mohamed Hafez > wrote: > >> I've seen a ton of blogs saying Java 8 is now available to Ubuntu 12.04 & >> 14.04 through the ppa openjdk-r. My question is how trustworthy is this >> ppa? Is it run by people from openjdk or ubuntu or something, or is it >> just >> some random source? Looking at https://launchpad.net/~openjdk-r it looks >> official-ish... >> > > From ott at mirix.org Wed Dec 2 19:39:56 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Wed, 02 Dec 2015 19:39:56 +0000 Subject: How can I report bugs in OpenJDK? Message-ID: <565F490C.2000307@mirix.org> I would like to know if and how I can report bugs in OpenJDK? I don't have an account for bugs.openjdk.java.net and I'm not otherwise involved in the project. - Matthias-Christian From dalibor.topic at oracle.com Wed Dec 2 19:42:22 2015 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 2 Dec 2015 20:42:22 +0100 Subject: How can I report bugs in OpenJDK? In-Reply-To: <565F490C.2000307@mirix.org> References: <565F490C.2000307@mirix.org> Message-ID: <565F499E.2060304@oracle.com> On 12/2/15 8:39 PM, Matthias-Christian Ott wrote: > I would like to know if and how I can report bugs in OpenJDK? I don't > have an account for bugs.openjdk.java.net and I'm not otherwise involved > in the project. Either directly to the provider of your binaries, if you use third party provided OpenJDK binaries, or, if you build your own, through bugs.java.com. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From ott at mirix.org Wed Dec 2 19:50:06 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Wed, 02 Dec 2015 19:50:06 +0000 Subject: How can I report bugs in OpenJDK? In-Reply-To: <565F499E.2060304@oracle.com> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> Message-ID: <565F4B6E.2020207@mirix.org> On 02/12/15 19:42, Dalibor Topic wrote: > On 12/2/15 8:39 PM, Matthias-Christian Ott wrote: >> I would like to know if and how I can report bugs in OpenJDK? I don't >> have an account for bugs.openjdk.java.net and I'm not otherwise involved >> in the project. > > Either directly to the provider of your binaries, if you use third party provided OpenJDK binaries, > or, if you build your own, through bugs.java.com. I build my own binaries. bugreport.java.com does not list OpenJDK as a product. Which one do I have to select? I'm not interested in helping Oracle improve its proprietary products. Are bugs that are reported through bugreport.java.com public or private to Oracle? - Matthias-Christian From dalibor.topic at oracle.com Wed Dec 2 20:07:52 2015 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 2 Dec 2015 21:07:52 +0100 Subject: How can I report bugs in OpenJDK? In-Reply-To: <565F4B6E.2020207@mirix.org> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> Message-ID: <565F4F98.7030609@oracle.com> On 12/2/15 8:50 PM, Matthias-Christian Ott wrote: > I build my own binaries. bugreport.java.com does not list OpenJDK as a > product. Which one do I have to select? OpenJDK is not product, so it's not listed as such. Depending on the area you'd like to report the issue in, you would typically pick the Java Platform, Standard Edition. > Are bugs that are reported through bugreport.java.com public or private > to Oracle? "Users without an account can also use bugs.sun.com to submit an issue. When such an issue is submitted, a record is created in the Java Incidents (JI) project in JBS; at the time of launch, the JI project is not publicly visible. Issues in the JI project have an identifier like JI-9XXXXXX, where the numeric portion corresponds to the bug identifier sent back to the submitter. After an initial triage process, if the incidents needs further review, it can be transferred to be an issue in the JDK project. When such a transfer occurs, the issue gets a new identifier in the JDK project (JDK-8YYYYYY) but references to the original JI-9XXXXXX number will be redirected." from https://wiki.openjdk.java.net/display/general/JBS+Overview cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From ott at mirix.org Thu Dec 3 09:53:49 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Dec 2015 09:53:49 +0000 Subject: How can I report bugs in OpenJDK? In-Reply-To: <565F4F98.7030609@oracle.com> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> Message-ID: <5660112D.6090506@mirix.org> First of all thank you for outlining the process. On 02/12/15 20:07, Dalibor Topic wrote: > OpenJDK is not product, so it's not listed as such. > > Depending on the area you'd like to report the issue in, you would typically pick the Java Platform, > Standard Edition. That would mean that I file a bug against Oracle's proprietary Java implementation. Of course it almost identical to OpenJDK but how do I know without the source code or installing the software and extensive testing? Just a remark. > "Users without an account can also use bugs.sun.com to submit an issue. [...]" > > from https://wiki.openjdk.java.net/display/general/JBS+Overview I see. I had found this page myself but I'm looking for a different solution as OpenJDK handles bug reporting from different other Free Software projects and very common principles like transparency and openness seem to be secondary. I can understand that there is a need for quality assurance of bug reports but this can also be achieved in other ways as demonstrated by other Free Software projects that are subject to major commercial interests. To make a long story short: Would it also be permissible and helpful to submit bug reports to core-libs-dev@ and ask for the bug report to be publicly filed in JBS? - Matthias-Christian From robert.zenz at sibvisions.com Thu Dec 3 10:11:05 2015 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Thu, 3 Dec 2015 10:11:05 +0000 Subject: How can I report bugs in OpenJDK? In-Reply-To: <5660112D.6090506@mirix.org> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> Message-ID: <5660153B.1020302@sibvisions.com> There was a discussion to revamp the bug reporting and participation mechanism to allow more transparency and better feedback from users in the light of the merge of the JavaFX bugtracker into the JDK one. Previously the JavaFX bugtracker allowed to create accounts and comment on all bugs, which is not possible in the JDK one. Though, that discussion died off fast (or never took really off for that matter) back then. So you might want to look into the archives for that one, I think that took part in discuss or web-discuss, not sure. Also in the openjfx-dev mailing list such a discussion has been respawned in the light of questioning whether or not JavaFX is a reliable technology (future wise), you can find it under the title "Future of JavaFX" in the archives, the discussion is still going on. You maybe want to participate there. On 03.12.2015 10:53, Matthias-Christian Ott wrote: > First of all thank you for outlining the process. > > On 02/12/15 20:07, Dalibor Topic wrote: >> OpenJDK is not product, so it's not listed as such. >> >> Depending on the area you'd like to report the issue in, you would typically pick the Java Platform, >> Standard Edition. > > That would mean that I file a bug against Oracle's proprietary Java > implementation. Of course it almost identical to OpenJDK but how do I > know without the source code or installing the software and extensive > testing? Just a remark. > >> "Users without an account can also use bugs.sun.com to submit an issue. [...]" >> >> from https://wiki.openjdk.java.net/display/general/JBS+Overview > > I see. I had found this page myself but I'm looking for a different > solution as OpenJDK handles bug reporting from different other Free > Software projects and very common principles like transparency and > openness seem to be secondary. I can understand that there is a need for > quality assurance of bug reports but this can also be achieved in other > ways as demonstrated by other Free Software projects that are subject to > major commercial interests. > > To make a long story short: Would it also be permissible and helpful to > submit bug reports to core-libs-dev@ and ask for the bug report to be > publicly filed in JBS? > > - Matthias-Christian > From dalibor.topic at oracle.com Thu Dec 3 12:17:19 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 3 Dec 2015 13:17:19 +0100 Subject: How can I report bugs in OpenJDK? In-Reply-To: <5660153B.1020302@sibvisions.com> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> <5660153B.1020302@sibvisions.com> Message-ID: <566032CF.2070907@oracle.com> On 03.12.2015 11:11, Robert Zenz wrote: > Also in the openjfx-dev mailing list such a discussion has been > respawned > You maybe want to participate there. No, please don't. The openjfx-dev mailing list, like most OpenJDK mailing lists is for technical discussions about development *only*. Abusing it to discuss non-technical matters that better belong on adoption-discuss or discuss is neither desirable nor should it be encouraged. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Dec 3 12:26:02 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 3 Dec 2015 13:26:02 +0100 Subject: How can I report bugs in OpenJDK? In-Reply-To: <5660112D.6090506@mirix.org> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> Message-ID: <566034DA.3090404@oracle.com> On 03.12.2015 10:53, Matthias-Christian Ott wrote: > First of all thank you for outlining the process. Thanks! > To make a long story short: Would it also be permissible Not really. If you look at the description of core-libs-dev and most other mailing lists, they serve for technical discussion of OpenJDK development in a respective area. They should not be used for other, non-technical discussions - that's what this list is for, for example. So if you wanted to discuss ideas for a fix in a specific area before you started working on one, that would be just fine. In that case, please see the contributing guide at http://openjdk.java.net/contribute/ for the requirements and steps to take. Just spamming various technical lists with bug reports in hope that someone else among the hundreds of subscribers files issues that you could easily just file yourself, on the other hand, would not be OK. > and helpful to > submit bug reports to core-libs-dev@ and ask for the bug report to be > publicly filed in JBS? Not at all, no. In that case your participation would be a net loss for this community, and I'd suggest reconsidering it, if that's all you're after. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From robert.zenz at sibvisions.com Thu Dec 3 13:03:13 2015 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Thu, 3 Dec 2015 13:03:13 +0000 Subject: How can I report bugs in OpenJDK? In-Reply-To: <566032CF.2070907@oracle.com> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> <5660153B.1020302@sibvisions.com> <566032CF.2070907@oracle.com> Message-ID: <56603D92.1030200@sibvisions.com> What I meant is "participate in that discussion/initiative", not necessarily in that thread...which will sooner or later migrate off that list anyway. On 03.12.2015 13:17, dalibor topic wrote: > > > On 03.12.2015 11:11, Robert Zenz wrote: >> Also in the openjfx-dev mailing list such a discussion has been >> respawned >> You maybe want to participate there. > > No, please don't. > > The openjfx-dev mailing list, like most OpenJDK mailing lists is for > technical discussions about development *only*. > > Abusing it to discuss non-technical matters that better belong on > adoption-discuss or discuss is neither desirable nor should it be > encouraged. > > cheers, > dalibor topic > From ott at mirix.org Thu Dec 3 13:37:26 2015 From: ott at mirix.org (Matthias-Christian Ott) Date: Thu, 03 Dec 2015 13:37:26 +0000 Subject: How can I report bugs in OpenJDK? In-Reply-To: <566034DA.3090404@oracle.com> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> <566034DA.3090404@oracle.com> Message-ID: <56604596.9040703@mirix.org> On 03/12/15 12:26, dalibor topic wrote: > On 03.12.2015 10:53, Matthias-Christian Ott wrote: >> To make a long story short: Would it also be permissible > > Not really. > > If you look at the description of core-libs-dev and most other mailing > lists, they serve for technical discussion of OpenJDK development in a > respective area. They should not be used for other, non-technical > discussions - that's what this list is for, for example. I understand what you are trying to say: bug trackers can handle bugs more appropriately. I agree. However, a short remark about the justification: are bug reports non-technical in your opinion? Bug reporting is an integral part of every software development process. > So if you wanted to discuss ideas for a fix in a specific area before > you started working on one, that would be just fine. In that case, > please see the contributing guide at http://openjdk.java.net/contribute/ > for the requirements and steps to take. Thank you for the link. At the moment I don't want to work on the issues but just report them. Other volunteers can perhaps fix them more easily and quickly than I can or the bug reports can simply serve as documentation. Moreover, I'm not sure that I understand or that I'm willing to sign the copyright assignment. > Just spamming various technical lists with bug reports in hope that > someone else among the hundreds of subscribers files issues that you > could easily just file yourself, on the other hand, would not be OK. I see. However, it seemed to me to be the only way to make the bug reports immediately public. I also submitted them through bugreport.java.com after they had been published on the mailing list. Perhaps I should publish them on my website first the next time and then submit them through bugreport.java.com. This would be an acceptable middle ground for me. I didn't mean to annoy anybody with useless email. I think the bug reporting process is now relatively clear to me. Thank you for the explanation and patience. I will try to fulfil the expectations of the OpenJDK community with regards to bug reporting and while also trying to meet my requirements of openness and transparency in the future. I have one last question: Who decides whether and when a JI becomes an issue in JBS and who decides whether and when a security vulnerability reported to secalert_us at oracle.com becomes an issue in JBS? For example FreeBSD has a policies for this [1,2] and I never had a problem reporting bugs to them. [1] https://www.freebsd.org/support/bugreports.html [2] https://www.freebsd.org/security/reporting.html From dalibor.topic at oracle.com Thu Dec 3 14:08:15 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 3 Dec 2015 15:08:15 +0100 Subject: How can I report bugs in OpenJDK? In-Reply-To: <56604596.9040703@mirix.org> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> <566034DA.3090404@oracle.com> <56604596.9040703@mirix.org> Message-ID: <56604CCF.8060004@oracle.com> On 03.12.2015 14:37, Matthias-Christian Ott wrote: > However, a short remark about the > justification: are bug reports non-technical in your opinion? It depends on the bug report, ultimately. For example, if the 'bug' one is trying to report is 'I read something somewhere on the Internet, is it really true?' then that's not actually technical, even when presented as a bug report of sorts ... > and who decides whether and when a security vulnerability > reported to secalert_us at oracle.com becomes an issue in JBS? Please see [0] for information about Oracle's Security Vulnerability Remediation Practices. cheers, dalibor topic [0] https://www.oracle.com/support/assurance/vulnerability-remediation/introduction.html -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From martijnverburg at gmail.com Thu Dec 3 14:35:07 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 3 Dec 2015 14:35:07 +0000 Subject: How can I report bugs in OpenJDK? In-Reply-To: <56604CCF.8060004@oracle.com> References: <565F490C.2000307@mirix.org> <565F499E.2060304@oracle.com> <565F4B6E.2020207@mirix.org> <565F4F98.7030609@oracle.com> <5660112D.6090506@mirix.org> <566034DA.3090404@oracle.com> <56604596.9040703@mirix.org> <56604CCF.8060004@oracle.com> Message-ID: Hi all, Could using Jiras capabilities to ensure certain details are provided help improve the quality of bug submissions? I've used that successfully in the past for other large OSS projects to avoid the high noise to signal ratio. Perhaps a trial could be run with a limited set of bug reporters and see what the quality looks like... ---- Alternatively could Oracle perhaps assign some resource into making the bugs.sun.com UI/Ux a little more friendly and have the tie in to JBS made more clear? I appreciate the underlying system probably can't be touched, but perhaps the HTML/CSS etc could be? Cheers, Martijn On 3 December 2015 at 14:08, dalibor topic wrote: > On 03.12.2015 14:37, Matthias-Christian Ott wrote: > >> However, a short remark about the >> justification: are bug reports non-technical in your opinion? >> > > It depends on the bug report, ultimately. > > For example, if the 'bug' one is trying to report is 'I read something > somewhere on the Internet, is it really true?' then that's not actually > technical, even when presented as a bug report of sorts ... > > and who decides whether and when a security vulnerability >> reported to secalert_us at oracle.com becomes an issue in JBS? >> > > Please see [0] for information about Oracle's Security Vulnerability > Remediation Practices. > > cheers, > dalibor topic > > [0] > https://www.oracle.com/support/assurance/vulnerability-remediation/introduction.html > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From sebastian.sickelmann at gmx.de Sat Dec 5 18:36:19 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sat, 5 Dec 2015 19:36:19 +0100 Subject: Compatible Field Resolution (Very first working prototype) In-Reply-To: <565D9D73.3000206@gmx.de> References: <565AEB85.7020105@gmx.de> <33F75FAA-1BE7-470E-9629-4C78B7AF9B77@oracle.com> <565D9D73.3000206@gmx.de> Message-ID: <56632EA3.9040607@gmx.de> 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) 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 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 > From matthiaswahl at m7w3.de Wed Dec 9 16:04:59 2015 From: matthiaswahl at m7w3.de (Matthias Wahl) Date: Wed, 9 Dec 2015 17:04:59 +0100 Subject: max heap size for compressed oops Message-ID: <5668512B.4070908@m7w3.de> Hello, i was delving into performance considerations that some java based projects suggested. One is restricting the maximum heap size on 64 bit systems due to the limitation on compressed Oops. The docs e.g. https://wiki.openjdk.java.net/display/HotSpot/CompressedOops mention an upper limit of 32GB. Howerer the elasticsearch documentation recommends to not increase the heap size beyond 30.5GB : https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops it's the only source i know using this recommendation. They recently changed it due to an advice from oracle, they say. but no reason why is given. Do you know any reason for limiting the heap size to 30.5 GB instead of 32 GB? thanks in advance! Matthias Wahl this is kind of a cross-post as it was already asked on IRC. But I'll repeat it here, so any answer may persist for others having the same question. From martijnverburg at gmail.com Wed Dec 9 16:27:55 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 9 Dec 2015 16:27:55 +0000 Subject: max heap size for compressed oops In-Reply-To: <5668512B.4070908@m7w3.de> References: <5668512B.4070908@m7w3.de> Message-ID: Hi Matthias, OpenJDK mailing lists are (primarily) for discussions on technical work of OpenJDK itself. You may get some joy out of the hotspot-dev mailing list but you're probably better off trying one of the following performance communities: Mechanical Sympathy: https://groups.google.com/forum/#!forum/mechanical-sympathy Friends of jClarity: https://groups.google.com/a/jclarity.com/forum/#!forum/friends Cheers, Martijn On 9 December 2015 at 16:04, Matthias Wahl wrote: > Hello, > > i was delving into performance considerations that some java based > projects suggested. One is restricting the maximum heap size on 64 bit > systems due to the limitation on compressed Oops. The docs e.g. > https://wiki.openjdk.java.net/display/HotSpot/CompressedOops mention an > upper limit of 32GB. > > Howerer the elasticsearch documentation recommends to not increase the > heap size beyond 30.5GB : > > https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops > > it's the only source i know using this recommendation. > They recently changed it due to an advice from oracle, they say. but no > reason why is given. > > Do you know any reason for limiting the heap size to 30.5 GB instead of > 32 GB? > > thanks in advance! > > Matthias Wahl > > this is kind of a cross-post as it was already asked on IRC. But I'll > repeat it here, so any answer may persist for others having the same > question. > From aph at redhat.com Wed Dec 9 17:11:55 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Dec 2015 17:11:55 +0000 Subject: max heap size for compressed oops In-Reply-To: <5668512B.4070908@m7w3.de> References: <5668512B.4070908@m7w3.de> Message-ID: <566860DB.3040304@redhat.com> On 12/09/2015 04:04 PM, Matthias Wahl wrote: > Do you know any reason for limiting the heap size to 30.5 GB instead of > 32 GB? The interesting thing you can do is use -XX:+PrintAssembly and have a look. My guess is that it has to do with zero-based compressed OOPs: if you can use zero as the base pointer you don't have to dedicate a register to the job and the compressing/decompressing code is faster. A narrow OOP is computed by oop_address == 0 ? 0 : (oop_address - heap_base) >> shift The OOP at 0 is a null, of course. If the heap base is zero, you can encode an OOP with a single shift instruction: lsr x0, x0, #3 But if the heap base is not zero, encoding an OOP gets nasty: subs x0, x0, xheapbase csel x0, x0, xzr, cs lsr x0, x0, #3 Here there are three instructions, one of them conditional. In the commonest case most modern processors can do the shifting in parallel with some other operation, so the cost of compressed OOPs is often zero as long as the heap base is zero. But there's no way that the three instructions used encoding an OOP with a nonzero heap base are gong to cost nothing. So why is there a difference between 30.5G and 32G? Because in practice the JVM sits in the bottom 1.5G or so of memory and the heap is immediately above it, so the heap base for compressed OOPs can be zero. Does that make sense? Andrew. From matthiaswahl at m7w3.de Fri Dec 11 15:13:15 2015 From: matthiaswahl at m7w3.de (Matthias Wahl) Date: Fri, 11 Dec 2015 16:13:15 +0100 Subject: max heap size for compressed oops In-Reply-To: <566860DB.3040304@redhat.com> References: <5668512B.4070908@m7w3.de> <566860DB.3040304@redhat.com> Message-ID: <566AE80B.8090404@m7w3.de> Thanks for your quick reply. This makes complete sense. It sheds some light on how compressed oops work. Unfortunately it does not answer my initial question. In the mean time i was able to figure out that we actually have compressed oops up to 32 GB: $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xmx32g -Xms32g -XX:+UseCompressedOops -version Java HotSpot(TM) 64-Bit Server VM warning: Max heap size too large for Compressed Oops java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) ---- $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xmx31999m -Xms31999m -XX:+UseCompressedOops -version Protected page at the reserved heap base: 0x000000011e000000 / 2097152 bytes heap address: 0x000000011e200000, size: 30502 MB, Compressed Oops with base: 0x000000011e1ff000 Narrow klass base: 0x00000008d6263000, Narrow klass shift: 0 Compressed class space size: 1073741824 Address: 0x00000008d6263000 Req Addr: 0x0000000890800000 java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) ---- So I am still searching for a reason for the 30.5GB suggestion. But I think we can narrow it down to some GC (G1) performance hint. Does anybody have a clue on why heaps > 30.5 GB may induce really worse performance characteristics? Be it G1 or CMS Garbage Collector. Thank you! Just ignore this mail if you think it's not the right place for such questions. Matthias Am 12/9/15 um 6:11 PM schrieb Andrew Haley: > On 12/09/2015 04:04 PM, Matthias Wahl wrote: >> Do you know any reason for limiting the heap size to 30.5 GB instead of >> 32 GB? > > The interesting thing you can do is use -XX:+PrintAssembly and have a > look. My guess is that it has to do with zero-based compressed OOPs: > if you can use zero as the base pointer you don't have to dedicate a > register to the job and the compressing/decompressing code is faster. > > A narrow OOP is computed by > > oop_address == 0 ? 0 : (oop_address - heap_base) >> shift > > The OOP at 0 is a null, of course. > > If the heap base is zero, you can encode an OOP with a single > shift instruction: > > lsr x0, x0, #3 > > But if the heap base is not zero, encoding an OOP gets nasty: > > subs x0, x0, xheapbase > csel x0, x0, xzr, cs > lsr x0, x0, #3 > > Here there are three instructions, one of them conditional. In the > commonest case most modern processors can do the shifting in parallel > with some other operation, so the cost of compressed OOPs is often > zero as long as the heap base is zero. But there's no way that the > three instructions used encoding an OOP with a nonzero heap base are > gong to cost nothing. > > So why is there a difference between 30.5G and 32G? Because in > practice the JVM sits in the bottom 1.5G or so of memory and the heap > is immediately above it, so the heap base for compressed OOPs can be > zero. > > Does that make sense? > > Andrew. > From adinn at redhat.com Fri Dec 11 15:32:01 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Dec 2015 15:32:01 +0000 Subject: max heap size for compressed oops In-Reply-To: <566AE80B.8090404@m7w3.de> References: <5668512B.4070908@m7w3.de> <566860DB.3040304@redhat.com> <566AE80B.8090404@m7w3.de> Message-ID: <566AEC71.5000905@redhat.com> On 11/12/15 15:13, Matthias Wahl wrote: > Thanks for your quick reply. > > This makes complete sense. > > It sheds some light on how compressed oops work. > Unfortunately it does not answer my initial question. . . . > Does anybody have a clue on why heaps > 30.5 GB may induce really worse > performance characteristics? Be it G1 or CMS Garbage Collector. Evidently it didn't make *complete* sense. If you retry your experiment using both a 32 GB and a heap slightly smaller than 32GB you will see that Andrew's answer really does address your question. Here's a 32GB heap: [adinn at sputstik ~]$ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xmx30g -Xms30g -XX:+UseCompressedOops -version Protected page at the reserved heap base: 0x00007fe0b7700000 / 524288 bytes heap address: 0x00007fe0b7780000, size: 30802 MB, Compressed Oops with base: 0x00007fe0b777f000 java version "1.7.0_75" Java(TM) SE Runtime Environment (build 1.7.0_75-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode) So, this heap is not zero based which means compressed oops are stored and loaded in other objects as offsets. They need to be converted to/from addresses by adding or subtracting the heap base. Now, here's a 28GB heap [adinn at sputstik ~]$ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xmx28g -Xms28g -XX:+UseCompressedOops -version heap address: 0x00000000fad80000, size: 28754 MB, zero based Compressed Oops java version "1.7.0_75" Java(TM) SE Runtime Environment (build 1.7.0_75-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode) [adinn at sputstik ~]$ This smaller heap is zero-based which means compressed oops are absolute addresses, rather than offsets. So, they can be stored and loaded into/from objects without the need to add or subtract a base address. That is enough to make a *big* difference to performance. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors:Michael Cunningham (US), Michael O'Neill(Ireland), Paul Argiry (US) From volker.simonis at gmail.com Fri Dec 11 15:39:13 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 11 Dec 2015 16:39:13 +0100 Subject: max heap size for compressed oops In-Reply-To: <566AE80B.8090404@m7w3.de> References: <5668512B.4070908@m7w3.de> <566860DB.3040304@redhat.com> <566AE80B.8090404@m7w3.de> Message-ID: Hi Matthias, the problem with compressed opps is that you usually want zero-based compressed oops (there are other compressed oops and they help to save some heap memory as well, but they usually behave worse from a performance point of view). But the problem of getting a 32GB chunk of virtual memory at a very low address (near 0) is inherently platform and system dependent. So if you configure your Java heap just a little too big, you may loose the ability to use compressed oops which may suddenly lead to out of memory situations compared to a slightly smaller heap with compressed oops. That's because in the bigger heap you can now (i.e. without compressed oops) store fewer Java objects (because the single Java objects are bigger). Using 30.5GB instead of 32 is probably just a heuristically found value which should ensure you can run with compressed oops. But again that's platform, system and even application dependent (e.g. if you launch Java from a custom launcher which already reserves memory in the low address space it may be much fewer memory which is available for compressed oops). Regards, Volker On Fri, Dec 11, 2015 at 4:13 PM, Matthias Wahl wrote: > Thanks for your quick reply. > > This makes complete sense. > > It sheds some light on how compressed oops work. > Unfortunately it does not answer my initial question. > > In the mean time i was able to figure out that we actually have > compressed oops up to 32 GB: > > > $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode > -Xmx32g -Xms32g -XX:+UseCompressedOops -version > Java HotSpot(TM) 64-Bit Server VM warning: Max heap size too large for > Compressed Oops > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > ---- > > $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode > -Xmx31999m -Xms31999m -XX:+UseCompressedOops -version > > Protected page at the reserved heap base: 0x000000011e000000 / 2097152 bytes > > heap address: 0x000000011e200000, size: 30502 MB, Compressed Oops with > base: 0x000000011e1ff000 > > Narrow klass base: 0x00000008d6263000, Narrow klass shift: 0 > Compressed class space size: 1073741824 Address: 0x00000008d6263000 Req > Addr: 0x0000000890800000 > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > ---- > > So I am still searching for a reason for the 30.5GB suggestion. > But I think we can narrow it down to some GC (G1) performance hint. > > Does anybody have a clue on why heaps > 30.5 GB may induce really worse > performance characteristics? Be it G1 or CMS Garbage Collector. > > Thank you! > > Just ignore this mail if you think it's not the right place for such > questions. > > > Matthias > > > Am 12/9/15 um 6:11 PM schrieb Andrew Haley: >> On 12/09/2015 04:04 PM, Matthias Wahl wrote: >>> Do you know any reason for limiting the heap size to 30.5 GB instead of >>> 32 GB? >> >> The interesting thing you can do is use -XX:+PrintAssembly and have a >> look. My guess is that it has to do with zero-based compressed OOPs: >> if you can use zero as the base pointer you don't have to dedicate a >> register to the job and the compressing/decompressing code is faster. >> >> A narrow OOP is computed by >> >> oop_address == 0 ? 0 : (oop_address - heap_base) >> shift >> >> The OOP at 0 is a null, of course. >> >> If the heap base is zero, you can encode an OOP with a single >> shift instruction: >> >> lsr x0, x0, #3 >> >> But if the heap base is not zero, encoding an OOP gets nasty: >> >> subs x0, x0, xheapbase >> csel x0, x0, xzr, cs >> lsr x0, x0, #3 >> >> Here there are three instructions, one of them conditional. In the >> commonest case most modern processors can do the shifting in parallel >> with some other operation, so the cost of compressed OOPs is often >> zero as long as the heap base is zero. But there's no way that the >> three instructions used encoding an OOP with a nonzero heap base are >> gong to cost nothing. >> >> So why is there a difference between 30.5G and 32G? Because in >> practice the JVM sits in the bottom 1.5G or so of memory and the heap >> is immediately above it, so the heap base for compressed OOPs can be >> zero. >> >> Does that make sense? >> >> Andrew. >> From matthiaswahl at m7w3.de Fri Dec 11 15:41:36 2015 From: matthiaswahl at m7w3.de (Matthias Wahl) Date: Fri, 11 Dec 2015 16:41:36 +0100 Subject: max heap size for compressed oops In-Reply-To: <566AEC71.5000905@redhat.com> References: <5668512B.4070908@m7w3.de> <566860DB.3040304@redhat.com> <566AE80B.8090404@m7w3.de> <566AEC71.5000905@redhat.com> Message-ID: <566AEEB0.4070909@m7w3.de> Am 12/11/15 um 4:32 PM schrieb Andrew Dinn: > On 11/12/15 15:13, Matthias Wahl wrote: >> Thanks for your quick reply. >> >> This makes complete sense. >> >> It sheds some light on how compressed oops work. >> Unfortunately it does not answer my initial question. > . . . >> Does anybody have a clue on why heaps > 30.5 GB may induce really worse >> performance characteristics? Be it G1 or CMS Garbage Collector. > > Evidently it didn't make *complete* sense. > > If you retry your experiment using both a 32 GB and a heap slightly > smaller than 32GB you will see that Andrew's answer really does address > your question. > > Here's a 32GB heap: > > [adinn at sputstik ~]$ java -XX:+UnlockDiagnosticVMOptions > -XX:+PrintCompressedOopsMode -Xmx30g -Xms30g -XX:+UseCompressedOops -version > > Protected page at the reserved heap base: 0x00007fe0b7700000 / 524288 bytes > > heap address: 0x00007fe0b7780000, size: 30802 MB, Compressed Oops with > base: 0x00007fe0b777f000 > > java version "1.7.0_75" > Java(TM) SE Runtime Environment (build 1.7.0_75-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode) > > So, this heap is not zero based which means compressed oops are stored > and loaded in other objects as offsets. They need to be converted > to/from addresses by adding or subtracting the heap base. > > Now, here's a 28GB heap > > [adinn at sputstik ~]$ java -XX:+UnlockDiagnosticVMOptions > -XX:+PrintCompressedOopsMode -Xmx28g -Xms28g -XX:+UseCompressedOops -version > > heap address: 0x00000000fad80000, size: 28754 MB, zero based Compressed Oops > > java version "1.7.0_75" > Java(TM) SE Runtime Environment (build 1.7.0_75-b13) > Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode) > [adinn at sputstik ~]$ > > This smaller heap is zero-based which means compressed oops are absolute > addresses, rather than offsets. So, they can be stored and loaded > into/from objects without the need to add or subtract a base address. > > That is enough to make a *big* difference to performance. Yeah that is true as Andrew Haley already pointed out showing the assembly which gets produced. But as the important border for zero based compressed oops is around 28 GB it cannot be a reason for suggesting 30.5 GB as heap size for performance reasons. As you've shown above even for 30 GB you already have compressed oops with a base > 0. That's why I am now asking for reasons related to the garbage collector that might cause bad performance especially for heaps > 30.5 GB. Kind regards Matthias Wahl From aph at redhat.com Fri Dec 11 16:43:34 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Dec 2015 16:43:34 +0000 Subject: max heap size for compressed oops In-Reply-To: <566AEEB0.4070909@m7w3.de> References: <5668512B.4070908@m7w3.de> <566860DB.3040304@redhat.com> <566AE80B.8090404@m7w3.de> <566AEC71.5000905@redhat.com> <566AEEB0.4070909@m7w3.de> Message-ID: <566AFD36.6000105@redhat.com> On 12/11/2015 03:41 PM, Matthias Wahl wrote: > But as the important border for zero based compressed oops is around 28 GB > it cannot be a reason for suggesting 30.5 GB as heap size for > performance reasons. As you've shown above even for 30 GB you already > have compressed oops with a base > 0. This works for me: $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode -Xmx30g -XX:+UseCompressedOops -version heap address: 0x0000000080000000, size: 30720 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 Narrow klass base: 0x0000000800000000, Narrow klass shift: 0 Compressed class space size: 1073741824 Address: 0x0000000800000000 Req Addr: 0x0000000800000000 openjdk version "1.9.0-internal" You just have to probe your own system to figure out exactly where the cutoff is. There's nothing special about 30.5 GB. Andrew. From zen at freedbms.net Sat Dec 12 02:50:04 2015 From: zen at freedbms.net (Zenaan Harkness) Date: Sat, 12 Dec 2015 02:50:04 +0000 Subject: RFC for future/ enhancement of java.lang.String - was Fwd: [Yaml-core] encoding and content in YML files Message-ID: java.lang.String is deficient. It does not provide a way to lay out a random "string" of Unicode characters ("graphemes" or "characters as the user perceives them"), e.g. to center or right-align such a "string" of "characters" in a text console. In discovering this I embarked on a two week journey of reading and a little code exploration. See here for current status including a detailed Javadoc detailing the issues we face: https://zenaan.github.io/zen/javadoc/zen/lang/string.html (There are some API thoughts/notes in the class file which don't appear in the Javadoc header.) java.lang.String is final, which precludes subclassing to enhance away its deficiencies. Notwithstanding, String's deficiencies ought be fixed, at least over the longer term (e.g. it might depend on a not fully backwards compatible version of Java, in the longest term vision, wrapper in the short term etc). Regards Zenaan ---------- Forwarded message ---------- From: Zenaan Harkness Date: Thu, 15 Oct 2015 22:30:15 +0000 Subject: Re: [Yaml-core] encoding and content in YML files To: yaml-core at lists.sourceforge.net Cc: jose isaias cabrera On 10/15/15, Oren Ben-Kiki wrote: [Oren is responding to a new user's confusion around "the actual characters vs. the Unicode code points" to be represented in a text file] > Doesn't work that way :-) > > "Code point" is a "platonic ideal". \u1234, UTF8, UTF16LE, UTF16BE, > UTF32LE, UTF32BE, etc. are all different ways to encode it. > > Think of the number three. You can't put the number three into a file. You > can put the byte 0b00000011 into a file, encoding it as a 1-byte integer > (uint8_t). Or you can write the ascii string 't' 'h' 'r' 'e' 'e' into a > file. You you could put the ascii character '3' into a file. Or any of a > zillion other ways. All these are _encodings_. The number 3 itself is > neither of them. It is a platonic ideal (the successor of the successor of > the successor of the zero element, if you go by Peano's axioms - and the > previous sentence is yet another "encoding"). > > A "code point" is like that. You can only put an _encoding_ of a code point > into a file. Very well described. Thank you Oren. Here is a little project, with some Javadoc describing Java's Unicode limitations, for those working in Java: http://zenaan.github.io/zen/javadoc/zen/lang/string.html I haven't touched this since May, and may well not for another year or two by the looks of it. Still, the Javadoc may be useful for those trying to wrap their heads around all things Unicode, and also, and in particular, with respect to Java programming. It certainly did my head in, a few times. Here was my original post to stringtemplate-discussion mailing list, "a coder's lament on the paucity of java.lang.String functionality": https://groups.google.com/forum/?_escaped_fragment_=msg/stringtemplate-discussion/jJ_gZrF8SKg/ir_cuPRx1JsJ#!msg/stringtemplate-discussion/jJ_gZrF8SKg/ir_cuPRx1JsJ I also posted that email to a semi-private google group, and we engaged in a substantial discussion, which may be useful to those who still are struggling after reading the Javadoc posted above - if so, I am willing to repost the key exchanges here (with emails/names redacted) - just ask. Regards Zenaan From sebastian.sickelmann at gmx.de Tue Dec 15 20:05:22 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 15 Dec 2015 21:05:22 +0100 Subject: Compatible Field Resolution (Now inside jlink) In-Reply-To: <56632EA3.9040607@gmx.de> References: <565AEB85.7020105@gmx.de> <33F75FAA-1BE7-470E-9629-4C78B7AF9B77@oracle.com> <565D9D73.3000206@gmx.de> <56632EA3.9040607@gmx.de> Message-ID: <56707282.60403@gmx.de> 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) > > 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 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 From sebastian.sickelmann at gmx.de Tue Dec 15 20:09:53 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 15 Dec 2015 21:09:53 +0100 Subject: Compatible Field Resolution (Now inside jlink) In-Reply-To: <56707282.60403@gmx.de> References: <565AEB85.7020105@gmx.de> <33F75FAA-1BE7-470E-9629-4C78B7AF9B77@oracle.com> <565D9D73.3000206@gmx.de> <56632EA3.9040607@gmx.de> <56707282.60403@gmx.de> Message-ID: <56707391.5050709@gmx.de> 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) >> >> 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 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 > From zen at freedbms.net Mon Dec 21 11:39:23 2015 From: zen at freedbms.net (Zenaan Harkness) Date: Mon, 21 Dec 2015 11:39:23 +0000 Subject: RFC for future/ enhancement of java.lang.String - was Fwd: [Yaml-core] encoding and content in YML files In-Reply-To: References: Message-ID: I recently discovered that Apple's Swift programming language handles this very nicely - Character instances are actually "grapheme clusters" - this is how it should be. Perl 6 seems to be heading in the direction of grapheme competency too. I updated the Javadoc to mention and link to these, and added lots of internal hyperlinks to Unicode glossary and other links too. Regards, Zenaan On 12/12/15, Zenaan Harkness wrote: > java.lang.String is deficient. It does not provide a way to lay out a > random "string" of Unicode characters ("graphemes" or "characters as > the user perceives them"), e.g. to center or right-align such a > "string" of "characters" in a text console. ... > https://zenaan.github.io/zen/javadoc/zen/lang/string.html From sebastian.sickelmann at gmx.de Tue Dec 22 05:44:31 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Tue, 22 Dec 2015 06:44:31 +0100 Subject: Compatible Field Resolution (status update of the experiments) Message-ID: <5678E33F.6060509@gmx.de> Hi, i a previous thread I wrote about a prototype for reducing the accessibility of static and non-static fields without breaking binary compatibility. You can read about the details in following thread: http://markmail.org/message/nrbu4tgmj3x3yolf Now I want to send an update of what i achieved so far, and what you are able to try (if you like). There is a prototype of jlink which does replacement of the get/putfield and get/putstatic if the field is not declared at the target or its hierarchy. You can find the Prototype here: http://cr.openjdk.java.net/~sebastian/cfa/jlink/webrev.00/ with some description about it here: http://markmail.org/message/7glllofh567bd4zt There is a prototype for the zero- and the template-interpreter but only for the getfield and getstatic bytecodes (no puts so far). You can find the Prototype here: http://cr.openjdk.java.net/~sebastian/cfa/zero_and_template_interp/ and some information about building the zero-interpreter here: http://markmail.org/message/b3pucyo26uilo3vd While experimenting with the template-interpreter, i found the Rewriter and that it is called from InstanceKlass linkage. This sounds really promissing, and so it will be my next experiment. After that i want to collect some performance data about these experiments. Any feedback is highly appreciated -- Sebastian