From ivan at azulsystems.com Wed Nov 4 16:31:16 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Wed, 4 Nov 2015 16:31:16 +0000 Subject: CFV: New Project: aarch32 port In-Reply-To: <1446564054.21384.31.camel@mylittlepony.linaroharston> References: <1446564054.21384.31.camel@mylittlepony.linaroharston> Message-ID: <30CF9369-F0DB-4E99-8A51-7511BB8609F7@azulsystems.com> Vote: yes > On 3 Nov 2015, at 18:20, Edward Nevill wrote: > > I hereby propose the creation of the "aarch32 port" Project with myself, > Edward Nevill as the Lead and the Porters Group as the sponsoring group. > > The goal of the project will be to provide a full featured port of > OpenJDK on the Linux/aarch32 platform. aarch32 is the 32 bit > sub-architecture within the ARMv8 architecture. The port will be fully > compatible with ARMv7 and may support ARMv6 depending on community > interest. > > We (Linaro) already have a working template interpreter and a CR of this > based on JDK 9/hs-comp has been pushed as a webrev to > cr.openjdk.java.net. > > http://cr.openjdk.java.net/~enevill/8139303/webrev.hotspot/ > http://cr.openjdk.java.net/~enevill/8139303/webrev.hs-comp/ > http://cr.openjdk.java.net/~enevill/8139303/webrev.jdk/ > > It is intended that once the port is complete it will be integrated into > the main OpenJDK branch. > > Edward Nevill has been working with the ARM architecture since 1989 and > with the JDK since 1996. He is author of the ARM assembler interpreter > and the ARM microJIT. He has been working on OpenJDK for aarch64 for the > past 2.5 years and is a JDK 9 committer. > > The proposed initial set of committers is > > Edward Nevill > Andrew Haley > Andrew Dinn > Joseph Joyce > > Votes are due by Tue Nov 15 15:20 GMT 2015 > > Only current OpenJDK Members [1] are eligible to vote on this > motion. Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Edward Nevill > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote > > From omajid at redhat.com Wed Nov 4 18:44:59 2015 From: omajid at redhat.com (Omair Majid) Date: Wed, 4 Nov 2015 13:44:59 -0500 Subject: CFV: New Project: aarch32 port In-Reply-To: <1446564054.21384.31.camel@mylittlepony.linaroharston> References: <1446564054.21384.31.camel@mylittlepony.linaroharston> Message-ID: <20151104184458.GB2708@redhat.com> Vote: Yes * Edward Nevill [2015-11-03 11:56]: > I hereby propose the creation of the "aarch32 port" Project with myself, > Edward Nevill as the Lead and the Porters Group as the sponsoring group. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From ivan at azulsystems.com Thu Nov 5 06:34:11 2015 From: ivan at azulsystems.com (Ivan Krylov) Date: Thu, 5 Nov 2015 09:34:11 +0300 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: References: Message-ID: <563AF863.1090409@azulsystems.com> Vote: yes Thanks, Ivan On 26/09/2015 01:34, Bob Vandette wrote: > I hereby propose the creation of the Mobile Project with myself > (Bob Vandette) as the initial Project Lead and the Porters Group as > the sponsoring Group. > > The Mobile Project will focus on porting the JDK to popular mobile > platforms such as iOS, Android, and Windows Mobile. Oracle plans > on contributing build system, Hotspot and JDK source changes required > to target mobile platforms including the ability to produce static > Java runtimes and modifications to the Zero interpreter required > for iOS ARM devices. > > I have been working on Java for over 15 years, focusing on Java SE > Embedded and mobile platforms for the last 9 years. > > The initial Reviewers will include all current Reviewers in the JDK 9 > Project plus Gary Adams and Bertrand Delsart, who have in the past > contributed significantly to Oracle's embedded Java products. The > initial Committers will be the current set of Committers to the JDK 9 > Project. > > Votes are due by 9:00 UTC on Monday 12, October 2015 > > Only current OpenJDK Members [1] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Bob Vandette > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote From aph at redhat.com Thu Nov 5 10:01:47 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 5 Nov 2015 10:01:47 +0000 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> Message-ID: <563B290B.6040703@redhat.com> On 29/09/15 18:18, Bob Vandette wrote: > 3. iOS x64 and arm64 (arm64 will be provided via Zero interpreter) Why use Zero? Andrew. From roman at kennke.org Thu Nov 5 11:27:52 2015 From: roman at kennke.org (Roman Kennke) Date: Thu, 05 Nov 2015 12:27:52 +0100 Subject: CFV: New Project: aarch32 port In-Reply-To: <1446564054.21384.31.camel@mylittlepony.linaroharston> References: <1446564054.21384.31.camel@mylittlepony.linaroharston> Message-ID: <1446722872.3171.20.camel@kennke.org> Vote: yes Roman Am Dienstag, den 03.11.2015, 15:20 +0000 schrieb Edward Nevill: > I hereby propose the creation of the "aarch32 port" Project with > myself, > Edward Nevill as the Lead and the Porters Group as the sponsoring > group. > > The goal of the project will be to provide a full featured port of > OpenJDK on the Linux/aarch32 platform. aarch32 is the 32 bit > sub-architecture within the ARMv8 architecture. The port will be > fully > compatible with ARMv7 and may support ARMv6 depending on community > interest. > > We (Linaro) already have a working template interpreter and a CR of > this > based on JDK 9/hs-comp has been pushed as a webrev to > cr.openjdk.java.net. > > http://cr.openjdk.java.net/~enevill/8139303/webrev.hotspot/ > http://cr.openjdk.java.net/~enevill/8139303/webrev.hs-comp/ > http://cr.openjdk.java.net/~enevill/8139303/webrev.jdk/ > > It is intended that once the port is complete it will be integrated > into > the main OpenJDK branch. > > Edward Nevill has been working with the ARM architecture since 1989 > and > with the JDK since 1996. He is author of the ARM assembler > interpreter > and the ARM microJIT. He has been working on OpenJDK for aarch64 for > the > past 2.5 years and is a JDK 9 committer. > > The proposed initial set of committers is > > Edward Nevill > Andrew Haley > Andrew Dinn > Joseph Joyce > > Votes are due by Tue Nov 15 15:20 GMT 2015 > > Only current OpenJDK Members [1] are eligible to vote on this > motion.??Votes must be cast in the open by replying to to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Edward Nevill > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote > > > From roman at kennke.org Thu Nov 5 11:28:50 2015 From: roman at kennke.org (Roman Kennke) Date: Thu, 05 Nov 2015 12:28:50 +0100 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: References: Message-ID: <1446722930.3171.21.camel@kennke.org> Vote: yes Roman Am Freitag, den 25.09.2015, 18:34 -0400 schrieb Bob Vandette: > I hereby propose the creation of the Mobile Project with myself > (Bob Vandette) as the initial Project Lead and the Porters Group as > the sponsoring Group. > > The Mobile Project will focus on porting the JDK to popular mobile > platforms such as iOS, Android, and Windows Mobile.??Oracle plans > on contributing build system, Hotspot and JDK source changes required > to target mobile platforms including the ability to produce static > Java runtimes and modifications to the Zero interpreter required > for iOS ARM devices. > > I have been working on Java for over 15 years, focusing on Java SE > Embedded and mobile platforms for the last 9 years. > > The initial Reviewers will include all current Reviewers in the JDK 9 > Project plus Gary Adams and Bertrand Delsart, who have in the past > contributed significantly to Oracle's embedded Java products.??The > initial Committers will be the current set of Committers to the JDK 9 > Project. > > Votes are due by 9:00 UTC on Monday 12, October 2015 > > Only current OpenJDK Members [1] are eligible to vote on this > motion.??Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [2]. > > Best regards, > Bob Vandette > > [1] http://openjdk.java.net/census#members ensus#members> > [2] http://openjdk.java.net/projects/#new-project-vote k.java.net/projects/#new-project-vote> From bob.vandette at oracle.com Thu Nov 5 13:25:04 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 5 Nov 2015 08:25:04 -0500 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <563B290B.6040703@redhat.com> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> Message-ID: <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> > On Nov 5, 2015, at 5:01 AM, Andrew Haley wrote: > > On 29/09/15 18:18, Bob Vandette wrote: >> 3. iOS x64 and arm64 (arm64 will be provided via Zero interpreter) > > Why use Zero? As you probably know, iOS does not allow dynamic code generation on ARM based devices (iPhone, iPad, etc). This eliminates the possibility of using the Hotspot JIT (Just-in-time compiler) but since the Hotspot template interpreter is also dynamically generated, we can?t use that form of the interpreter. We have enhanced our closed ARM ports to statically generate the interpreter for iOS but since these sources are not available in the open source forest, we?ll use Zero initially to provide a working solution for the Mobile project. I welcome the maintainers of the open aarch64 port to enhance that port to enable static code generation of your interpreter so that we won?t have to use Zero. The shared code changes required for static code generation has already been integrated into the JDK9 master sources. Bob. > > Andrew. > From Fabrizio.Giudici at tidalwave.it Thu Nov 5 13:54:24 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 05 Nov 2015 14:54:24 +0100 Subject: Question about the scope of this mailing list Message-ID: Hi. Is it appropriate to post here questions about why a certain Java API (e.g. in Java8, Streams, etc...) has been made in a way instead of another? -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From martijnverburg at gmail.com Thu Nov 5 13:56:43 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 5 Nov 2015 13:56:43 +0000 Subject: Question about the scope of this mailing list In-Reply-To: References: Message-ID: Hi Fabrizio, Those sorts of questions should go to core-libs. Cheers, Martijn On 5 November 2015 at 13:54, Fabrizio Giudici wrote: > Hi. > > Is it appropriate to post here questions about why a certain Java API > (e.g. in Java8, Streams, etc...) has been made in a way instead of another? > > -- > Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. > "We make Java work. Everywhere." > http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it > From aph at redhat.com Thu Nov 5 14:50:03 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 5 Nov 2015 14:50:03 +0000 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> Message-ID: <563B6C9B.4070900@redhat.com> On 11/05/2015 01:25 PM, Bob Vandette wrote: > >> On Nov 5, 2015, at 5:01 AM, Andrew Haley wrote: >> >> On 29/09/15 18:18, Bob Vandette wrote: >>> 3. iOS x64 and arm64 (arm64 will be provided via Zero interpreter) >> >> Why use Zero? > > As you probably know, iOS does not allow dynamic code generation on > ARM based devices (iPhone, iPad, etc). Aha! I think I knew, but had forgotten... > This eliminates the possibility of using the Hotspot JIT (Just-in- > time compiler) but since the Hotspot template interpreter is also > dynamically generated, we can?t use that form of the interpreter. > We have enhanced our closed ARM ports to statically generate the > interpreter for iOS but since these sources are not available in the > open source forest, we?ll use Zero initially to provide a working > solution for the Mobile project. I welcome the maintainers of the > open aarch64 port to enhance that port to enable static code > generation of your interpreter so that we won?t have to use Zero. > The shared code changes required for static code generation has > already been integrated into the JDK9 master sources. OK, thanks. It's definitely worth us having a look at that. Andrew. From bob.vandette at oracle.com Thu Nov 5 15:49:30 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 5 Nov 2015 10:49:30 -0500 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <563AF863.1090409@azulsystems.com> References: <563AF863.1090409@azulsystems.com> Message-ID: Thanks Ivan and Roman. The CFV deadline has passed and the project has been approved. We?re in the process of setting of the Mobile project. I hope to have it live shortly. Bob. > On Nov 5, 2015, at 1:34 AM, Ivan Krylov wrote: > > Vote: yes > > Thanks, > Ivan > > On 26/09/2015 01:34, Bob Vandette wrote: >> I hereby propose the creation of the Mobile Project with myself >> (Bob Vandette) as the initial Project Lead and the Porters Group as >> the sponsoring Group. >> >> The Mobile Project will focus on porting the JDK to popular mobile >> platforms such as iOS, Android, and Windows Mobile. Oracle plans >> on contributing build system, Hotspot and JDK source changes required >> to target mobile platforms including the ability to produce static >> Java runtimes and modifications to the Zero interpreter required >> for iOS ARM devices. >> >> I have been working on Java for over 15 years, focusing on Java SE >> Embedded and mobile platforms for the last 9 years. >> >> The initial Reviewers will include all current Reviewers in the JDK 9 >> Project plus Gary Adams and Bertrand Delsart, who have in the past >> contributed significantly to Oracle's embedded Java products. The >> initial Committers will be the current set of Committers to the JDK 9 >> Project. >> >> Votes are due by 9:00 UTC on Monday 12, October 2015 >> >> Only current OpenJDK Members [1] are eligible to vote on this >> motion. Votes must be cast in the open on the discuss list. >> Replying to this message is sufficient if your mail program >> honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Best regards, >> Bob Vandette >> >> [1] http://openjdk.java.net/census#members >> [2] http://openjdk.java.net/projects/#new-project-vote > From Fabrizio.Giudici at tidalwave.it Thu Nov 5 16:47:02 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 05 Nov 2015 17:47:02 +0100 Subject: Question about the scope of this mailing list In-Reply-To: References: Message-ID: On Thu, 05 Nov 2015 14:56:43 +0100, Martijn Verburg wrote: > Hi Fabrizio, > > Those sorts of questions should go to core-libs. Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From omajid at redhat.com Thu Nov 5 21:05:34 2015 From: omajid at redhat.com (Omair Majid) Date: Thu, 5 Nov 2015 16:05:34 -0500 Subject: Contributing fixes to documentation Message-ID: <20151105210534.GB4236@redhat.com> Hi, I occasionally run into bug reports for OpenJDK where someone spots an error in the man pages. And I can't fix them and contribute the fix upstream. If this was an error in the source code, I would create patch and post it for review and push it to OpenJDK. And maybe do a backport. But since the error is in the man pages - which I have been told are generated - I can't do much about the fix. And I see a few bug reports similar to this every year (such as [1] and [2]). All I have been able to do is file bugs and let someone else put in the work to fix the issue. Is there any chance that contributors can directly fix the various forms of documentation included in OpenJDK? I spoke to Mark Reinhold about this once and he suggested that it might be possible to include the master sources into OpenJDK and generate the various types of documentation (including man pages and html pages from that). Is that something that could be implemented? I am willing to help with that. Thanks, Omair [1] https://bugzilla.redhat.com/show_bug.cgi?id=1132227 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1095307 -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From edward.nevill at gmail.com Tue Nov 10 10:42:47 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 10 Nov 2015 10:42:47 +0000 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <563B6C9B.4070900@redhat.com> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> <563B6C9B.4070900@redhat.com> Message-ID: <1447152167.14377.24.camel@mylittlepony.linaroharston> On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote: > On 11/05/2015 01:25 PM, Bob Vandette wrote: > > This eliminates the possibility of using the Hotspot JIT (Just-in- > > time compiler) but since the Hotspot template interpreter is also > > dynamically generated, we can?t use that form of the interpreter. > > We have enhanced our closed ARM ports to statically generate the > > interpreter for iOS but since these sources are not available in the > > open source forest, we?ll use Zero initially to provide a working > > solution for the Mobile project. I welcome the maintainers of the > > open aarch64 port to enhance that port to enable static code > > generation of your interpreter so that we won?t have to use Zero. > > The shared code changes required for static code generation has > > already been integrated into the JDK9 master sources. > > OK, thanks. It's definitely worth us having a look at that. One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to compile to some intermediate representation which would be more amenable to interpretation. I am thinking of an intermediate representation where each opcode/operand pair is 128 bits and the dispatch code is simply. ldp Ropcode, Roperand, [Rpc], #16 br Ropcode IE. The opecode is simply the address of a static routine to handle that opcode. So, for example you code fold the sequence iload N iload M iadd istore O to a single opcode &iadd_three_op where and are encoded in the 2nd 64 bit word. If you further allowed for some simple register allocation (as per the ARM microJIT) with 4 registers assigned to the top 4 stack locations and 4 registers assigned to 4 locals (probably, but not necessarily local_0 to local_3) then the above sequence could be reduced to &iadd_O_M_N IE there would be a dedicated opcode for oadd O, M, N which simply does mov Ropcode, Roperand ; no operand, so operand becomes next opcode ldr Roperand, [Rpc], #8 add RO, RM, RN ; do the op br Ropcode I think it would be possible to get quite good performance using this technique, especially if you could statically compile longer code sequences based on profiling information. All the best, Ed. From aph at redhat.com Tue Nov 10 18:28:17 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Nov 2015 18:28:17 +0000 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <1447152167.14377.24.camel@mylittlepony.linaroharston> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> <563B6C9B.4070900@redhat.com> <1447152167.14377.24.camel@mylittlepony.linaroharston> Message-ID: <56423741.3090104@redhat.com> On 10/11/15 10:42, Edward Nevill wrote: > On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote: >> On 11/05/2015 01:25 PM, Bob Vandette wrote: >>> This eliminates the possibility of using the Hotspot JIT (Just-in- >>> time compiler) but since the Hotspot template interpreter is also >>> dynamically generated, we can?t use that form of the interpreter. >>> We have enhanced our closed ARM ports to statically generate the >>> interpreter for iOS but since these sources are not available in the >>> open source forest, we?ll use Zero initially to provide a working >>> solution for the Mobile project. I welcome the maintainers of the >>> open aarch64 port to enhance that port to enable static code >>> generation of your interpreter so that we won?t have to use Zero. >>> The shared code changes required for static code generation has >>> already been integrated into the JDK9 master sources. >> >> OK, thanks. It's definitely worth us having a look at that. > > One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to > compile to some intermediate representation which would be more amenable > to interpretation. > > I am thinking of an intermediate representation where each > opcode/operand pair is 128 bits and the dispatch code is simply. > > ldp Ropcode, Roperand, [Rpc], #16 > br Ropcode > > IE. The opecode is simply the address of a static routine to handle that > opcode. i.e. direct threaded code. > I think it would be possible to get quite good performance using this > technique, especially if you could statically compile longer code > sequences based on profiling information. Maybe, but I suspect it would be easier to write a JIT (C1 or C2) back-end for this machine. I expect that the real problem performance-wise would be that you'd blow out the Dcache. Andrew. From bob.vandette at oracle.com Tue Nov 10 20:35:14 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 10 Nov 2015 15:35:14 -0500 Subject: CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <1447152167.14377.24.camel@mylittlepony.linaroharston> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> <563B6C9B.4070900@redhat.com> <1447152167.14377.24.camel@mylittlepony.linaroharston> Message-ID: > On Nov 10, 2015, at 5:42 AM, Edward Nevill wrote: > > On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote: >> On 11/05/2015 01:25 PM, Bob Vandette wrote: >>> This eliminates the possibility of using the Hotspot JIT (Just-in- >>> time compiler) but since the Hotspot template interpreter is also >>> dynamically generated, we can?t use that form of the interpreter. >>> We have enhanced our closed ARM ports to statically generate the >>> interpreter for iOS but since these sources are not available in the >>> open source forest, we?ll use Zero initially to provide a working >>> solution for the Mobile project. I welcome the maintainers of the >>> open aarch64 port to enhance that port to enable static code >>> generation of your interpreter so that we won?t have to use Zero. >>> The shared code changes required for static code generation has >>> already been integrated into the JDK9 master sources. >> >> OK, thanks. It's definitely worth us having a look at that. This sounds a bit like RewriteByteCodes and RewriteFrequentParis taken to the extreem. This would be a useful general Hotspot enhancement if it weren?t for the fact that interpreter performance matters less and less each day. With TieredCompilation and the our eventual AOT implementation, we?ll be spending less time interpreting. As a performance improvement for iOS it might be worth doing on it?s own but if we were to implement something like this, why not go straight to Ahead-of-time compilation that leverages existing JITs. You have to be careful what you compile but you can get a nice performance improvement with very little code generation. Bob. > > One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to > compile to some intermediate representation which would be more amenable > to interpretation. > > I am thinking of an intermediate representation where each > opcode/operand pair is 128 bits and the dispatch code is simply. > > ldp Ropcode, Roperand, [Rpc], #16 > br Ropcode > > IE. The opecode is simply the address of a static routine to handle that > opcode. > > So, for example you code fold the sequence > > iload N > iload M > iadd > istore O > > to a single opcode > > &iadd_three_op > > where and are encoded in the 2nd 64 bit word. > > If you further allowed for some simple register allocation (as per the > ARM microJIT) with 4 registers assigned to the top 4 stack locations and > 4 registers assigned to 4 locals (probably, but not necessarily local_0 > to local_3) then the above sequence could be reduced to > > &iadd_O_M_N > > IE there would be a dedicated opcode for oadd O, M, N which simply does > > mov Ropcode, Roperand ; no operand, so operand becomes next opcode > ldr Roperand, [Rpc], #8 > add RO, RM, RN ; do the op > br Ropcode > > I think it would be possible to get quite good performance using this > technique, especially if you could statically compile longer code > sequences based on profiling information. > > All the best, > Ed. > > From dalibor.topic at oracle.com Fri Nov 13 13:01:11 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 13 Nov 2015 14:01:11 +0100 Subject: CFV: New Project: aarch32 port In-Reply-To: <1446722872.3171.20.camel@kennke.org> References: <1446564054.21384.31.camel@mylittlepony.linaroharston> <1446722872.3171.20.camel@kennke.org> Message-ID: <5645DF17.7040409@oracle.com> Vote: Yes. The OpenJDK Porters Group is a sponsor of this Project. cheers, dalibor topic, OpenJDK Porters Group Lead -- 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 neugens.limasoftware at gmail.com Fri Nov 27 12:49:59 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 27 Nov 2015 13:49:59 +0100 Subject: Fosdem Java DevRoom CFP deadline extended Message-ID: Hi all! I have extended the deadline for proposal submission: https://lists.fosdem.org/pipermail/java-devroom/2015-November/000142.html - Here the original announcement: https://lists.fosdem.org/pipermail/java-devroom/2015-October/000136.html I hope to see more papers flowing! Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From sebastian.sickelmann at gmx.de Sun Nov 29 12:11:49 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Sun, 29 Nov 2015 13:11:49 +0100 Subject: Compatible Field Resolution Message-ID: <565AEB85.7020105@gmx.de> 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 brian.goetz at oracle.com Sun Nov 29 16:08:54 2015 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 29 Nov 2015 11:08:54 -0500 Subject: Compatible Field Resolution In-Reply-To: <565AEB85.7020105@gmx.de> References: <565AEB85.7020105@gmx.de> Message-ID: <33F75FAA-1BE7-470E-9629-4C78B7AF9B77@oracle.com> 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 alex.buckley at oracle.com Mon Nov 30 19:42:07 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 30 Nov 2015 11:42:07 -0800 Subject: Compatible Field Resolution In-Reply-To: <565AEB85.7020105@gmx.de> References: <565AEB85.7020105@gmx.de> Message-ID: <565CA68F.4040809@oracle.com> You mean accessibility, not visibility. The difference is significant; see "Project Jigsaw: Under The Hood" from JavaOne for more. You are right that the model of accessibility used by the Java language and the JVM is also used by the Core Reflection API (including j.l.r.Proxy), the MethodHandle API, and the Language Model API. Alex On 11/29/2015 4: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 Mon Nov 30 20:23:48 2015 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 30 Nov 2015 21:23:48 +0100 Subject: Compatible Field Resolution In-Reply-To: <565CA68F.4040809@oracle.com> Message-ID: <9e2d6f82-7c4d-4b99-9769-5280145ca470@email.android.com> Thanks for clarification. This is an interesting translation error. In most german text about accessibility the german word for visibility is used. Even for other programming languages with strong encapsulation. Thanks for mentioning MethodHandles which I forget to list in my questions below and the language model API which I would have missed completly. -- Sebastian Am 30.11.2015 8:42 nachm. schrieb Alex Buckley : > > You mean accessibility, not visibility. The difference is significant; > see "Project Jigsaw: Under The Hood" from JavaOne for more. > > You are right that the model of accessibility used by the Java language > and the JVM is also used by the Core Reflection API (including > j.l.r.Proxy), the MethodHandle API, and the Language Model API. > > Alex > > On 11/29/2015 4: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 alex.buckley at oracle.com Mon Nov 30 20:46:21 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 30 Nov 2015 12:46:21 -0800 Subject: Compatible Field Resolution In-Reply-To: <9e2d6f82-7c4d-4b99-9769-5280145ca470@email.android.com> References: <9e2d6f82-7c4d-4b99-9769-5280145ca470@email.android.com> Message-ID: <565CB59D.6060408@oracle.com> The translation issue is interesting to know. The terminology is important because "visibility" (i.e. what a class loader allows its defined classes to "see" in other class loaders) is solely a run time concept, whereas "accessibility" is both compile time and run time. (As is "readability", the module dependency model which now underpins accessibility.) Alex On 11/30/2015 12:23 PM, Sebastian Sickelmann wrote: > Thanks for clarification. This is an interesting translation error. In most german text about accessibility the german word for visibility is used. Even for other programming languages with strong encapsulation. > > Thanks for mentioning MethodHandles which I forget to list in my questions below and the language model API which I would have missed completly. > > -- > Sebastian > > Am 30.11.2015 8:42 nachm. schrieb Alex Buckley : >> >> You mean accessibility, not visibility. The difference is significant; >> see "Project Jigsaw: Under The Hood" from JavaOne for more. >> >> You are right that the model of accessibility used by the Java language >> and the JVM is also used by the Core Reflection API (including >> j.l.r.Proxy), the MethodHandle API, and the Language Model API. >> >> Alex >> >> On 11/29/2015 4: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 >>>