From nagappan at gmail.com Fri Aug 3 00:59:57 2012 From: nagappan at gmail.com (Nagappan Alagappan) Date: Thu, 2 Aug 2012 17:59:57 -0700 Subject: Announce: Cobra 2.0 - Windows GUI test automation tool Message-ID: Hello, Highlights * Java / C# / VB.NET / PowerShell / Ruby are now officially supported LDTP scripting languages other than Python * Approximately 130 APIs are compatible with Linux version of LDTP * C# client is compatible with Mono .NET framework and we have tested it on Linux/Mac * Identify object name based on automation id (window id, as per SilkTest users) * i18n support * CPU / Memory logging * Remote test execution New features: * List / Tree item API's are added * Scroll to the element if the respective pattern is enabled * Added new characters in keyboard input * Object lookup based on wildcard("?") * Double click on allowed object's * Added hyper link widget type under known objects New APIs: * getwindowsize * simulatemousemove * gettablerowindex * getobjectnameatcoords * onwindowcreate (Java/C# client) * removecallback (Java/C# client) * mouserightclick Bug fixes: * Taskbar is now identified as pane, rather than ukn * generatemouseevent API now takes the optional argument, compatible with Linux * Fixed a crash, if the window title has back slash * Grabing focus on combobox element fails the object selection, removed the respective code * Ignore special characters while searching object name * Fix regexp in object lookup * getcellvalue API now takes the optional argument, compatible with Linux * Handle task manager menuitem, which worked slightly different than other menu * Fixed listing sub-menus with a simplified method * getcellvalue API now as the Linux version * getchild API now returns appropriate output * Fixed *window APIs to work with different types of window * Fixed mouse left click on a text widget Credit: * John Yingjun Li (VMware) have contributed most of the code in this release. I really appreciate all his effort * VMware colleagues * Thanks to all others who have reported bugs through forum / email / in-person / IRC Please spread the word and also share your feedback with us. About LDTP: Cross Platform GUI Automation tool Linux version is LDTP, Windows version is Cobra and Mac version is PyATOM (Work in progress). * Linux version is known to work on GNOME / KDE (QT >= 4.8) / Java Swing / LibreOffice / Mozilla application on all major Linux distribution. * Windows version is known to work on application written in .NET / C++ / Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version. * Mac version is currently under development and verified only on OS X Lion. Where ever PyATOM runs, LDTP should work on it. Download source: https://github.com/ldtp/cobra Download binary (Windows XP / Windows 7 / Windows 8): http://download.freedesktop.org/ldtp/cobra-latest/ System requirement: .NET 3.5, refer README.txt after installation Documentation references: For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org For information on various APIs in LDTP including those added for this release can be got from http://ldtp.freedesktop.org/user-doc/index.html Java doc - http://ldtp.freedesktop.org/javadoc/ Report bugs - http://ldtp.freedesktop.org/wiki/Bugs To subscribe to LDTP mailing lists, visit http://ldtp.freedesktop.org/wiki/Mailing_20list IRC Channel - #ldtp on irc.freenode.net Thanks Nagappan -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org Cobra - Windows GUI Automation tool - https://github.com/ldtp/cobra http://nagappanal.blogspot.com From the.6th.month at gmail.com Fri Aug 3 04:04:34 2012 From: the.6th.month at gmail.com (the.6th.month at gmail.com) Date: Fri, 3 Aug 2012 12:04:34 +0800 Subject: jvm core dump with libnet.so Message-ID: hi, all: We just encountered core dumps with our java process several times in recent hours, and we've collected two core dump files and made a brief analysis with gdb. According to the backtrace, both core dumps seem to be resulted from libnet.so. The backtrace info is pasted as follows: core dump 1 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff497d6000 Core was generated by `/home/q/java/jdk1.6.0_26/bin/java -Djava.util.logging.config.file=/home/q/www/t'. Program terminated with signal 11, Segmentation fault. #0 0x00000030b160de70 in send () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000030b160de70 in send () from /lib64/libpthread.so.0 #1 0x00002aaab8e88843 in NET_Send () from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so #2 0x00002aaab8e85666 in Java_java_net_SocketOutputStream_socketWrite0 () from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so core dump 2 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff979fc000 Core was generated by `/home/q/java/jdk1.6.0_26/bin/java -Djava.util.logging.config.file=/home/q/www/t'. Program terminated with signal 11, Segmentation fault. #0 0x00000030b0e8c42b in gettimeofday () from /lib64/libc.so.6 (gdb) bt #0 0x00000030b0e8c42b in gettimeofday () from /lib64/libc.so.6 #1 0x00002aaab8b4bd42 in NET_Timeout () from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.soCentOS release 5.6 (Final #2 0x00002aaab8b483c5 in Java_java_net_SocketInputStream_socketRead0 () from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so Our program is running with hotspot jdk 6u26, and the JAVA_OPTS is as below: -XX:+PrintGCDetails -Xss256k -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:/home/q/www/travelco/logs/gc.log-server -Xms5120m -Xmx5120m -Xmn1536m -XX:PermSize=256m -server -Dfile.encoding=UTF-8 The OS is CentOS release 5.6 (Final), and the whole system is running on a physical machine with 24 cores and 8 gigabytes memory. We encountered almost the same problem a year ago, and we solved the problem by simply changed from hotspot jdk to openjdk. It sounds quite weird to me, and I am keen to know what the reason is for this situation. Does anyone have any idea about that? Any help would be truly appreciated. Thanks very much. All the best, Leon From the.6th.month at gmail.com Fri Aug 3 08:45:41 2012 From: the.6th.month at gmail.com (the.6th.month at gmail.com) Date: Fri, 3 Aug 2012 16:45:41 +0800 Subject: jvm core dump with libnet.so In-Reply-To: <501B8E65.2080905@redhat.com> References: <501B8E65.2080905@redhat.com> Message-ID: hi, Andrew; I am seeing it on two machines with exactly same configurations. It is sorta unpredictable. We are seeing it almost once an hour on both machines, and since I changed to openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)) for one machine, it hasn't crashed till now, and the other remains the same. Since I don't get any debug symbol, I can't get any clue what goes wrong there. On 3 August 2012 16:40, Andrew Haley wrote: > On 08/03/2012 05:04 AM, the.6th.month at gmail.com wrote: > > We encountered almost the same problem a year ago, and we solved the > > problem by simply changed from hotspot jdk to openjdk. > > It sounds quite weird to me, and I am keen to know what the reason is for > > this situation. Does anyone have any idea about that? Any help would be > > truly appreciated. > > Are you seeing this on more than one machine? Is it reproducible? > > Andrew. > > From aph at redhat.com Fri Aug 3 08:50:41 2012 From: aph at redhat.com (Andrew Haley) Date: Fri, 03 Aug 2012 09:50:41 +0100 Subject: jvm core dump with libnet.so In-Reply-To: References: <501B8E65.2080905@redhat.com> Message-ID: <501B90E1.5070609@redhat.com> On 08/03/2012 09:45 AM, the.6th.month at gmail.com wrote: > On 3 August 2012 16:40, Andrew Haley wrote: > >> On 08/03/2012 05:04 AM, the.6th.month at gmail.com wrote: >>> We encountered almost the same problem a year ago, and we solved the >>> problem by simply changed from hotspot jdk to openjdk. >>> It sounds quite weird to me, and I am keen to know what the reason is for >>> this situation. Does anyone have any idea about that? Any help would be >>> truly appreciated. >> >> Are you seeing this on more than one machine? Is it reproducible? >> > I am seeing it on two machines with exactly same configurations. It is > sorta unpredictable. We are seeing it almost once an hour on both machines, > and since I changed to openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM (build > 19.0-b09, mixed mode)) for one machine, it hasn't crashed till now, and the > other remains the same. > Since I don't get any debug symbol, I can't get any clue what goes wrong > there. So what are the two OpenJDK versions? The breaking, and the OK? Andrew. From the.6th.month at gmail.com Fri Aug 3 08:58:52 2012 From: the.6th.month at gmail.com (the.6th.month at gmail.com) Date: Fri, 3 Aug 2012 16:58:52 +0800 Subject: jvm core dump with libnet.so In-Reply-To: <501B90E1.5070609@redhat.com> References: <501B8E65.2080905@redhat.com> <501B90E1.5070609@redhat.com> Message-ID: the one crashes is running with hotspot 6u26 build 1.6.0_26-b03, not openjdk. the one seems to work is openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)) as I mentioned in previous letter. On 3 August 2012 16:50, Andrew Haley wrote: > On 08/03/2012 09:45 AM, the.6th.month at gmail.com wrote: > > On 3 August 2012 16:40, Andrew Haley wrote: > > > >> On 08/03/2012 05:04 AM, the.6th.month at gmail.com wrote: > >>> We encountered almost the same problem a year ago, and we solved the > >>> problem by simply changed from hotspot jdk to openjdk. > >>> It sounds quite weird to me, and I am keen to know what the reason is > for > >>> this situation. Does anyone have any idea about that? Any help would be > >>> truly appreciated. > >> > >> Are you seeing this on more than one machine? Is it reproducible? > >> > > I am seeing it on two machines with exactly same configurations. It is > > sorta unpredictable. We are seeing it almost once an hour on both > machines, > > and since I changed to openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM (build > > 19.0-b09, mixed mode)) for one machine, it hasn't crashed till now, and > the > > other remains the same. > > Since I don't get any debug symbol, I can't get any clue what goes wrong > > there. > > So what are the two OpenJDK versions? The breaking, and the OK? > > Andrew. > > From aph at redhat.com Fri Aug 3 08:40:05 2012 From: aph at redhat.com (Andrew Haley) Date: Fri, 03 Aug 2012 09:40:05 +0100 Subject: jvm core dump with libnet.so In-Reply-To: References: Message-ID: <501B8E65.2080905@redhat.com> On 08/03/2012 05:04 AM, the.6th.month at gmail.com wrote: > We encountered almost the same problem a year ago, and we solved the > problem by simply changed from hotspot jdk to openjdk. > It sounds quite weird to me, and I am keen to know what the reason is for > this situation. Does anyone have any idea about that? Any help would be > truly appreciated. Are you seeing this on more than one machine? Is it reproducible? Andrew. From ahughes at redhat.com Fri Aug 3 09:57:01 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 05:57:01 -0400 (EDT) Subject: jvm core dump with libnet.so In-Reply-To: Message-ID: <234103641.8077707.1343987821630.JavaMail.root@redhat.com> ----- Original Message ----- > the one crashes is running with hotspot 6u26 build 1.6.0_26-b03, not > openjdk. > the one seems to work is openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM > (build > 19.0-b09, mixed mode)) as I mentioned in previous letter. > So use OpenJDK, as it works. I'm not sure I see the problem here. You can report the u26 crash to bugs.sun.com, but as there are newer versions available, both of 6 and 7, I'd guess the initial remedy will just be to try one of those. There's nothing OpenJDK developers can do to debug proprietary code. > On 3 August 2012 16:50, Andrew Haley wrote: > > > On 08/03/2012 09:45 AM, the.6th.month at gmail.com wrote: > > > On 3 August 2012 16:40, Andrew Haley wrote: > > > > > >> On 08/03/2012 05:04 AM, the.6th.month at gmail.com wrote: > > >>> We encountered almost the same problem a year ago, and we > > >>> solved the > > >>> problem by simply changed from hotspot jdk to openjdk. > > >>> It sounds quite weird to me, and I am keen to know what the > > >>> reason is > > for > > >>> this situation. Does anyone have any idea about that? Any help > > >>> would be > > >>> truly appreciated. > > >> > > >> Are you seeing this on more than one machine? Is it > > >> reproducible? > > >> > > > I am seeing it on two machines with exactly same configurations. > > > It is > > > sorta unpredictable. We are seeing it almost once an hour on both > > machines, > > > and since I changed to openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM > > > (build > > > 19.0-b09, mixed mode)) for one machine, it hasn't crashed till > > > now, and > > the > > > other remains the same. > > > Since I don't get any debug symbol, I can't get any clue what > > > goes wrong > > > there. > > > > So what are the two OpenJDK versions? The breaking, and the OK? > > > > Andrew. > > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From the.6th.month at gmail.com Fri Aug 3 10:02:09 2012 From: the.6th.month at gmail.com (the.6th.month at gmail.com) Date: Fri, 3 Aug 2012 18:02:09 +0800 Subject: jvm core dump with libnet.so In-Reply-To: <234103641.8077707.1343987821630.JavaMail.root@redhat.com> References: <234103641.8077707.1343987821630.JavaMail.root@redhat.com> Message-ID: okay, fair enough, thank you, Andrew. We might go as well with openjdk. On 3 August 2012 17:57, Andrew Hughes wrote: > ----- Original Message ----- > > the one crashes is running with hotspot 6u26 build 1.6.0_26-b03, not > > openjdk. > > the one seems to work is openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM > > (build > > 19.0-b09, mixed mode)) as I mentioned in previous letter. > > > > So use OpenJDK, as it works. > > I'm not sure I see the problem here. > > You can report the u26 crash to bugs.sun.com, but as there are newer > versions available, both of 6 and 7, I'd guess the initial remedy will > just be to try one of those. > > There's nothing OpenJDK developers can do to debug proprietary code. > > > On 3 August 2012 16:50, Andrew Haley wrote: > > > > > On 08/03/2012 09:45 AM, the.6th.month at gmail.com wrote: > > > > On 3 August 2012 16:40, Andrew Haley wrote: > > > > > > > >> On 08/03/2012 05:04 AM, the.6th.month at gmail.com wrote: > > > >>> We encountered almost the same problem a year ago, and we > > > >>> solved the > > > >>> problem by simply changed from hotspot jdk to openjdk. > > > >>> It sounds quite weird to me, and I am keen to know what the > > > >>> reason is > > > for > > > >>> this situation. Does anyone have any idea about that? Any help > > > >>> would be > > > >>> truly appreciated. > > > >> > > > >> Are you seeing this on more than one machine? Is it > > > >> reproducible? > > > >> > > > > I am seeing it on two machines with exactly same configurations. > > > > It is > > > > sorta unpredictable. We are seeing it almost once an hour on both > > > machines, > > > > and since I changed to openjdk 1.6.0_20 (OpenJDK 64-Bit Server VM > > > > (build > > > > 19.0-b09, mixed mode)) for one machine, it hasn't crashed till > > > > now, and > > > the > > > > other remains the same. > > > > Since I don't get any debug symbol, I can't get any clue what > > > > goes wrong > > > > there. > > > > > > So what are the two OpenJDK versions? The breaking, and the OK? > > > > > > Andrew. > > > > > > > > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > From aph at redhat.com Fri Aug 3 12:26:16 2012 From: aph at redhat.com (Andrew Haley) Date: Fri, 03 Aug 2012 13:26:16 +0100 Subject: jvm core dump with libnet.so In-Reply-To: References: <234103641.8077707.1343987821630.JavaMail.root@redhat.com> Message-ID: <501BC368.1000700@redhat.com> On 08/03/2012 11:02 AM, the.6th.month at gmail.com wrote: > okay, fair enough, thank you, Andrew. > We might go as well with openjdk. The code bases for proprietary and 6 open are quite separate. While it's possible this is a JVM bug, it's far from certain. It might be that something elsewhere is triggering the problem. However, the proprietary VM is closed, so there is nothing that can happen outside Oracle to find the problem. Andrew. From Alan.Bateman at oracle.com Fri Aug 3 12:35:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Aug 2012 13:35:15 +0100 Subject: jvm core dump with libnet.so In-Reply-To: References: Message-ID: <501BC583.7090408@oracle.com> On 03/08/2012 05:04, the.6th.month at gmail.com wrote: > hi, all: > > We just encountered core dumps with our java process several times in > recent hours, and we've collected two core dump files and made a brief > analysis with gdb. According to the backtrace, both core dumps seem to be > resulted from libnet.so. This appears to be Oracle's 6u26 release which has different lineage to the OpenJDK jdk6 project. Joe Darcy has a useful blog on the genealogy [1] that may help explain this. Also 6u26 is quite very old, you may want to try something more recent. If for whatever reason this isn't possible then try running without -XX:+UseCompressedOops on the off-chance that this may be the problem you are running into. -Alan [1] https://blogs.oracle.com/darcy/entry/openjdk_6_genealogy From nagappan at gmail.com Fri Aug 3 19:09:08 2012 From: nagappan at gmail.com (Nagappan Alagappan) Date: Fri, 3 Aug 2012 12:09:08 -0700 Subject: Announce: LDTP 3.0 - Linux GUI test automation tool Message-ID: Hello, Highlights: * Java / C# / VB.NET / PowerShell / Ruby are now officially supported LDTP scripting languages other than Python New Features: * Firefox have check / uncheck as actions for check box New APIs: * selectpanel * selectpanelname * selectpanelindex Bug fix: * Simplified the implementation verifyselect for combobox menuitem * Fix QT related accessibility issue * Bug#673931 - Python-ldtp has issues if the application calls an env or other program to run Credit: * Ubuntu QA team members (Dave Morley, Ara Pulido) * VMware desktop QA team members * Kartik Mistry (Debian package maintainer) * Thanks to all others who have reported bugs through forum / email / in-person / IRC About LDTP: Cross Platform GUI Automation tool Linux version is LDTP, Windows version is Cobra and Mac version is PyATOM (Work in progress). * Linux version is known to work on GNOME / KDE (QT >= 4.8) / Java Swing / LibreOffice / Mozilla application on all major Linux distribution. * Windows version is known to work on application written in .NET / C++ / Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version. * Mac version is currently under development and verified only on OS X Lion. Where ever PyATOM runs, LDTP should work on it. Download source: https://github.com/ldtp/ldtp2 Download binary (RPM / DEB): http://download.opensuse.org/repositories/home:/anagappan:/ldtp2:/ Documentation references: For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org For information on various APIs in LDTP including those added for this release can be got from http://ldtp.freedesktop.org/user-doc/index.html Java doc - http://ldtp.freedesktop.org/javadoc/ Report bugs - http://ldtp.freedesktop.org/wiki/Bugs To subscribe to LDTP mailing lists, visit http://ldtp.freedesktop.org/wiki/Mailing_20list IRC Channel - #ldtp on irc.freenode.net Thanks Nagappan -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org Cobra - Windows GUI Automation tool - https://github.com/ldtp/cobra http://nagappanal.blogspot.com From david.holmes at oracle.com Mon Aug 6 01:53:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 06 Aug 2012 11:53:59 +1000 Subject: jvm core dump with libnet.so In-Reply-To: References: Message-ID: <501F23B7.8090800@oracle.com> Hi, Please don't use the discuss list for bug reports - that is not its purpose. There are technical mailing lists for various components of OpenJDK. In this case net-dev at openjdk.java.net is most appropriate. Thanks, David Holmes On 3/08/2012 2:04 PM, the.6th.month at gmail.com wrote: > hi, all: > > We just encountered core dumps with our java process several times in > recent hours, and we've collected two core dump files and made a brief > analysis with gdb. According to the backtrace, both core dumps seem to be > resulted from libnet.so. The backtrace info is pasted as follows: > > core dump 1 > warning: no loadable sections found in added symbol-file system-supplied > DSO at 0x7fff497d6000 > Core was generated by `/home/q/java/jdk1.6.0_26/bin/java > -Djava.util.logging.config.file=/home/q/www/t'. > Program terminated with signal 11, Segmentation fault. > #0 0x00000030b160de70 in send () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x00000030b160de70 in send () from /lib64/libpthread.so.0 > #1 0x00002aaab8e88843 in NET_Send () from > /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so > #2 0x00002aaab8e85666 in Java_java_net_SocketOutputStream_socketWrite0 () > from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so > > core dump 2 > warning: no loadable sections found in added symbol-file system-supplied > DSO at 0x7fff979fc000 > Core was generated by `/home/q/java/jdk1.6.0_26/bin/java > -Djava.util.logging.config.file=/home/q/www/t'. > Program terminated with signal 11, Segmentation fault. > #0 0x00000030b0e8c42b in gettimeofday () from /lib64/libc.so.6 > (gdb) bt > #0 0x00000030b0e8c42b in gettimeofday () from /lib64/libc.so.6 > #1 0x00002aaab8b4bd42 in NET_Timeout () from > /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.soCentOS release 5.6 (Final > #2 0x00002aaab8b483c5 in Java_java_net_SocketInputStream_socketRead0 () > from /home/q/java/jdk1.6.0_26/jre/lib/amd64/libnet.so > > Our program is running with hotspot jdk 6u26, and the JAVA_OPTS is as below: > -XX:+PrintGCDetails -Xss256k -XX:+UseCompressedOops -XX:+DisableExplicitGC > -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution > -Xloggc:/home/q/www/travelco/logs/gc.log-server -Xms5120m -Xmx5120m > -Xmn1536m -XX:PermSize=256m -server -Dfile.encoding=UTF-8 > > The OS is CentOS release 5.6 (Final), and the whole system is running on a > physical machine with 24 cores and 8 gigabytes memory. > > We encountered almost the same problem a year ago, and we solved the > problem by simply changed from hotspot jdk to openjdk. > It sounds quite weird to me, and I am keen to know what the reason is for > this situation. Does anyone have any idea about that? Any help would be > truly appreciated. > Thanks very much. > > All the best, > Leon From recursivepointer at gmail.com Tue Aug 7 09:10:06 2012 From: recursivepointer at gmail.com (viper) Date: Tue, 7 Aug 2012 11:10:06 +0200 Subject: Running Java Applications on Windows Embedded Handheld 6.5 systems Message-ID: Hi all! I've a Motorola MC 3100G with Windows Embedded Handheld 6.5. I would like to run my java application on it, but i can't find a java virtual machine for this system.. anyone there can help me? regards, viper -- + http://vipertechnology.dyndns.org () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments + http://vipertechnology.dyndns.org/cotnact/ From roger.riggs at oracle.com Fri Aug 10 20:26:33 2012 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 10 Aug 2012 16:26:33 -0400 Subject: Project Proposal: Threeten Message-ID: <50256E79.7050206@oracle.com> In accordance with the OpenJDK guidelines [1], we would like to start discussion of a new Project to integrate JSR 310 Date and Time API into OpenJDK. The goal of the ThreeTen Project will be to integrate the JSR 310 RI into OpenJDK. Currently, JSR 310 is hosted on SourceForge [2] and the source code hosted at Github [3]. The ThreeTen Project will only contribute the JSR 310 RI, Specification, and tests to OpenJDK. The new Project depends on parallel OpenJDK Projects such as Project Lambda and other related internationalization updates. The JSR 310 public discussion alias [4] will continue to be hosted on SourceForge. The development of the specification, RI and tests will continue on Github and be periodically merged into the ThreeTen OpenJDK Project. The proposed initial Project lead is Roger Riggs, a co-spec lead of JSR 310 with Stephen Colebourne and Michael Nascimento Santos. Roger has been working in the Core Libraries Group to facilitate the integration of JSR 310 RI into OpenJDK. The initial committers are proposed to be: Stephen Colebourne, Sherman Shen, Roger Riggs and James Gough, and Richard Warburton. Please discuss and let us know what you think in the next week. Thank you for your consideration, [1] http://openjdk.java.net/projects/#new-project [2] http://threeten.sourceforge.net [3] https://github.com/ThreeTen/threeten [4] https://sourceforge.net/mail/?group_id=386712 From John.Coomes at oracle.com Mon Aug 13 23:13:22 2012 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 13 Aug 2012 16:13:22 -0700 Subject: Project Proposal: GPU support Message-ID: <20521.35346.516524.252773@oracle.com> In accordance with the OpenJDK guidelines [1], we would like to start the discussion of a new project to explore implementing GPU support in Java with a native JVM. This project intends to enable Java applications to seamlessly take advantage of a GPU--whether it is a discrete device or integrated with a CPU--with the objective to improve the application performance. This project will demonstrate the performance advantages of offloading Java compute to a GPU. We propose to use the Hotspot JVM, and will concentrate on code generation, garbage collection, and runtimes. Performance will be improved, while preserving compile time, memory consumption and code generation quality. We anticipate that this project will also provide guidance on enabling GPU support for other JVM hosted languages (JavaScript/Nashorn, Scala, JRuby...). We will start exploring leveraging the new Java 8 Lambda language and library features. As this project progress, we may identify challenges with the Java API and constructs which may lead to new language, JVM and library extensions that will need standardization under the JCP process. To ensure the broadest possible collaboration between potential contributors the project will maintain one or more code repositories derived from the OpenJDK HotSpot repository [2] and a developers' mailing list. The HotSpot group[3] will sponsor this project. John Coomes will be the initial Lead; the initial Committers and Authors are still being determined. (Reviewers are not needed as the project will not require formal change review.) Regards, John Coomes, OpenJDK HotSpot Group Lead Gary Frost, AMD [1] http://openjdk.java.net/projects/#new-project [2] http://hg.openjdk.java.net/hsx/hotspot-main/ [3] http://openjdk.java.net/census#hotspot From mp at jugs.org Tue Aug 14 06:23:43 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Tue, 14 Aug 2012 08:23:43 +0200 Subject: Project Proposal: GPU support In-Reply-To: <20521.35346.516524.252773@oracle.com> References: <20521.35346.516524.252773@oracle.com> Message-ID: <5029EEEF.7090405@jugs.org> Hi, I thought you might be interested in a link to a project with a very similar goal. Regards, Michael Am 14.08.2012 01:13, schrieb John Coomes: > In accordance with the OpenJDK guidelines [1], we would like to start > the discussion of a new project to explore implementing GPU support in > Java with a native JVM. This project intends to enable Java > applications to seamlessly take advantage of a GPU--whether it is a > discrete device or integrated with a CPU--with the objective to > improve the application performance. > > This project will demonstrate the performance advantages of offloading > Java compute to a GPU. We propose to use the Hotspot JVM, and will > concentrate on code generation, garbage collection, and > runtimes. Performance will be improved, while preserving compile time, > memory consumption and code generation quality. We anticipate that > this project will also provide guidance on enabling GPU support for > other JVM hosted languages (JavaScript/Nashorn, Scala, JRuby...). > > We will start exploring leveraging the new Java 8 Lambda language and > library features. As this project progress, we may identify challenges > with the Java API and constructs which may lead to new language, JVM > and library extensions that will need standardization under the JCP > process. > > To ensure the broadest possible collaboration between potential > contributors the project will maintain one or more code repositories > derived from the OpenJDK HotSpot repository [2] and a developers' > mailing list. > > The HotSpot group[3] will sponsor this project. John Coomes will be > the initial Lead; the initial Committers and Authors are still being > determined. (Reviewers are not needed as the project will not require > formal change review.) > > Regards, > > John Coomes, OpenJDK HotSpot Group Lead > Gary Frost, AMD > > [1] http://openjdk.java.net/projects/#new-project > [2] http://hg.openjdk.java.net/hsx/hotspot-main/ > [3] http://openjdk.java.net/census#hotspot -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From Gary.Frost at amd.com Tue Aug 14 16:12:27 2012 From: Gary.Frost at amd.com (Frost, Gary) Date: Tue, 14 Aug 2012 16:12:27 +0000 Subject: Project Proposal: GPU support Message-ID: Thanks John, On behalf of AMD I'd like to confirm we're very interested in this project and looking forward to fully participating. We would be happy to have some of our engineers be Committers on this project. Gary Frost From donald.smith at oracle.com Tue Aug 14 16:43:09 2012 From: donald.smith at oracle.com (Donald Smith) Date: Tue, 14 Aug 2012 12:43:09 -0400 Subject: Project Proposal: GPU support In-Reply-To: <5029EEEF.7090405@jugs.org> References: <20521.35346.516524.252773@oracle.com> <5029EEEF.7090405@jugs.org> Message-ID: <502A801D.8030304@oracle.com> Thanks - we did notice the /. coverage this weekend, what great timing! I do definitely want to work out, are you by any chance related to this work and could facilitate an intro, otherwise I'll just reach out directly. - Don On 14/08/2012 2:23 AM, Dr. Michael Paus wrote: > Hi, > I thought you might be interested in a link to a project with a very > similar goal. > > Regards, > Michael > > Am 14.08.2012 01:13, schrieb John Coomes: >> In accordance with the OpenJDK guidelines [1], we would like to start >> the discussion of a new project to explore implementing GPU support in >> Java with a native JVM. This project intends to enable Java >> applications to seamlessly take advantage of a GPU--whether it is a >> discrete device or integrated with a CPU--with the objective to >> improve the application performance. >> >> This project will demonstrate the performance advantages of offloading >> Java compute to a GPU. We propose to use the Hotspot JVM, and will >> concentrate on code generation, garbage collection, and >> runtimes. Performance will be improved, while preserving compile time, >> memory consumption and code generation quality. We anticipate that >> this project will also provide guidance on enabling GPU support for >> other JVM hosted languages (JavaScript/Nashorn, Scala, JRuby...). >> >> We will start exploring leveraging the new Java 8 Lambda language and >> library features. As this project progress, we may identify challenges >> with the Java API and constructs which may lead to new language, JVM >> and library extensions that will need standardization under the JCP >> process. >> >> To ensure the broadest possible collaboration between potential >> contributors the project will maintain one or more code repositories >> derived from the OpenJDK HotSpot repository [2] and a developers' >> mailing list. >> >> The HotSpot group[3] will sponsor this project. John Coomes will be >> the initial Lead; the initial Committers and Authors are still being >> determined. (Reviewers are not needed as the project will not require >> formal change review.) >> >> Regards, >> >> John Coomes, OpenJDK HotSpot Group Lead >> Gary Frost, AMD >> >> [1] http://openjdk.java.net/projects/#new-project >> [2] http://hg.openjdk.java.net/hsx/hotspot-main/ >> [3] http://openjdk.java.net/census#hotspot > > From Alan.Bateman at oracle.com Tue Aug 14 17:50:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Aug 2012 18:50:54 +0100 Subject: Project Proposal: Threeten In-Reply-To: <50256E79.7050206@oracle.com> References: <50256E79.7050206@oracle.com> Message-ID: <502A8FFE.4090302@oracle.com> On 10/08/2012 21:26, roger riggs wrote: > In accordance with the OpenJDK guidelines [1], we would like to start > discussion > of a new Project to integrate JSR 310 Date and Time API into OpenJDK. I support this proposal and propose that it be sponsored by the core-libs group. -Alan. From scolebourne at joda.org Tue Aug 14 18:02:29 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 14 Aug 2012 19:02:29 +0100 Subject: Project Proposal: Threeten In-Reply-To: <50256E79.7050206@oracle.com> References: <50256E79.7050206@oracle.com> Message-ID: Unsurprisingly, I support the creation of this project to integrate JSR-310/ThreeTen. Stephen On 10 August 2012 21:26, roger riggs wrote: > In accordance with the OpenJDK guidelines [1], we would like to start > discussion > of a new Project to integrate JSR 310 Date and Time API into OpenJDK. > > The goal of the ThreeTen Project will be to integrate the JSR 310 RI into > OpenJDK. > Currently, JSR 310 is hosted on SourceForge [2] and the source code hosted > at Github [3]. > The ThreeTen Project will only contribute the JSR 310 RI, Specification, and > tests > to OpenJDK. The new Project depends on parallel OpenJDK Projects such as > Project Lambda and other related internationalization updates. > > The JSR 310 public discussion alias [4] will continue to be hosted on > SourceForge. > The development of the specification, RI and tests will continue on Github > and > be periodically merged into the ThreeTen OpenJDK Project. > > The proposed initial Project lead is Roger Riggs, a co-spec lead of JSR 310 > with Stephen Colebourne and Michael Nascimento Santos. Roger has been > working in the Core Libraries Group to facilitate the integration of JSR > 310 RI > into OpenJDK. > The initial committers are proposed to be: Stephen Colebourne, Sherman Shen, > Roger Riggs and James Gough, and Richard Warburton. > > Please discuss and let us know what you think in the next week. > > Thank you for your consideration, > > [1] http://openjdk.java.net/projects/#new-project > [2] http://threeten.sourceforge.net > [3] https://github.com/ThreeTen/threeten > [4] https://sourceforge.net/mail/?group_id=386712 From henri.gomez at gmail.com Wed Aug 15 05:24:38 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 15 Aug 2012 07:24:38 +0200 Subject: Project Proposal: GPU support In-Reply-To: <502A801D.8030304@oracle.com> References: <20521.35346.516524.252773@oracle.com> <5029EEEF.7090405@jugs.org> <502A801D.8030304@oracle.com> Message-ID: > Thanks - we did notice the /. coverage this weekend, what great timing! I > do definitely want to work out, are you by any chance related to this work > and could facilitate an intro, otherwise I'll just reach out directly. I think you could contact Phil Pratt-Szeliga (pcpratts at chirrup.org) From mp at jugs.org Wed Aug 15 06:45:14 2012 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 15 Aug 2012 08:45:14 +0200 Subject: Project Proposal: GPU support In-Reply-To: <502A801D.8030304@oracle.com> References: <20521.35346.516524.252773@oracle.com> <5029EEEF.7090405@jugs.org> <502A801D.8030304@oracle.com> Message-ID: <502B457A.9090908@jugs.org> Am 14.08.2012 18:43, schrieb Donald Smith: > Thanks - we did notice the /. coverage this weekend, what great > timing! I do definitely want to work out, are you by any chance > related to this work and could facilitate an intro, otherwise I'll > just reach out directly. No, I am not related to this work. I just read about it somewhere a couple of days ago and remembered it when I got your proposal. > > - Don > > > On 14/08/2012 2:23 AM, Dr. Michael Paus wrote: >> Hi, >> I thought you might be interested in a link to a project with a very >> similar goal. >> >> Regards, >> Michael >> >> Am 14.08.2012 01:13, schrieb John Coomes: >>> In accordance with the OpenJDK guidelines [1], we would like to start >>> the discussion of a new project to explore implementing GPU support in >>> Java with a native JVM. This project intends to enable Java >>> applications to seamlessly take advantage of a GPU--whether it is a >>> discrete device or integrated with a CPU--with the objective to >>> improve the application performance. >>> >>> This project will demonstrate the performance advantages of offloading >>> Java compute to a GPU. We propose to use the Hotspot JVM, and will >>> concentrate on code generation, garbage collection, and >>> runtimes. Performance will be improved, while preserving compile time, >>> memory consumption and code generation quality. We anticipate that >>> this project will also provide guidance on enabling GPU support for >>> other JVM hosted languages (JavaScript/Nashorn, Scala, JRuby...). >>> >>> We will start exploring leveraging the new Java 8 Lambda language and >>> library features. As this project progress, we may identify challenges >>> with the Java API and constructs which may lead to new language, JVM >>> and library extensions that will need standardization under the JCP >>> process. >>> >>> To ensure the broadest possible collaboration between potential >>> contributors the project will maintain one or more code repositories >>> derived from the OpenJDK HotSpot repository [2] and a developers' >>> mailing list. >>> >>> The HotSpot group[3] will sponsor this project. John Coomes will be >>> the initial Lead; the initial Committers and Authors are still being >>> determined. (Reviewers are not needed as the project will not require >>> formal change review.) >>> >>> Regards, >>> >>> John Coomes, OpenJDK HotSpot Group Lead >>> Gary Frost, AMD >>> >>> [1] http://openjdk.java.net/projects/#new-project >>> [2] http://hg.openjdk.java.net/hsx/hotspot-main/ >>> [3] http://openjdk.java.net/census#hotspot >> >> -- -------------------------------------------------------------------------------------- Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS). For more information visit www.jugs.de. From henri.gomez at gmail.com Wed Aug 15 07:40:06 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Wed, 15 Aug 2012 09:40:06 +0200 Subject: Project Proposal: GPU support In-Reply-To: <502B457A.9090908@jugs.org> References: <20521.35346.516524.252773@oracle.com> <5029EEEF.7090405@jugs.org> <502A801D.8030304@oracle.com> <502B457A.9090908@jugs.org> Message-ID: > No, I am not related to this work. I just read about it somewhere a couple > of days ago > and remembered it when I got your proposal. Side note, there is work in progress to add OSX support next to Linux, Windows. From pcpratts at chirrup.org Thu Aug 16 19:19:02 2012 From: pcpratts at chirrup.org (Phil Pratt-Szeliga) Date: Thu, 16 Aug 2012 15:19:02 -0400 Subject: Project Proposal: GPU support Message-ID: Hello, I would be interested in working with the Hotspot group on this project. Phil Pratt-Szeliga Syracuse University http://chirrup.org/ From donald.smith at oracle.com Thu Aug 16 19:53:52 2012 From: donald.smith at oracle.com (Donald Smith) Date: Thu, 16 Aug 2012 15:53:52 -0400 Subject: Project Proposal: GPU support In-Reply-To: References: Message-ID: <502D4FD0.6060703@oracle.com> Hi Phil, Will you be at JavaOne by chance? - Don On 16/08/2012 3:19 PM, Phil Pratt-Szeliga wrote: > Hello, > > I would be interested in working with the Hotspot group on this project. > > Phil Pratt-Szeliga > Syracuse University > http://chirrup.org/ From Ryan.LaMothe at pnnl.gov Thu Aug 16 20:11:38 2012 From: Ryan.LaMothe at pnnl.gov (LaMothe, Ryan R) Date: Thu, 16 Aug 2012 13:11:38 -0700 Subject: Project Proposal: GPU support In-Reply-To: References: Message-ID: <0003FD2B9D9E364CBFD03658C2991E6301AC8DCD6BCD@EMAIL04.pnl.gov> I am interested in working with the Hotspot group on this project. I would also like introduce folks on this list to Aparapi, if you are not familiar: http://code.google.com/p/aparapi/ http://developer.amd.com/zones/java/aparapi/pages/default.aspx __________________________________________________ Ryan LaMothe Research Scientist Pacific Northwest National Laboratory ryan.lamothe at pnnl.gov www.pnnl.gov From henri.gomez at gmail.com Thu Aug 16 21:12:25 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Thu, 16 Aug 2012 23:12:25 +0200 Subject: Project Proposal: GPU support In-Reply-To: <0003FD2B9D9E364CBFD03658C2991E6301AC8DCD6BCD@EMAIL04.pnl.gov> References: <0003FD2B9D9E364CBFD03658C2991E6301AC8DCD6BCD@EMAIL04.pnl.gov> Message-ID: More than pleased to see how many projects are focused on Java on GPU. Cuda, OpenCL, tremendous 2012/8/16 LaMothe, Ryan R : > I am interested in working with the Hotspot group on this project. > > I would also like introduce folks on this list to Aparapi, if you are not familiar: > > http://code.google.com/p/aparapi/ > http://developer.amd.com/zones/java/aparapi/pages/default.aspx > > > __________________________________________________ > > Ryan LaMothe > Research Scientist > > Pacific Northwest National Laboratory > ryan.lamothe at pnnl.gov > www.pnnl.gov From john.r.rose at oracle.com Fri Aug 17 01:34:51 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 16 Aug 2012 18:34:51 -0700 Subject: Project Proposal: GPU support In-Reply-To: References: Message-ID: Excellent! I'm eager to find out what "pain points" in the JVM architecture you ran into doing rootbeer. Regarding the graph linearization part, have a look at the Batches talk and my Arrays talk at the JVM Language Summit. The videos were just posted. Here's mine: http://medianetwork.oracle.com/video/player/1785452137001 -- John (on my iPhone) On Aug 16, 2012, at 12:19 PM, Phil Pratt-Szeliga wrote: > Hello, > > I would be interested in working with the Hotspot group on this project. > > Phil Pratt-Szeliga > Syracuse University > http://chirrup.org/ From sebastian.sickelmann at gmx.de Fri Aug 17 08:15:03 2012 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Fri, 17 Aug 2012 10:15:03 +0200 Subject: Project Proposal: CompatibleChanges Message-ID: <502DFD87.9080303@gmx.de> In accordance with the OpenJDK guidelines [1], I would like to start discussion of a new Project to change the OpenJDK JVM implementation to make it possible to update java apis in ways that are not possible today. The goal of the CompatibleChanges Project will be to change the OpenJDK JVM implementation. It is not intented to change Java The-Language. Currently i there is one Proof of Concept[2] that shows the possible-usage in an example (remove public static- and instance-fields in a binary compatible way). The POC uses bytecode-rewrite at loadtime and invokedynamic at runtime to figure out which method to call instead of an fieldaccess. My initial suggest would be to change the JVMS-rules for Field Resolution and don't do it with instrumentation and invoke-dynamic. Real-Short Example: public class ClassToChange { public Throwable cause = new RuntimeException("INIT"); public static Object staticField = "ORIG_VALUE"; } Evolved Implementation: public class OLD { private Throwable cause = new RuntimeException("INIT"); private static Object staticField = "ORIG_VALUE"; @Accessor("cause") public Throwable getCause() { return cause; } @Accessor("cause") public void initCause(Throwable cause) { this.cause = cause; } @Accessor("staticField") public static Object getFoo() { return staticField; } @Accessor("staticField") public static void setFoo(Object value) { staticField = value; } } Some initial thoughts about Reflection-Changes and 3 ways of how the Field Resolution Rules can be changed are documented here[3]. It is written in the textual form of a JEP, but it is not intended to be a JEP. There is some initial feedback (on my first discussion request in jdk8-dev) by Brian Goetz and Joe Darcy back in Oct 2011[4]. The initial committers are proposed to be: Sebastian Sickelmann Please discuss and let me know what you think. Thank you for your consideration, [1] http://openjdk.java.net/projects/#new-project [2] https://github.com/picpromusic/incubator/tree/projectProposal/jdk/compatibleFieldAccess [3] https://github.com/picpromusic/incubator/blob/projectProposal/jdk/compatibleFieldAccess/JEP.markdown [4]http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html From pcpratts at chirrup.org Fri Aug 17 14:02:04 2012 From: pcpratts at chirrup.org (Phil Pratt-Szeliga) Date: Fri, 17 Aug 2012 10:02:04 -0400 Subject: Project Proposal: GPU support In-Reply-To: References: Message-ID: Hi John, Thanks for the slides. I am not in touch with experts on Java! :-) I'll have to think about this a little. The way I made Rootbeer, I made it work for any JVM, which required a certain design. If we are inside the JVM, there are lots of new tradeoffs to study about how to best do things. One tough thing about making rootbeer is that once you send your binary to the GPU and launch it, it was pretty much a black box for me. I couldn't see inside the GPU very well. Some minor things that come to mind: 1. On the NVIDIA GPUs if you don't align, say, int's, to a 4 byte boundary, the GPU will silently align the pointer and read from where ever that is. 2. You can't make the CUDA code for the GPU include all of the Java code. It will be too big for the GPU and compilation will take too long. Rootbeer searches which methods are reachable from the entry (gpuMethod in the rootbeer interface Kernel) and does things like only include the fields accessible from those methods. 3. Some of the native code in, say, AtomicLong or Random that people did for performance reasons made me remap those classes to pure Java versions I made myself. Right now native code cannot be put on the GPU with rootbeer. Research topic? 4. When I made rootbeer I cross-compiled Java Bytecode to CUDA and then compiled the CUDA before anything runs on the GPU. If this is happening inside the JVM, we might want to translate straight to ptx (for NVIDIA devices). 5. Keeping track of the root objects for the garbage collector could be tricky on the GPU because there is no runtime monitor in my work. Just plain CUDA code. 6. Serialization and memory transfer is a huge bottleneck when using GPUs talking over a PCI express bus. 7. Properly using the shared memory (NVIDIA term here) on the GPU is a harder research problem. I did not get that to work yet with rootbeer. But shared memory gives much better performance. 8. For even more optimizations people have research about converting un-aligned GPU memory reads into GPU aligned memory reads. These are just a few things I am thinking of right now. Another person that maybe people should talk to is Micheal Wolfe at PGI [1]. Phil Pratt-Szeliga Syracuse University http://chirrup.org/ [1] http://www.pgroup.com/index.htm From pcpratts at chirrup.org Fri Aug 17 14:13:29 2012 From: pcpratts at chirrup.org (Phil Pratt-Szeliga) Date: Fri, 17 Aug 2012 10:13:29 -0400 Subject: Project Proposal: GPU support In-Reply-To: References: Message-ID: Sorry, typo in my last email. I mean to say: "I am _now_ in touch with experts on Java". Phil Pratt-Szeliga Syracuse University http://chirrup.org/ From Ryan.LaMothe at pnnl.gov Fri Aug 17 21:06:32 2012 From: Ryan.LaMothe at pnnl.gov (LaMothe, Ryan R) Date: Fri, 17 Aug 2012 14:06:32 -0700 Subject: Project Proposal: GPU support In-Reply-To: Message-ID: Has anyone considered platform and device independent solutions such as the next-generation Heterogeneous Systems Architecture (HSA): http://hsafoundation.com/ This framework holds enormous promise and would be my first choice to target for a heterogeneous JVM feature like GPU and APU computing. __________________________________________________ Ryan LaMothe Research Scientist Pacific Northwest National Laboratory On 8/17/12 7:02 AM, "Phil Pratt-Szeliga" wrote: >Hi John, > >Thanks for the slides. I am not in touch with experts on Java! :-) > >I'll have to think about this a little. The way I made Rootbeer, I >made it work for any JVM, which required a certain design. If we are >inside the JVM, there are lots of new tradeoffs to study about how to >best do things. One tough thing about making rootbeer is that once you >send your binary to the GPU and launch it, it was pretty much a black >box for me. I couldn't see inside the GPU very well. > >Some minor things that come to mind: >1. On the NVIDIA GPUs if you don't align, say, int's, to a 4 byte >boundary, the GPU will silently align the pointer and read from where >ever that is. >2. You can't make the CUDA code for the GPU include all of the Java >code. It will be too big for the GPU and compilation will take too >long. Rootbeer searches which methods are reachable from the entry >(gpuMethod in the rootbeer interface Kernel) and does things like only >include the fields accessible from those methods. >3. Some of the native code in, say, AtomicLong or Random that people >did for performance reasons made me remap those classes to pure Java >versions I made myself. Right now native code cannot be put on the GPU >with rootbeer. Research topic? >4. When I made rootbeer I cross-compiled Java Bytecode to CUDA and >then compiled the CUDA before anything runs on the GPU. If this is >happening inside the JVM, we might want to translate straight to ptx >(for NVIDIA devices). >5. Keeping track of the root objects for the garbage collector could >be tricky on the GPU because there is no runtime monitor in my work. >Just plain CUDA code. >6. Serialization and memory transfer is a huge bottleneck when using >GPUs talking over a PCI express bus. >7. Properly using the shared memory (NVIDIA term here) on the GPU is a >harder research problem. I did not get that to work yet with rootbeer. >But shared memory gives much better performance. >8. For even more optimizations people have research about converting >un-aligned GPU memory reads into GPU aligned memory reads. > >These are just a few things I am thinking of right now. > >Another person that maybe people should talk to is Micheal Wolfe at PGI >[1]. > >Phil Pratt-Szeliga >Syracuse University >http://chirrup.org/ > >[1] http://www.pgroup.com/index.htm From i30817 at gmail.com Sat Aug 18 14:18:22 2012 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 18 Aug 2012 15:18:22 +0100 Subject: Should LinkedHashMap expose the Entries subclass Message-ID: I'm trying to subclass LinkedHashMap so i can add new indexed iterator methods: ListIterator from(E e) So, getEntry(e) is package protected and i though 'easy, since the entries in this map are nodes on the list i can easily use that to make a iterator by placing my subclass on the 'java.util' namespace'. Not so fast; both header (the linked list guardian), modcount (the iterator failsafe iterator data) and more importantly the double linked Entry subclass are all private - so it seems my subclass is going to become a mess of reflection and my access times will suffer consequentially (though probably not as bad as copying the data). What i'm asking is if is there any change of the 'Linked' subclasses either returning a list iterator on their iterators, or at least making the internal data fields protected or package protected? From i30817 at gmail.com Sat Aug 18 14:20:48 2012 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 18 Aug 2012 15:20:48 +0100 Subject: Should LinkedHashMap expose the Entries subclass In-Reply-To: References: Message-ID: Excuse the spelling, 'change' -> 'chance', 'iterator failsafe iterator' -> 'iterator failsafe' On Sat, Aug 18, 2012 at 3:18 PM, Paulo Levi wrote: > I'm trying to subclass LinkedHashMap so i can add new indexed iterator > methods: > ListIterator from(E e) > > So, getEntry(e) is package protected and i though 'easy, since the entries > in this map are nodes on the list i can easily use that to make a iterator > by placing my subclass on the 'java.util' namespace'. > > Not so fast; both header (the linked list guardian), modcount (the > iterator failsafe iterator data) and more importantly the double linked > Entry subclass are all private - so it seems my subclass is going to become > a mess of reflection and my access times will suffer consequentially > (though probably not as bad as copying the data). > > What i'm asking is if is there any change of the 'Linked' subclasses > either returning a list iterator on their iterators, or at least making the > internal data fields protected or package protected? > From i30817 at gmail.com Sat Aug 18 16:38:14 2012 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 18 Aug 2012 17:38:14 +0100 Subject: Should LinkedHashMap expose the Entries subclass In-Reply-To: References: Message-ID: Now that i looked at the code, ListIterator is not the best fit - it has some dubious methods for something indexed by hashcode. The int nextIndex() and int previousIndex() methods. How about making a superinterface for ListIterator -> OrderedIterator and make a new methods OrderedIterator> from(K e) (for map) OrderedIterator from(E e) (for set) ? From i30817 at gmail.com Sat Aug 18 20:02:38 2012 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 18 Aug 2012 21:02:38 +0100 Subject: Is it a terrible idea to copy a jdk class source into my LGPL project? Message-ID: I'd like to know if i can work around some 'extension problems' like this, since my project is also open source. From i30817 at gmail.com Sat Aug 18 20:10:05 2012 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 18 Aug 2012 21:10:05 +0100 Subject: Should LinkedHashMap expose the Entries subclass In-Reply-To: References: Message-ID: Actually no, it shouldn't be ListIterator's super - a Iterator.add and Iterator.set used in a Set would need to potentially move a subsequent element that already exists. From david.holmes at oracle.com Sun Aug 19 22:42:16 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 Aug 2012 08:42:16 +1000 Subject: Should LinkedHashMap expose the Entries subclass In-Reply-To: References: Message-ID: <50316BC8.8060103@oracle.com> Paulo, Technical questions of this kind should be directed to the appropriate mailing list, not the discuss list. The appropriate list would be core-libs-dev at openjdk.java.net Regards, David Holmes On 19/08/2012 6:10 AM, Paulo Levi wrote: > Actually no, it shouldn't be ListIterator's super - a Iterator.add and > Iterator.set used in a Set would need to potentially move a subsequent > element that already exists. From sebastian.sickelmann at gmx.de Mon Aug 20 11:46:28 2012 From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann) Date: Mon, 20 Aug 2012 13:46:28 +0200 Subject: Project Proposal: CompatibleChanges In-Reply-To: <502DFD87.9080303@gmx.de> References: <502DFD87.9080303@gmx.de> Message-ID: <50322394.60405@gmx.de> I want to add some more ideas what can be done in the CompatibleChanges Project. I also would add some tools that can help developers to check for binary compatibility and to simplify the process of creating binary compatible solutions. Here are some samples: - Integrate tools to check for binary compatiblity like : https://github.com/lvc/japi-compliance-checker - Tools that can help to create compatible serialization implementations. - Tools for visualisation serialization; create human readable/comparable textual forms of serialization results. I hope that someone have some more good ideas how we can improve/simplify the creation of binary compatible changes. -- Sebastian Am 17.08.2012 10:15, schrieb Sebastian Sickelmann: > In accordance with the OpenJDK guidelines [1], I would like to start > discussion > of a new Project to change the OpenJDK JVM implementation to make it > possible to > update java apis in ways that are not possible today. > > The goal of the CompatibleChanges Project will be to change the > OpenJDK JVM implementation. > It is not intented to change Java The-Language. Currently i there is > one Proof of Concept[2] > that shows the possible-usage in an example (remove public static- and > instance-fields in a > binary compatible way). > The POC uses bytecode-rewrite at loadtime and invokedynamic at runtime > to figure out > which method to call instead of an fieldaccess. My initial suggest > would be to > change the JVMS-rules for Field Resolution and don't do it with > instrumentation and > invoke-dynamic. > > Real-Short Example: > public class ClassToChange { > public Throwable cause = new RuntimeException("INIT"); > public static Object staticField = "ORIG_VALUE"; > } > Evolved Implementation: > public class OLD { > private Throwable cause = new RuntimeException("INIT"); > private static Object staticField = "ORIG_VALUE"; > @Accessor("cause") public Throwable getCause() { return cause; } > @Accessor("cause") public void initCause(Throwable cause) { > this.cause = cause; } > @Accessor("staticField") public static Object getFoo() { return > staticField; } > @Accessor("staticField") public static void setFoo(Object value) { > staticField = value; } > } > > > Some initial thoughts about Reflection-Changes and 3 ways of how the > Field Resolution Rules can > be changed are documented here[3]. It is written in the textual form > of a JEP, but it is not > intended to be a JEP. > > There is some initial feedback (on my first discussion request in > jdk8-dev) by Brian Goetz > and Joe Darcy back in Oct 2011[4]. > > The initial committers are proposed to be: Sebastian Sickelmann > > Please discuss and let me know what you think. > > Thank you for your consideration, > > [1] http://openjdk.java.net/projects/#new-project > [2] > https://github.com/picpromusic/incubator/tree/projectProposal/jdk/compatibleFieldAccess > [3] > https://github.com/picpromusic/incubator/blob/projectProposal/jdk/compatibleFieldAccess/JEP.markdown > [4]http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html > From mike.milinkovich at eclipse.org Tue Aug 21 14:42:02 2012 From: mike.milinkovich at eclipse.org (Mike Milinkovich) Date: Tue, 21 Aug 2012 10:42:02 -0400 Subject: Enhanced metadata in Java SE 8 In-Reply-To: <50328C4C.90406@oracle.com> References: <50328C4C.90406@oracle.com> Message-ID: <006401cd7fab$231d4b70$6957e250$@eclipse.org> Alex, Could you please point me to the publicly-available issue tracker at OpenJDK for these JSRs? I can't seem to find them. Thanks. > -----Original Message----- > From: announce-bounces at openjdk.java.net [mailto:announce- > bounces at openjdk.java.net] On Behalf Of Alex Buckley > Sent: August-20-12 3:13 PM > To: announce at openjdk.java.net > Subject: Enhanced metadata in Java SE 8 > > The Compiler Group has sponsored a mailing list for the design and > specification of two language-level features in Java SE 8: repeating > annotations and method parameter reflection. More info at: > > http://mail.openjdk.java.net/pipermail/compiler-dev/2012- > August/004636.html > > Thanks to the OpenJDK Web Site Terms of Use, this is the first time that > OpenJDK will host the specification of Java SE features as well as their > implementation. The link above mentions how specification v. > implementation will be divided. > > Alex From alex.buckley at oracle.com Wed Aug 22 18:08:00 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Aug 2012 11:08:00 -0700 Subject: Enhanced metadata in Java SE 8 Message-ID: <50352000.6040803@oracle.com> Mike, These features are described by JEPs, not JSRs. Because the features make small changes to the Java language, JVM, and java.* API, they are being carried out under the authority of the Java SE 8 Platform Umbrella JSR (337) as required by http://jcp.org/en/procedures/jcp2#2.1.2. Alex > Alex, > > Could you please point me to the publicly-available issue tracker at OpenJDK for these JSRs? I can't seem to find them. > > Thanks. > >> -----Original Message----- >> From: announce-bounces at openjdk.java.net [mailto:announce- >> bounces at openjdk.java.net] On Behalf Of Alex Buckley >> Sent: August-20-12 3:13 PM >> To: announce at openjdk.java.net >> Subject: Enhanced metadata in Java SE 8 >> >> The Compiler Group has sponsored a mailing list for the design and >> specification of two language-level features in Java SE 8: repeating >> annotations and method parameter reflection. More info at: >> >> http://mail.openjdk.java.net/pipermail/compiler-dev/2012- >> August/004636.html >> >> Thanks to the OpenJDK Web Site Terms of Use, this is the first time that >> OpenJDK will host the specification of Java SE features as well as their >> implementation. The link above mentions how specification v. >> implementation will be divided. >> >> Alex From alex.buckley at oracle.com Wed Aug 22 18:19:27 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Aug 2012 11:19:27 -0700 Subject: CFV: New Project: Three Ten In-Reply-To: References: Message-ID: <503522AF.9090207@oracle.com> Iris, Please clarify that the name of the proposed OpenJDK project is "Three Ten", not "ThreeTen". "ThreeTen" is the SourceForge project but you used it in the body where "Three Ten" was needed. Essentially, the ThreeTen project on SourceForge is going to contribute materials to the Three Ten project on OpenJDK. Now that nomenclature is all cleared up (!), my main question: what mailing lists are planned for the Three Ten project? If the JSR 310 specification is to be "contributed" to OpenJDK, then it will presumably need a comment-and-evaluation-licensed mailing list separate from a GPL'd list for RI discussion. Alex On Wednesday, August 22, 2012 4:55:31 AM, Iris Clark wrote: > I hereby propose the creation of the ThreeTen Project with Roger Riggs as the Lead and Core Libraries as the sponsoring Group. > > As discussed earlier [1], the goal of the ThreeTen Project is to integrate the JSR 310 Date and Time API [2] Reference Implementation (RI) into JDK 8 [3]. Currently, JSR 310 is hosted on SourceForge [4] and the source code is hosted at Github [5]. The ThreeTen Project will contribute the JSR 310 RI, specification, and tests to OpenJDK. This Project depends on other OpenJDK Projects such as Project Lambda and other related internationalization updates. > > The JSR 310 public discussion list [6] will continue to be hosted on SourceForge. The development of the specification, RI, and tests will continue on Github and be periodically merged into the ThreeTen Project. > > The proposed Project Lead is Roger Riggs, a co-spec lead of JSR 310 with Stephen Colebourne and Michael Nascimento Santos. Roger has been working in the Core Libraries Group to facilitate the integration of the JSR 310 RI into JDK 8. > > The initial committers will be: Stephen Colebourne, Sherman Shen, Roger Riggs, James Gough, and Richard Warburton. > > Votes are due by 7:00pm UTC on Wednesday, 5 September [7]. > > Only current OpenJDK Members [8] are eligible to vote on this motion. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [9]. > > Thanks! > Iris Clark > > [1] http://mail.openjdk.java.net/pipermail/discuss/2012-August/002716.html > [2] http://jcp.org/en/jsr/detail?id=310 > [3] http://openjdk.java.net/projects/jdk8/ > [4] http://threeten.sourceforge.net > [5] https://github.com/ThreeTen/threeten > [6] https://sourceforge.net/mail/?group_id=386712 > [7] http://www.timeanddate.com/worldclock/fixedtime.html?msg=ThreeTen+Project+Votes&iso=20120905T12&p1=283 > [8] http://openjdk.java.net/census#members > [9] http://openjdk.java.net/projects/#new-project-vote From mike.milinkovich at eclipse.org Wed Aug 22 18:34:44 2012 From: mike.milinkovich at eclipse.org (Mike Milinkovich) Date: Wed, 22 Aug 2012 18:34:44 +0000 Subject: Enhanced metadata in Java SE 8 In-Reply-To: <50352000.6040803@oracle.com> References: <50352000.6040803@oracle.com> Message-ID: <1811612810-1345660487-cardhu_decombobulator_blackberry.rim.net-796066213-@b3.c18.bise6.blackberry> Alex, Thanks. But what makes no sense to me is that the Java 8 JSR337 stipulates that it is operating under version 2.7 of the JCP process, but the authority you reference is in the 2.8 version. How does that work? Further, my reading of the transparency requirements in the 2.8 process _require_ an open issue tracker if the spec work is hosted elsewhere. Am I reading it wrong? I'm not trying to be a problem child. I think doing spec and RI work in parallel and in open source is the right way to go. I just don't get how this intersection of JCP and OpenJDK processes actually works. Mike Milinkovich mike.milinkovich at eclipse.org +1.613.220.3223 -----Original Message----- From: Alex Buckley Sender: discuss-bounces at openjdk.java.net Date: Wed, 22 Aug 2012 11:08:00 To: Subject: Enhanced metadata in Java SE 8 Mike, These features are described by JEPs, not JSRs. Because the features make small changes to the Java language, JVM, and java.* API, they are being carried out under the authority of the Java SE 8 Platform Umbrella JSR (337) as required by http://jcp.org/en/procedures/jcp2#2.1.2. Alex > Alex, > > Could you please point me to the publicly-available issue tracker at OpenJDK for these JSRs? I can't seem to find them. > > Thanks. > >> -----Original Message----- >> From: announce-bounces at openjdk.java.net [mailto:announce- >> bounces at openjdk.java.net] On Behalf Of Alex Buckley >> Sent: August-20-12 3:13 PM >> To: announce at openjdk.java.net >> Subject: Enhanced metadata in Java SE 8 >> >> The Compiler Group has sponsored a mailing list for the design and >> specification of two language-level features in Java SE 8: repeating >> annotations and method parameter reflection. More info at: >> >> http://mail.openjdk.java.net/pipermail/compiler-dev/2012- >> August/004636.html >> >> Thanks to the OpenJDK Web Site Terms of Use, this is the first time that >> OpenJDK will host the specification of Java SE features as well as their >> implementation. The link above mentions how specification v. >> implementation will be divided. >> >> Alex From alex.buckley at oracle.com Wed Aug 22 18:40:08 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 22 Aug 2012 11:40:08 -0700 Subject: Enhanced metadata in Java SE 8 In-Reply-To: <1811612810-1345660487-cardhu_decombobulator_blackberry.rim.net-796066213-@b3.c18.bise6.blackberry> References: <50352000.6040803@oracle.com> <1811612810-1345660487-cardhu_decombobulator_blackberry.rim.net-796066213-@b3.c18.bise6.blackberry> Message-ID: <50352788.9060708@oracle.com> Ah, pardon my use of a JCP 2.8 URL. Since as you say JSR 337 is run under JCP 2.7, the correct URL is http://jcp.org/en/procedures/jcp2_7#1.1.2. Alex On 8/22/2012 11:34 AM, Mike Milinkovich wrote: > > Alex, > > Thanks. But what makes no sense to me is that the Java 8 JSR337 > stipulates that it is operating under version 2.7 of the JCP process, > but the authority you reference is in the 2.8 version. How does that > work? > > Further, my reading of the transparency requirements in the 2.8 > process _require_ an open issue tracker if the spec work is hosted > elsewhere. Am I reading it wrong? > > I'm not trying to be a problem child. I think doing spec and RI work > in parallel and in open source is the right way to go. I just don't > get how this intersection of JCP and OpenJDK processes actually > works. > > > Mike Milinkovich mike.milinkovich at eclipse.org +1.613.220.3223 > > -----Original Message----- From: Alex Buckley > Sender: discuss-bounces at openjdk.java.net > Date: Wed, 22 Aug 2012 11:08:00 To: > Subject: Enhanced metadata in Java SE 8 > > Mike, > > These features are described by JEPs, not JSRs. Because the features > make small changes to the Java language, JVM, and java.* API, they > are being carried out under the authority of the Java SE 8 Platform > Umbrella JSR (337) as required by > http://jcp.org/en/procedures/jcp2#2.1.2. > > Alex > >> Alex, >> >> Could you please point me to the publicly-available issue tracker >> at OpenJDK for these JSRs? I can't seem to find them. >> >> Thanks. >> >>> -----Original Message----- From: announce-bounces at >>> openjdk.java.net [mailto:announce- bounces at openjdk.java.net] >>> On Behalf Of Alex Buckley Sent: August-20-12 3:13 PM To: announce >>> at openjdk.java.net Subject: Enhanced metadata in Java SE 8 >>> >>> The Compiler Group has sponsored a mailing list for the design >>> and specification of two language-level features in Java SE 8: >>> repeating annotations and method parameter reflection. More info >>> at: >>> >>> http://mail.openjdk.java.net/pipermail/compiler-dev/2012- >>> August/004636.html >>> >>> Thanks to the OpenJDK Web Site Terms of Use, this is the first >>> time that OpenJDK will host the specification of Java SE features >>> as well as their implementation. The link above mentions how >>> specification v. implementation will be divided. >>> >>> Alex > From Roger.Riggs at oracle.com Wed Aug 22 19:06:40 2012 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 22 Aug 2012 15:06:40 -0400 Subject: CFV: New Project: ThreeTen In-Reply-To: <503522AF.9090207@oracle.com> References: <503522AF.9090207@oracle.com> Message-ID: <50352DC0.1010003@oracle.com> The intention is to use the project name "ThreeTen". The extra spec in the subject line is unintentional. Roger On 8/22/2012 2:19 PM, Alex Buckley wrote: > Iris, > > Please clarify that the name of the proposed OpenJDK project is "Three > Ten", not "ThreeTen". "ThreeTen" is the SourceForge project but you > used it in the body where "Three Ten" was needed. > > Essentially, the ThreeTen project on SourceForge is going to > contribute materials to the Three Ten project on OpenJDK. > > Now that nomenclature is all cleared up (!), my main question: what > mailing lists are planned for the Three Ten project? If the JSR 310 > specification is to be "contributed" to OpenJDK, then it will > presumably need a comment-and-evaluation-licensed mailing list > separate from a GPL'd list for RI discussion. > > Alex > > On Wednesday, August 22, 2012 4:55:31 AM, Iris Clark wrote: >> I hereby propose the creation of the ThreeTen Project with Roger >> Riggs as the Lead and Core Libraries as the sponsoring Group. >> >> As discussed earlier [1], the goal of the ThreeTen Project is to >> integrate the JSR 310 Date and Time API [2] Reference Implementation >> (RI) into JDK 8 [3]. Currently, JSR 310 is hosted on SourceForge [4] >> and the source code is hosted at Github [5]. The ThreeTen Project >> will contribute the JSR 310 RI, specification, and tests to OpenJDK. >> This Project depends on other OpenJDK Projects such as Project Lambda >> and other related internationalization updates. >> >> The JSR 310 public discussion list [6] will continue to be hosted on >> SourceForge. The development of the specification, RI, and tests >> will continue on Github and be periodically merged into the ThreeTen >> Project. >> >> The proposed Project Lead is Roger Riggs, a co-spec lead of JSR 310 >> with Stephen Colebourne and Michael Nascimento Santos. Roger has >> been working in the Core Libraries Group to facilitate the >> integration of the JSR 310 RI into JDK 8. >> >> The initial committers will be: Stephen Colebourne, Sherman Shen, >> Roger Riggs, James Gough, and Richard Warburton. >> >> Votes are due by 7:00pm UTC on Wednesday, 5 September [7]. >> >> Only current OpenJDK Members [8] are eligible to vote on this >> motion. Votes must be cast in the open by replying to this mailing >> list. >> >> For Lazy Consensus voting instructions, see [9]. >> >> Thanks! >> Iris Clark >> >> [1] >> http://mail.openjdk.java.net/pipermail/discuss/2012-August/002716.html >> [2] http://jcp.org/en/jsr/detail?id=310 >> [3] http://openjdk.java.net/projects/jdk8/ >> [4] http://threeten.sourceforge.net >> [5] https://github.com/ThreeTen/threeten >> [6] https://sourceforge.net/mail/?group_id=386712 >> [7] >> http://www.timeanddate.com/worldclock/fixedtime.html?msg=ThreeTen+Project+Votes&iso=20120905T12&p1=283 >> [8] http://openjdk.java.net/census#members >> [9] http://openjdk.java.net/projects/#new-project-vote -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From iris.clark at oracle.com Wed Aug 22 21:14:35 2012 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 22 Aug 2012 14:14:35 -0700 (PDT) Subject: CFV: New Project: ThreeTen In-Reply-To: <50352DC0.1010003@oracle.com> References: <503522AF.9090207@oracle.com> <50352DC0.1010003@oracle.com> Message-ID: <970c01ba-9f03-41da-8223-967afa1a57b5@default> Hi. Yes, Roger is correct. I was clearly jet lagged when I wrote out the subject line. The JSR 310 spec leads have chosen to use alternate infrastructure for their development. The existence of a corresponding OpenJDK Project will aid in the integration of the JSR into JDK 8. Thanks, iris -----Original Message----- From: Roger Riggs Sent: Wednesday, August 22, 2012 12:07 PM To: discuss at openjdk.java.net Subject: Re: CFV: New Project: ThreeTen The intention is to use the project name "ThreeTen". The extra spec in the subject line is unintentional. Roger On 8/22/2012 2:19 PM, Alex Buckley wrote: > Iris, > > Please clarify that the name of the proposed OpenJDK project is "Three > Ten", not "ThreeTen". "ThreeTen" is the SourceForge project but you > used it in the body where "Three Ten" was needed. > > Essentially, the ThreeTen project on SourceForge is going to > contribute materials to the Three Ten project on OpenJDK. > > Now that nomenclature is all cleared up (!), my main question: what > mailing lists are planned for the Three Ten project? If the JSR 310 > specification is to be "contributed" to OpenJDK, then it will > presumably need a comment-and-evaluation-licensed mailing list > separate from a GPL'd list for RI discussion. > > Alex > > On Wednesday, August 22, 2012 4:55:31 AM, Iris Clark wrote: >> I hereby propose the creation of the ThreeTen Project with Roger >> Riggs as the Lead and Core Libraries as the sponsoring Group. >> >> As discussed earlier [1], the goal of the ThreeTen Project is to >> integrate the JSR 310 Date and Time API [2] Reference Implementation >> (RI) into JDK 8 [3]. Currently, JSR 310 is hosted on SourceForge [4] >> and the source code is hosted at Github [5]. The ThreeTen Project >> will contribute the JSR 310 RI, specification, and tests to OpenJDK. >> This Project depends on other OpenJDK Projects such as Project Lambda >> and other related internationalization updates. >> >> The JSR 310 public discussion list [6] will continue to be hosted on >> SourceForge. The development of the specification, RI, and tests >> will continue on Github and be periodically merged into the ThreeTen >> Project. >> >> The proposed Project Lead is Roger Riggs, a co-spec lead of JSR 310 >> with Stephen Colebourne and Michael Nascimento Santos. Roger has >> been working in the Core Libraries Group to facilitate the >> integration of the JSR 310 RI into JDK 8. >> >> The initial committers will be: Stephen Colebourne, Sherman Shen, >> Roger Riggs, James Gough, and Richard Warburton. >> >> Votes are due by 7:00pm UTC on Wednesday, 5 September [7]. >> >> Only current OpenJDK Members [8] are eligible to vote on this motion. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [9]. >> >> Thanks! >> Iris Clark >> >> [1] >> http://mail.openjdk.java.net/pipermail/discuss/2012-August/002716.htm >> l [2] http://jcp.org/en/jsr/detail?id=310 >> [3] http://openjdk.java.net/projects/jdk8/ >> [4] http://threeten.sourceforge.net >> [5] https://github.com/ThreeTen/threeten >> [6] https://sourceforge.net/mail/?group_id=386712 >> [7] >> http://www.timeanddate.com/worldclock/fixedtime.html?msg=ThreeTen+Pro >> ject+Votes&iso=20120905T12&p1=283 [8] >> http://openjdk.java.net/census#members >> [9] http://openjdk.java.net/projects/#new-project-vote -- Thanks, Roger Oracle Java Platform Group Green Oracle Oracle is committed to developing practices and products that help protect the environment From mark.reinhold at oracle.com Wed Aug 22 21:24:16 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 22 Aug 2012 14:24:16 -0700 Subject: Enhanced metadata in Java SE 8 In-Reply-To: mike.milinkovich@eclipse.org; Wed, 22 Aug 2012 18:34:44 -0000; <1811612810-1345660487-cardhu_decombobulator_blackberry.rim.net-796066213-@b3.c18.bise6.blackberry> Message-ID: <20120822212416.92B86AB4@eggemoggin.niobe.net> 2012/8/22 11:34 -0700, mike.milinkovich at eclipse.org: > Further, my reading of the transparency requirements in the 2.8 process > _require_ an open issue tracker if the spec work is hosted > elsewhere. Am I reading it wrong? No, I don't think so (except maybe that a JSR needs an issue tracker no matter where it's hosted). > I'm not trying to be a problem child. I think doing spec and RI work in > parallel and in open source is the right way to go. I just don't get > how this intersection of JCP and OpenJDK processes actually works. These tiny language changes don't merit a JSR of their own, so they'll be covered directly in the Java SE 8 umbrella JSR (337) [1]. Discussion of these changes will take place on the evaluation-and-comment list Alex mentioned earlier [2]. To answer your next question, JSR 337 was originally submitted under JCP 2.7 and has yet to convert to JCP 2.8 and its stronger transparency requirements. A giant step toward that was taken with the installation of the new OpenJDK Terms of Use [3]. As soon as I settle a couple of other details I'll ask the JCP PMO to convert JSR 337 to JCP 2.8. - Mark [1] http://openjdk.java.net/projects/jdk8/spec/ [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2012-August/004636.html [3] http://openjdk.java.net/legal/tou/ From Lee.Howes at amd.com Wed Aug 22 21:39:35 2012 From: Lee.Howes at amd.com (Howes, Lee) Date: Wed, 22 Aug 2012 21:39:35 +0000 Subject: Project Proposal: GPU support Message-ID: <5E3D9627421424498670FBDDE0E9AFEA1D0740@storexdag03.amd.com> Hi John and discuss list members, As Gary mentioned below it would be very interesting to have more engineers from AMD contribute to this project and I'd be interested in taking part on some level. We can discuss later what this means in terms of a time commitment. Lee Howes Gary Frost wrote: > Thanks John, > > On behalf of AMD I'd like to confirm we're very interested in this project and looking forward to fully participating. We would be happy to have some of our engineers be Committers on this project. > > Gary Frost From eric.caspole at amd.com Wed Aug 22 21:55:40 2012 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 22 Aug 2012 17:55:40 -0400 Subject: Project Proposal: GPU support In-Reply-To: <5E3D9627421424498670FBDDE0E9AFEA1D0740@storexdag03.amd.com> References: <5E3D9627421424498670FBDDE0E9AFEA1D0740@storexdag03.amd.com> Message-ID: I am interested in working on this project as well. Regards, Eric Caspole On Aug 22, 2012, at 5:39 PM, Howes, Lee wrote: > Hi John and discuss list members, > As Gary mentioned below it would be very interesting to have more > engineers from AMD contribute to this project and I'd be interested > in taking part on some level. We can discuss later what this means > in terms of a time commitment. > > Lee Howes > > Gary Frost wrote: >> Thanks John, >> >> On behalf of AMD I'd like to confirm we're very interested in this >> project and looking forward to fully participating. We would be >> happy to have some of our engineers be Committers on this project. >> >> Gary Frost > From jmaxg3 at gmail.com Sat Aug 25 04:57:53 2012 From: jmaxg3 at gmail.com (Max Grossman) Date: Fri, 24 Aug 2012 23:57:53 -0500 Subject: OpenJDK GPU Project Message-ID: I'm also interested in working on the GPU project proposed in [1]. Who can I talk to about getting involved? Thanks, Max Grossman Rice University jmg3.web.rice.edu 1. http://mail.openjdk.java.net/pipermail/discuss/2012-August/002717.html From henri.gomez at gmail.com Tue Aug 28 09:45:51 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 28 Aug 2012 11:45:51 +0200 Subject: OpenJDK and gcc options on Linux Message-ID: Hi to all, I'm doing a POC with OpenJDK build (7 and highers) for various Linux distributions, CentOS/RHEL, OpenSuse/SLES. I'm wondering what gcc/g++ options your using on Linux to get best performance available ? >From logs, it seems more than basic by default : g++ -DLINUX -D_GNU_SOURCE -DIA32 -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/prims -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/precompiled -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/cpu/x86/vm -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/os_cpu/linux_x86/vm -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/os/linux/vm -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/os/posix/vm -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/adlc -I../generated -DASSERT -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 -march=i586 -pipe -Werror -g -c -o ../generated/adfiles/archDesc.o /home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/adlc/archDesc.cpp ... /usr/bin/gcc -g -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-b53"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -c -o /home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/obj/check_code.o ../../../src/share/native/common/check_code.c /usr/bin/gcc -g -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-b53"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -c -o /home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/obj/check_format.o ../../../src/share/native/common/check_format.c make[5]: Leaving directory `/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/jdk/make/java/verify' On OSX, much more gcc options are in use : /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-b53"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/verify/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -c -o /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/verify/obj64/check_format.o ../../../src/share/native/common/check_format.c Cheers From henri.gomez at gmail.com Tue Aug 28 09:48:25 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 28 Aug 2012 11:48:25 +0200 Subject: OpenJDK and gcc options on Linux In-Reply-To: References: Message-ID: To resume, what are your CFLAGS and CPPFLAGS options on Linux :-) 2012/8/28 Henri Gomez : > Hi to all, > > I'm doing a POC with OpenJDK build (7 and highers) for various Linux > distributions, CentOS/RHEL, OpenSuse/SLES. > > I'm wondering what gcc/g++ options your using on Linux to get best > performance available ? > > From logs, it seems more than basic by default : > > g++ -DLINUX -D_GNU_SOURCE -DIA32 > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/prims > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/precompiled > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/cpu/x86/vm > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/os_cpu/linux_x86/vm > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/os/linux/vm > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/os/posix/vm > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/adlc > -I../generated -DASSERT -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 > -DTARGET_ARCH_MODEL_x86_32 -DTARGET_OS_ARCH_linux_x86 > -DTARGET_OS_ARCH_MODEL_linux_x86_32 -DTARGET_COMPILER_gcc -DCOMPILER2 > -DCOMPILER1 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new > -fvisibility=hidden -m32 -march=i586 -pipe -Werror -g -c -o > ../generated/adfiles/archDesc.o > /home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/hotspot/src/share/vm/adlc/archDesc.cpp > > ... > > /usr/bin/gcc -g -O2 -fno-strict-aliasing -fPIC -W -Wall > -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-b53"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/CClassHeaders > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -c -o > /home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/obj/check_code.o > ../../../src/share/native/common/check_code.c > /usr/bin/gcc -g -O2 -fno-strict-aliasing -fPIC -W -Wall > -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-b53"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. > -I/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/CClassHeaders > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -c -o > /home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/build/linux-i586/tmp/java/verify/obj/check_format.o > ../../../src/share/native/common/check_format.c > make[5]: Leaving directory > `/home/cijenka/workspace/openjdk8-standard-build/noarch/opensuse12-i386-builder/jdk/make/java/verify' > > > On OSX, much more gcc options are in use : > > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-b53"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > -D_REENTRANT -DMACOSX -D_LP64=1 -I. > -I/Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/verify/CClassHeaders > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -c -o > /Users/henri/Documents/jenkins/data/jobs/openjdk-jdk8-jdk8/workspace/build/macosx-x86_64/tmp/java/verify/obj64/check_format.o > ../../../src/share/native/common/check_format.c > > Cheers From dalibor.topic at oracle.com Tue Aug 28 11:34:46 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Tue, 28 Aug 2012 13:34:46 +0200 Subject: OpenJDK and gcc options on Linux In-Reply-To: References: Message-ID: <503CACD6.80405@oracle.com> On 8/28/12 11:45 AM, Henri Gomez wrote: > I'm wondering what gcc/g++ options your using on Linux to get best > performance available ? Whatever the build system chooses should be fine. For the alternative, see [0]. cheers, dalibor topic [0] http://funroll-loops.info/ -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz 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 henri.gomez at gmail.com Tue Aug 28 12:16:23 2012 From: henri.gomez at gmail.com (Henri Gomez) Date: Tue, 28 Aug 2012 14:16:23 +0200 Subject: OpenJDK and gcc options on Linux In-Reply-To: <503CACD6.80405@oracle.com> References: <503CACD6.80405@oracle.com> Message-ID: >> I'm wondering what gcc/g++ options your using on Linux to get best >> performance available ? > > Whatever the build system chooses should be fine. For the alternative, > see [0]. Interesting link I was wondering about using -Os on Linux. From me at alcidesfonseca.com Wed Aug 29 01:02:54 2012 From: me at alcidesfonseca.com (Alcides Fonseca) Date: Wed, 29 Aug 2012 02:02:54 +0100 Subject: Project Proposal: GPU support Message-ID: <044D55A2-ABA0-4068-96EE-D424F63C3B9A@alcidesfonseca.com> Hi everyone, I am also interesting in participating on this project. In my masters thesis I developed ?miniumGPU[1] a GPU-backed Map-Reduce library for Java (and ?minium[2], a JVM-based language). My approach differs from the ones proposed in which it is a Source-to-Source compiler that takes Java source code, looks up for the lambda functions of higher-order functions (map, reduce and a couple others) and translates them to OpenCL functions. At runtime these functions are integrated in kernel templates (one for map, other for reduce, ?) and executed using the JavaCL library. Another of the novel features is that it automatically decides if a given operation will be executed on the CPU or on the CPU. We have both a regression solution as well as Machine Learning classification systems. This is something that might be interesting to include in the Java solution, even if it is bytecode-based. ? Alcides Fonseca PhD Student Invited Assistent University of Coimbra [1] https://github.com/aeminium/AeminiumGPU and https://github.com/aeminium/AeminiumGPUCompiler [2] https://github.com/aeminium/AeminiumGPUCompiler From Alan.Bateman at oracle.com Wed Aug 29 08:49:51 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Aug 2012 09:49:51 +0100 Subject: CFV: New Project: Three Ten In-Reply-To: References: Message-ID: <503DD7AF.7050707@oracle.com> Vote: yes From neugens.limasoftware at gmail.com Wed Aug 29 09:04:52 2012 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 29 Aug 2012 11:04:52 +0200 Subject: CFV: New Project: Three Ten In-Reply-To: References: Message-ID: Vote: Yes Cheers, Mario 2012/8/22 Iris Clark : > I hereby propose the creation of the ThreeTen Project with Roger Riggs as the Lead and Core Libraries as the sponsoring Group. > > As discussed earlier [1], the goal of the ThreeTen Project is to integrate the JSR 310 Date and Time API [2] Reference Implementation (RI) into JDK 8 [3]. Currently, JSR 310 is hosted on SourceForge [4] and the source code is hosted at Github [5]. The ThreeTen Project will contribute the JSR 310 RI, specification, and tests to OpenJDK. This Project depends on other OpenJDK Projects such as Project Lambda and other related internationalization updates. > > The JSR 310 public discussion list [6] will continue to be hosted on SourceForge. The development of the specification, RI, and tests will continue on Github and be periodically merged into the ThreeTen Project. > > The proposed Project Lead is Roger Riggs, a co-spec lead of JSR 310 with Stephen Colebourne and Michael Nascimento Santos. Roger has been working in the Core Libraries Group to facilitate the integration of the JSR 310 RI into JDK 8. > > The initial committers will be: Stephen Colebourne, Sherman Shen, Roger Riggs, James Gough, and Richard Warburton. > > Votes are due by 7:00pm UTC on Wednesday, 5 September [7]. > > Only current OpenJDK Members [8] are eligible to vote on this motion. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [9]. > > Thanks! > Iris Clark > > [1] http://mail.openjdk.java.net/pipermail/discuss/2012-August/002716.html > [2] http://jcp.org/en/jsr/detail?id=310 > [3] http://openjdk.java.net/projects/jdk8/ > [4] http://threeten.sourceforge.net > [5] https://github.com/ThreeTen/threeten > [6] https://sourceforge.net/mail/?group_id=386712 > [7] http://www.timeanddate.com/worldclock/fixedtime.html?msg=ThreeTen+Project+Votes&iso=20120905T12&p1=283 > [8] http://openjdk.java.net/census#members > [9] http://openjdk.java.net/projects/#new-project-vote -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From scolebourne at joda.org Wed Aug 29 09:05:36 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 29 Aug 2012 10:05:36 +0100 Subject: CFV: New Project: Three Ten In-Reply-To: <503DD7AF.7050707@oracle.com> References: <503DD7AF.7050707@oracle.com> Message-ID: I vote yes (to whatever extent I am allowed to vote) Stephen On 29 August 2012 09:49, Alan Bateman wrote: > Vote: yes From jeff.dinkins at oracle.com Wed Aug 29 15:09:33 2012 From: jeff.dinkins at oracle.com (Jeff Dinkins) Date: Wed, 29 Aug 2012 08:09:33 -0700 Subject: CFV: New Project: Three Ten In-Reply-To: References: Message-ID: Vote: yes From xueming.shen at oracle.com Wed Aug 29 16:41:51 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 29 Aug 2012 09:41:51 -0700 Subject: CFV: New Project: Three Ten In-Reply-To: References: Message-ID: <503E464F.6010503@oracle.com> Vote: yes From Ivan.Krylov at amd.com Thu Aug 30 15:21:27 2012 From: Ivan.Krylov at amd.com (Krylov, Ivan) Date: Thu, 30 Aug 2012 15:21:27 +0000 Subject: Project Proposal: GPU support In-Reply-To: <044D55A2-ABA0-4068-96EE-D424F63C3B9A@alcidesfonseca.com> References: <044D55A2-ABA0-4068-96EE-D424F63C3B9A@alcidesfonseca.com> Message-ID: <1B31AD29CB96D346B2AF4C1AB7902CD00742DD@storexdag04.amd.com> Hello, I am interested in participating in this project. Thanks, Ivan From dalibor.topic at oracle.com Thu Aug 30 17:44:28 2012 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 30 Aug 2012 19:44:28 +0200 Subject: CFV: New Project: Three Ten In-Reply-To: References: Message-ID: <503FA67C.5010109@oracle.com> Vote: Yes. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz 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