From gnu.andrew at redhat.com Wed Mar 13 19:19:45 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 22:19:45 -0400 (EDT) Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <5114CABE.3070809@oracle.com> Message-ID: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> ----- Original Message ----- > The build part of this review looks good to me. > Judging by this changeset, I gather javazic is no longer being run. If so, why is the source code being retained in the tree? It means that a build of OpenJDK against itself now fails. The new build system currently finds the javazic source code and tries to compile it, but fails because ZoneInfoFile.java has changed and Gen.java can no longer compile against it. Deleting the javazic source code fixes the build. Any reason not to commit this? http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > /Erik > > On 2013-02-07 19:31, Xueming Shen wrote: > > Hi, > > > > 8007572: Replace existing jdk timezone data at /lib/zi > > with > > JSR310's tzdb. > > > > Webrev: > > http://cr.openjdk.java.net/~sherman/8007572/ > > > > Note: > > JDK/JRE has been using the time zone data at /lib/zi for > > j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own > > time zone data file/format lib/tzdb.jar to provide the > > time > > zone data support for its new java.time date-time classes. > > > > So we now have two different time zone data files in different > > formats > > (though from the same time zone data source, Olson tz data, now the > > IANA > > Time Zone Datebase) to support two sets of date-time APIs > > (java.util > > date-time classes and java.time date-time classes) in one JDK/JRE, > > which > > definitely will add the maintenance burden going forward, given the > > fact > > that we will have to update/distribute the latest tzdb data in > > JDK/JRE > > periodically [2]. > > > > Also the current way the time-zone data is being > > distributed/installed > > (at /lib.zi, as individual file for each time zone) has > > been > > a footprint concern for some configurations, especially the small > > embedded > > environment. The JEP151 [3] was originally submitted to propose to > > store > > the time-zone data more efficiently into a single compressed file. > > The > > JEP 151 has been withdrawn since, with the assumption that JDK 8 > > may > > replace the "zi" data with the much smaller JSR310 tzdb data file. > > > > As indicated in JEP151, current installed "zi" directory probably > > takes > > up 1M of disk-space with the 0.5k default file-system-block-size. > > Even > > with the proposed "store in one single compressed file" approach, > > it will > > still take about 250K space for all tzdb data in "zi" directory. > > JSR310 > > tzdb data file however is much smaller. It is around 40K for > > compressed > > and 100k uncompressed, for the same tz data. > > > > The proposed change is to share the JSR310 time zone data tzdb.jar > > with j.u.TimeZone by converting the JSR310 tzdb data completely > > (bits > > to bits compatible) at runtime into the internal data structure > > that > > j.u.TimeZone needs for its time zone data functionality/needs. > > > > Thanks! > > -Sherman > > > > [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 > > [2] > > http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html > > [3] http://openjdk.java.net/jeps/151 > -- 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 xueming.shen at oracle.com Wed Mar 13 19:51:45 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Mar 2013 19:51:45 -0700 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> Message-ID: <51413B41.4010305@oracle.com> This should have been addessed via JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control job* -Sherman On 3/13/13 7:19 PM, Andrew Hughes wrote: > ----- Original Message ----- >> The build part of this review looks good to me. >> > Judging by this changeset, I gather javazic is no longer being run. > If so, why is the source code being retained in the tree? It means > that a build of OpenJDK against itself now fails. The new > build system currently finds the javazic source code and tries to compile it, > but fails because ZoneInfoFile.java has changed and Gen.java can no longer > compile against it. Deleting the javazic source code fixes the > build. > > Any reason not to commit this? > > http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > >> /Erik >> >> On 2013-02-07 19:31, Xueming Shen wrote: >>> Hi, >>> >>> 8007572: Replace existing jdk timezone data at /lib/zi >>> with >>> JSR310's tzdb. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sherman/8007572/ >>> >>> Note: >>> JDK/JRE has been using the time zone data at /lib/zi for >>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>> time zone data file/format lib/tzdb.jar to provide the >>> time >>> zone data support for its new java.time date-time classes. >>> >>> So we now have two different time zone data files in different >>> formats >>> (though from the same time zone data source, Olson tz data, now the >>> IANA >>> Time Zone Datebase) to support two sets of date-time APIs >>> (java.util >>> date-time classes and java.time date-time classes) in one JDK/JRE, >>> which >>> definitely will add the maintenance burden going forward, given the >>> fact >>> that we will have to update/distribute the latest tzdb data in >>> JDK/JRE >>> periodically [2]. >>> >>> Also the current way the time-zone data is being >>> distributed/installed >>> (at /lib.zi, as individual file for each time zone) has >>> been >>> a footprint concern for some configurations, especially the small >>> embedded >>> environment. The JEP151 [3] was originally submitted to propose to >>> store >>> the time-zone data more efficiently into a single compressed file. >>> The >>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>> may >>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>> >>> As indicated in JEP151, current installed "zi" directory probably >>> takes >>> up 1M of disk-space with the 0.5k default file-system-block-size. >>> Even >>> with the proposed "store in one single compressed file" approach, >>> it will >>> still take about 250K space for all tzdb data in "zi" directory. >>> JSR310 >>> tzdb data file however is much smaller. It is around 40K for >>> compressed >>> and 100k uncompressed, for the same tz data. >>> >>> The proposed change is to share the JSR310 time zone data tzdb.jar >>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>> (bits >>> to bits compatible) at runtime into the internal data structure >>> that >>> j.u.TimeZone needs for its time zone data functionality/needs. >>> >>> Thanks! >>> -Sherman >>> >>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>> [2] >>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>> [3] http://openjdk.java.net/jeps/151 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130313/dc4e5d17/attachment.html From david.holmes at oracle.com Wed Mar 13 21:26:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 14:26:28 +1000 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <51415174.5010309@oracle.com> On 14/03/2013 12:51 PM, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* Which is still in the tl repo and unlikely to reach jdk8/jdk8 till b82 promotion next week. David > -Sherman > > On 3/13/13 7:19 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> The build part of this review looks good to me. >>> >> Judging by this changeset, I gather javazic is no longer being run. >> If so, why is the source code being retained in the tree? It means >> that a build of OpenJDK against itself now fails. The new >> build system currently finds the javazic source code and tries to >> compile it, >> but fails because ZoneInfoFile.java has changed and Gen.java can no >> longer >> compile against it. Deleting the javazic source code fixes the >> build. >> >> Any reason not to commit this? >> >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ >> >>> /Erik >>> >>> On 2013-02-07 19:31, Xueming Shen wrote: >>>> Hi, >>>> >>>> 8007572: Replace existing jdk timezone data at /lib/zi >>>> with >>>> JSR310's tzdb. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sherman/8007572/ >>>> >>>> Note: >>>> JDK/JRE has been using the time zone data at /lib/zi for >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its own >>>> time zone data file/format lib/tzdb.jar to provide the >>>> time >>>> zone data support for its new java.time date-time classes. >>>> >>>> So we now have two different time zone data files in different >>>> formats >>>> (though from the same time zone data source, Olson tz data, now the >>>> IANA >>>> Time Zone Datebase) to support two sets of date-time APIs >>>> (java.util >>>> date-time classes and java.time date-time classes) in one JDK/JRE, >>>> which >>>> definitely will add the maintenance burden going forward, given the >>>> fact >>>> that we will have to update/distribute the latest tzdb data in >>>> JDK/JRE >>>> periodically [2]. >>>> >>>> Also the current way the time-zone data is being >>>> distributed/installed >>>> (at /lib.zi, as individual file for each time zone) has >>>> been >>>> a footprint concern for some configurations, especially the small >>>> embedded >>>> environment. The JEP151 [3] was originally submitted to propose to >>>> store >>>> the time-zone data more efficiently into a single compressed file. >>>> The >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 >>>> may >>>> replace the "zi" data with the much smaller JSR310 tzdb data file. >>>> >>>> As indicated in JEP151, current installed "zi" directory probably >>>> takes >>>> up 1M of disk-space with the 0.5k default file-system-block-size. >>>> Even >>>> with the proposed "store in one single compressed file" approach, >>>> it will >>>> still take about 250K space for all tzdb data in "zi" directory. >>>> JSR310 >>>> tzdb data file however is much smaller. It is around 40K for >>>> compressed >>>> and 100k uncompressed, for the same tz data. >>>> >>>> The proposed change is to share the JSR310 time zone data tzdb.jar >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely >>>> (bits >>>> to bits compatible) at runtime into the internal data structure >>>> that >>>> j.u.TimeZone needs for its time zone data functionality/needs. >>>> >>>> Thanks! >>>> -Sherman >>>> >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 >>>> [2] >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html >>>> >>>> [3] http://openjdk.java.net/jeps/151 > From Alan.Bateman at oracle.com Wed Mar 13 23:47:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 06:47:09 +0000 Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51413B41.4010305@oracle.com> References: <1163719046.18271878.1363227585008.JavaMail.root@redhat.com> <51413B41.4010305@oracle.com> Message-ID: <5141726D.2090107@oracle.com> On 14/03/2013 02:51, Xueming Shen wrote: > This should have been addessed via > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build problems > with hs25-b19 control job* > > Right, this was fixed several weeks ago with: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3 There are a lot of changes backed up in jdk8/tl due to several issues. Lana Steuck will be integrating them into jdk8/jdk8 soon. -Alan. From gnu.andrew at redhat.com Thu Mar 14 09:10:14 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 12:10:14 -0400 (EDT) Subject: [JSR310 M7 Review request] 8007572: Replace existing jdk timezone data at /lib/zi with JSR310's tzdb. In-Reply-To: <51415174.5010309@oracle.com> Message-ID: <155408043.18863217.1363277414103.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 12:51 PM, Xueming Shen wrote: > > This should have been addessed via > > > > JDK-8008348 *The leftover jdk/make/tools/javazic causes build > > problems > > with hs25-b19 control job* > > > > Which is still in the tl repo and unlikely to reach jdk8/jdk8 till > b82 > promotion next week. > Yep, that's exactly why I'm seeing it. This is in an IcedTea build using the latest build drop, b80. Glad it's been caught and dealt with :) > David > > > -Sherman > > > > On 3/13/13 7:19 PM, Andrew Hughes wrote: > >> ----- Original Message ----- > >>> The build part of this review looks good to me. > >>> > >> Judging by this changeset, I gather javazic is no longer being > >> run. > >> If so, why is the source code being retained in the tree? It > >> means > >> that a build of OpenJDK against itself now fails. The new > >> build system currently finds the javazic source code and tries to > >> compile it, > >> but fails because ZoneInfoFile.java has changed and Gen.java can > >> no > >> longer > >> compile against it. Deleting the javazic source code fixes the > >> build. > >> > >> Any reason not to commit this? > >> > >> http://cr.openjdk.java.net/~andrew/build/javazic/webrev.01/ > >> > >>> /Erik > >>> > >>> On 2013-02-07 19:31, Xueming Shen wrote: > >>>> Hi, > >>>> > >>>> 8007572: Replace existing jdk timezone data at > >>>> /lib/zi > >>>> with > >>>> JSR310's tzdb. > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~sherman/8007572/ > >>>> > >>>> Note: > >>>> JDK/JRE has been using the time zone data at /lib/zi > >>>> for > >>>> j.u.TimeZone since JDK 1.4.0 [1]. JSR310 has introduced in its > >>>> own > >>>> time zone data file/format lib/tzdb.jar to provide > >>>> the > >>>> time > >>>> zone data support for its new java.time date-time classes. > >>>> > >>>> So we now have two different time zone data files in different > >>>> formats > >>>> (though from the same time zone data source, Olson tz data, now > >>>> the > >>>> IANA > >>>> Time Zone Datebase) to support two sets of date-time APIs > >>>> (java.util > >>>> date-time classes and java.time date-time classes) in one > >>>> JDK/JRE, > >>>> which > >>>> definitely will add the maintenance burden going forward, given > >>>> the > >>>> fact > >>>> that we will have to update/distribute the latest tzdb data in > >>>> JDK/JRE > >>>> periodically [2]. > >>>> > >>>> Also the current way the time-zone data is being > >>>> distributed/installed > >>>> (at /lib.zi, as individual file for each time zone) > >>>> has > >>>> been > >>>> a footprint concern for some configurations, especially the > >>>> small > >>>> embedded > >>>> environment. The JEP151 [3] was originally submitted to propose > >>>> to > >>>> store > >>>> the time-zone data more efficiently into a single compressed > >>>> file. > >>>> The > >>>> JEP 151 has been withdrawn since, with the assumption that JDK 8 > >>>> may > >>>> replace the "zi" data with the much smaller JSR310 tzdb data > >>>> file. > >>>> > >>>> As indicated in JEP151, current installed "zi" directory > >>>> probably > >>>> takes > >>>> up 1M of disk-space with the 0.5k default > >>>> file-system-block-size. > >>>> Even > >>>> with the proposed "store in one single compressed file" > >>>> approach, > >>>> it will > >>>> still take about 250K space for all tzdb data in "zi" directory. > >>>> JSR310 > >>>> tzdb data file however is much smaller. It is around 40K for > >>>> compressed > >>>> and 100k uncompressed, for the same tz data. > >>>> > >>>> The proposed change is to share the JSR310 time zone data > >>>> tzdb.jar > >>>> with j.u.TimeZone by converting the JSR310 tzdb data completely > >>>> (bits > >>>> to bits compatible) at runtime into the internal data structure > >>>> that > >>>> j.u.TimeZone needs for its time zone data functionality/needs. > >>>> > >>>> Thanks! > >>>> -Sherman > >>>> > >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-4230123 > >>>> [2] > >>>> http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html > >>>> > >>>> [3] http://openjdk.java.net/jeps/151 > > > -- 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 mvyskocil at suse.cz Fri Mar 22 03:09:54 2013 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Fri, 22 Mar 2013 11:09:54 +0100 Subject: Two AArch64-related patches Message-ID: <20130322100954.GD31002@linux-xtv2.site> Hi all, I'm a maintainer of openjdk for SUSE and recently I've got two patches from our AArch64 team for openjdk7. I have no idea if porting of openjdk7 is important for this group, but it is probably better to try it. Regards Michal Vyskocil -------------- next part -------------- A non-text attachment was scrubbed... Name: java-1.7.0-openjdk-aarch64.patch Type: text/x-patch Size: 1217 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130322/bc630d76/java-1.7.0-openjdk-aarch64.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: java-1.7.0-openjdk-fork.patch Type: text/x-patch Size: 1787 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20130322/bc630d76/java-1.7.0-openjdk-fork.patch From aph at redhat.com Fri Mar 22 03:43:01 2013 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Mar 2013 10:43:01 +0000 Subject: Two AArch64-related patches Message-ID: <514C35B5.1080804@redhat.com> Michal Vyskocil writes: > I'm a maintainer of openjdk for SUSE and recently I've got two patches > from our AArch64 team for openjdk7. I have no idea if porting of > openjdk7 is important for this group, but it is probably better to try > it. You may be aware that there is an AArch64 porting project. Mailing List aarch64-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/aarch64-dev The actual source code still isn't there, but hopefully will be as soon as we get all the legal details sorted out. Now for the patch itself: > --- icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > +++ icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > @@ -1893,7 +1893,8 @@ void * os::dll_load(const char *filename > {EM_MIPS, EM_MIPS, ELFCLASS32, ELFDATA2MSB, (char*)"MIPS"}, > {EM_PARISC, EM_PARISC, ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"}, > {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"}, > - {EM_SH, EM_SH, ELFCLASS32, ELFDATA2LSB, (char*)"SH"} /* Support little endian only*/ > + {EM_SH, EM_SH, ELFCLASS32, ELFDATA2LSB, (char*)"SH"}, /* Support little endian only*/ > + {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"} /* Support little endian only*/ > }; > > #if (defined IA32) > @@ -1926,6 +1927,8 @@ void * os::dll_load(const char *filename > static Elf32_Half running_arch_code=EM_68K; > #elif (defined SH) > static Elf32_Half running_arch_code=EM_SH; > + #elif (defined AARCH64) > + static Elf32_Half running_arch_code=EM_AARCH64; > #else > #error Method os::dll_load requires that one of following is defined:\ > IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, ALPHA, MIPS, MIPSEL, PARISC, M68K, SH This part seems reasonable. > --- icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > +++ icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > @@ -5374,14 +5374,6 @@ void Parker::unpark() { > > extern char** environ; > > -#ifndef __NR_fork > -#define __NR_fork IA32_ONLY(2) IA64_ONLY(not defined) AMD64_ONLY(57) > -#endif > - > -#ifndef __NR_execve > -#define __NR_execve IA32_ONLY(11) IA64_ONLY(1033) AMD64_ONLY(59) > -#endif > - > // Run the specified command in a separate process. Return its exit value, > // or -1 on failure (e.g. can't fork a new process). > // Unlike system(), this function can be called from signal handler. It > @@ -5392,10 +5384,11 @@ int os::fork_and_exec(char* cmd) { > // fork() in LinuxThreads/NPTL is not async-safe. It needs to run > // pthread_atfork handlers and reset pthread library. All we need is a > // separate process to execve. Make a direct syscall to fork process. > - // On IA64 there's no fork syscall, we have to use fork() and hope for > - // the best... > - pid_t pid = NOT_IA64(syscall(__NR_fork);) > - IA64_ONLY(fork();) > +#ifdef SYS_fork > + pid_t pid = syscall(SYS_fork); > +#else > + pid_t pid = syscall(SYS_clone, SIGCHLD, 0, 0, 0, 0); > +#endif > > if (pid < 0) { > // fork failed > @@ -5409,10 +5402,7 @@ int os::fork_and_exec(char* cmd) { > // not reset by fork() (see notes above), execve() will instead kill > // every thread in the parent process. We know this is the only thread > // in the new process, so make a system call directly. > - // IA64 should use normal execve() from glibc to match the glibc fork() > - // above. > - NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) > - IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) > + syscall(SYS_execve, "/bin/sh", argv, environ); > > // execve failed > _exit(-1); Why have you deleted the IA-64 code? Andrew. From mvyskocil at suse.cz Fri Mar 22 04:32:46 2013 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Fri, 22 Mar 2013 12:32:46 +0100 Subject: Two AArch64-related patches In-Reply-To: <514C35B5.1080804@redhat.com> References: <514C35B5.1080804@redhat.com> Message-ID: <20130322113246.GE31002@linux-xtv2.site> On Fri, Mar 22, 2013 at 10:43:01AM +0000, Andrew Haley wrote: > Michal Vyskocil writes: > > > I'm a maintainer of openjdk for SUSE and recently I've got two patches > > from our AArch64 team for openjdk7. I have no idea if porting of > > openjdk7 is important for this group, but it is probably better to try > > it. > > You may be aware that there is an AArch64 porting project. > > Mailing List > aarch64-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/aarch64-dev > > The actual source code still isn't there, but hopefully will be as > soon as we get all the legal details sorted out. > > Now for the patch itself: > > > --- icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > +++ icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > @@ -1893,7 +1893,8 @@ void * os::dll_load(const char *filename > > {EM_MIPS, EM_MIPS, ELFCLASS32, ELFDATA2MSB, (char*)"MIPS"}, > > {EM_PARISC, EM_PARISC, ELFCLASS32, ELFDATA2MSB, (char*)"PARISC"}, > > {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, (char*)"M68k"}, > > - {EM_SH, EM_SH, ELFCLASS32, ELFDATA2LSB, (char*)"SH"} /* Support little endian only*/ > > + {EM_SH, EM_SH, ELFCLASS32, ELFDATA2LSB, (char*)"SH"}, /* Support little endian only*/ > > + {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"} /* Support little endian only*/ > > }; > > > > #if (defined IA32) > > @@ -1926,6 +1927,8 @@ void * os::dll_load(const char *filename > > static Elf32_Half running_arch_code=EM_68K; > > #elif (defined SH) > > static Elf32_Half running_arch_code=EM_SH; > > + #elif (defined AARCH64) > > + static Elf32_Half running_arch_code=EM_AARCH64; > > #else > > #error Method os::dll_load requires that one of following is defined:\ > > IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, ALPHA, MIPS, MIPSEL, PARISC, M68K, SH > > This part seems reasonable. > > > --- icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > +++ icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > @@ -5374,14 +5374,6 @@ void Parker::unpark() { > > > > extern char** environ; > > > > -#ifndef __NR_fork > > -#define __NR_fork IA32_ONLY(2) IA64_ONLY(not defined) AMD64_ONLY(57) > > -#endif > > - > > -#ifndef __NR_execve > > -#define __NR_execve IA32_ONLY(11) IA64_ONLY(1033) AMD64_ONLY(59) > > -#endif > > - > > // Run the specified command in a separate process. Return its exit value, > > // or -1 on failure (e.g. can't fork a new process). > > // Unlike system(), this function can be called from signal handler. It > > @@ -5392,10 +5384,11 @@ int os::fork_and_exec(char* cmd) { > > // fork() in LinuxThreads/NPTL is not async-safe. It needs to run > > // pthread_atfork handlers and reset pthread library. All we need is a > > // separate process to execve. Make a direct syscall to fork process. > > - // On IA64 there's no fork syscall, we have to use fork() and hope for > > - // the best... > > - pid_t pid = NOT_IA64(syscall(__NR_fork);) > > - IA64_ONLY(fork();) > > +#ifdef SYS_fork > > + pid_t pid = syscall(SYS_fork); > > +#else > > + pid_t pid = syscall(SYS_clone, SIGCHLD, 0, 0, 0, 0); > > +#endif > > > > if (pid < 0) { > > // fork failed > > @@ -5409,10 +5402,7 @@ int os::fork_and_exec(char* cmd) { > > // not reset by fork() (see notes above), execve() will instead kill > > // every thread in the parent process. We know this is the only thread > > // in the new process, so make a system call directly. > > - // IA64 should use normal execve() from glibc to match the glibc fork() > > - // above. > > - NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) > > - IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) > > + syscall(SYS_execve, "/bin/sh", argv, environ); > > > > // execve failed > > _exit(-1); > > Why have you deleted the IA-64 code? I've forgot to add an original author into CC, fixed now. Andreas, please comment Regards Michal Vyskocil > > Andrew. From gnu.andrew at redhat.com Mon Mar 25 14:47:58 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Mar 2013 17:47:58 -0400 (EDT) Subject: Two AArch64-related patches In-Reply-To: <514C35B5.1080804@redhat.com> Message-ID: <552628385.23675722.1364248078742.JavaMail.root@redhat.com> ----- Original Message ----- > Michal Vyskocil writes: > > > I'm a maintainer of openjdk for SUSE and recently I've got two > > patches > > from our AArch64 team for openjdk7. I have no idea if porting of > > openjdk7 is important for this group, but it is probably better to > > try > > it. > > You may be aware that there is an AArch64 porting project. > > Mailing List > aarch64-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/aarch64-dev > > The actual source code still isn't there, but hopefully will be as > soon as we get all the legal details sorted out. > Is there an intention to backport the AArch64 port to 7? > Now for the patch itself: > > > --- icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > +++ icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > @@ -1893,7 +1893,8 @@ void * os::dll_load(const char *filename > > {EM_MIPS, EM_MIPS, ELFCLASS32, ELFDATA2MSB, > > (char*)"MIPS"}, > > {EM_PARISC, EM_PARISC, ELFCLASS32, ELFDATA2MSB, > > (char*)"PARISC"}, > > {EM_68K, EM_68K, ELFCLASS32, ELFDATA2MSB, > > (char*)"M68k"}, > > - {EM_SH, EM_SH, ELFCLASS32, ELFDATA2LSB, > > (char*)"SH"} /* Support little endian only*/ > > + {EM_SH, EM_SH, ELFCLASS32, ELFDATA2LSB, > > (char*)"SH"}, /* Support little endian only*/ > > + {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, > > (char*)"AARCH64"} /* Support little endian only*/ > > }; > > > > #if (defined IA32) > > @@ -1926,6 +1927,8 @@ void * os::dll_load(const char *filename > > static Elf32_Half running_arch_code=EM_68K; > > #elif (defined SH) > > static Elf32_Half running_arch_code=EM_SH; > > + #elif (defined AARCH64) > > + static Elf32_Half running_arch_code=EM_AARCH64; > > #else > > #error Method os::dll_load requires that one of following is > > defined:\ > > IA32, AMD64, IA64, __sparc, __powerpc__, ARM, S390, > > ALPHA, MIPS, MIPSEL, PARISC, M68K, SH > > This part seems reasonable. Yes, I'm sure we have similar patches like this for other archs. I'll add it to our trees. Is the little endian comment still applicable or just a copy-and-paste error? > > > --- icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > +++ icedtea-2.3.7/openjdk/hotspot/src/os/linux/vm/os_linux.cpp > > @@ -5374,14 +5374,6 @@ void Parker::unpark() { > > > > extern char** environ; > > > > -#ifndef __NR_fork > > -#define __NR_fork IA32_ONLY(2) IA64_ONLY(not defined) > > AMD64_ONLY(57) > > -#endif > > - > > -#ifndef __NR_execve > > -#define __NR_execve IA32_ONLY(11) IA64_ONLY(1033) AMD64_ONLY(59) > > -#endif > > - > > // Run the specified command in a separate process. Return its > > exit value, > > // or -1 on failure (e.g. can't fork a new process). > > // Unlike system(), this function can be called from signal > > handler. It > > @@ -5392,10 +5384,11 @@ int os::fork_and_exec(char* cmd) { > > // fork() in LinuxThreads/NPTL is not async-safe. It needs to > > run > > // pthread_atfork handlers and reset pthread library. All we > > need is a > > // separate process to execve. Make a direct syscall to fork > > process. > > - // On IA64 there's no fork syscall, we have to use fork() and > > hope for > > - // the best... > > - pid_t pid = NOT_IA64(syscall(__NR_fork);) > > - IA64_ONLY(fork();) > > +#ifdef SYS_fork > > + pid_t pid = syscall(SYS_fork); > > +#else > > + pid_t pid = syscall(SYS_clone, SIGCHLD, 0, 0, 0, 0); > > +#endif > > > > if (pid < 0) { > > // fork failed > > @@ -5409,10 +5402,7 @@ int os::fork_and_exec(char* cmd) { > > // not reset by fork() (see notes above), execve() will > > instead kill > > // every thread in the parent process. We know this is the > > only thread > > // in the new process, so make a system call directly. > > - // IA64 should use normal execve() from glibc to match the > > glibc fork() > > - // above. > > - NOT_IA64(syscall(__NR_execve, "/bin/sh", argv, environ);) > > - IA64_ONLY(execve("/bin/sh", (char* const*)argv, environ);) > > + syscall(SYS_execve, "/bin/sh", argv, environ); > > > > // execve failed > > _exit(-1); > > Why have you deleted the IA-64 code? > This makes no sense to me either. > 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 Tue Mar 26 02:35:35 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Mar 2013 09:35:35 +0000 Subject: Two AArch64-related patches In-Reply-To: <552628385.23675722.1364248078742.JavaMail.root@redhat.com> References: <552628385.23675722.1364248078742.JavaMail.root@redhat.com> Message-ID: <51516BE7.7030803@redhat.com> On 03/25/2013 09:47 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Michal Vyskocil writes: >> >> > I'm a maintainer of openjdk for SUSE and recently I've got two >> > patches >> > from our AArch64 team for openjdk7. I have no idea if porting of >> > openjdk7 is important for this group, but it is probably better to >> > try >> > it. >> >> You may be aware that there is an AArch64 porting project. >> >> Mailing List >> aarch64-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/aarch64-dev >> >> The actual source code still isn't there, but hopefully will be as >> soon as we get all the legal details sorted out. > > Is there an intention to backport the AArch64 port to 7? It's entirely confined to HotSpot, so I don't think there's any need to backport anything: I hope that we'll be able to use a newer HotSpot with 7. Andrew. From gnu.andrew at redhat.com Tue Mar 26 07:45:22 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 26 Mar 2013 10:45:22 -0400 (EDT) Subject: Two AArch64-related patches In-Reply-To: <51516BE7.7030803@redhat.com> Message-ID: <1976740502.23970105.1364309122054.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/25/2013 09:47 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Michal Vyskocil writes: > >> > >> > I'm a maintainer of openjdk for SUSE and recently I've got two > >> > patches > >> > from our AArch64 team for openjdk7. I have no idea if porting > >> > of > >> > openjdk7 is important for this group, but it is probably better > >> > to > >> > try > >> > it. > >> > >> You may be aware that there is an AArch64 porting project. > >> > >> Mailing List > >> aarch64-dev at openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/aarch64-dev > >> > >> The actual source code still isn't there, but hopefully will be as > >> soon as we get all the legal details sorted out. > > > > Is there an intention to backport the AArch64 port to 7? > > It's entirely confined to HotSpot, so I don't think there's any > need to backport anything: I hope that we'll be able to use > a newer HotSpot with 7. > Well, it'll still have to be backported to the 7u repositories, but yes, I see what you mean; it will no doubt just get included in one of the bulk updates by default. But that's a long way off and I see no harm in making Zero work in the meantime. Has it been run on a completely AArch64 system yet? I'm wondering if any minor JDK issues might come up once a full build is done purely on AArch64 without the emulator. > 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 Tue Mar 26 08:08:18 2013 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Mar 2013 15:08:18 +0000 Subject: Two AArch64-related patches In-Reply-To: <1976740502.23970105.1364309122054.JavaMail.root@redhat.com> References: <1976740502.23970105.1364309122054.JavaMail.root@redhat.com> Message-ID: <5151B9E2.4040409@redhat.com> On 03/26/2013 02:45 PM, Andrew Hughes wrote: > Has it been run on a completely AArch64 system yet? No. > I'm wondering if any minor JDK issues might come up once a full > build is done purely on AArch64 without the emulator. I would be astonished if there were no problems. Andrew.