Re: [NEW] devel/jdk/1.8
On Thu, 2015-06-11 at 07:41 +0200, Rafael Sadowski wrote: On Sun Jun 07, 2015 at 04:19:43PM -0400, Kurt Miller wrote: Better later then never... OpenJDK 1.8 u45 for amd64 and i386. i386 has the same intermittent crash 1.7 has. Works well enough to self bootstrap using the native_bootstrap flavor. Needs some real world use now. Most of the upstream *bsd porting was done by FreeBSD java developers. The OpenBSD portions were done by myself and Bryan C. Everly. Look okay? -Kurt Run with some old an new (only 1.8) JAR applications. Works as expected. Thank you and the others for testing it. I have fixed a few issues that were reported and imported it today. Regards, -Kurt
Re: [NEW] devel/jdk/1.8
On Sun Jun 07, 2015 at 04:19:43PM -0400, Kurt Miller wrote: Better later then never... OpenJDK 1.8 u45 for amd64 and i386. i386 has the same intermittent crash 1.7 has. Works well enough to self bootstrap using the native_bootstrap flavor. Needs some real world use now. Most of the upstream *bsd porting was done by FreeBSD java developers. The OpenBSD portions were done by myself and Bryan C. Everly. Look okay? -Kurt Run with some old an new (only 1.8) JAR applications. Works as expected. OpenBSD 5.7-current (GENERIC.MP) #33: Tue Jun 9 18:27:18 CEST 2015 Best, Rafael
Re: [NEW] devel/jdk/1.8
On Mon, 2015-06-08 at 19:24 -0400, trondd wrote: On 2015-06-08 10:47, Kurt Miller wrote: Thanks Tim for the testing and research into this issue. I'll take a look later at reducing the default CompressedClassSpaceSize. What ulimits were you running with? -Kurt There is an extra layer, I've just realized. I'm running java in chroot and had just upgraded my snapshot so now chroot is aware of user login classes. So at this point, I think that means it's using the default class. I believe the only change I have made there is: :datasize-max=2G:\ :datasize-cur=1536M:\ I don't increase the limit from -cur. Ok thanks again. I've looked into this a bit and found this nice description of the 1.7 - 1.8 changes that eliminated the permanent generation in 1.7 and replaced it with metaspace plus compressed class space in 1.8: http://java-latte.blogspot.in/2014/03/metaspace-in-java-8.html Currently the compressed class space is fixed size like perm gen was. Oracle set a large default of 1G but only uses it in chunks as needed by java applications. I can reduce the default in our port, but it may come as a surprise that our default is smaller and cause the need for increasing it at startup for vary large applications. Alternatively, I can keep the large default but it would require a large datasize ulimit (2G may be enough) for 1.8. For users who want to run with smaller datasize ulimits they have the two options you noted: 1) Disable compressed class pointers via: -XX:+UseCompressedClassPointers 2) Reduce the size of the compressed class space via: -XX:CompressedClassSpaceSize=256M I haven't decided which approach is better for us. Requiring a 2G datasize ulimit to run does seem excessive. Thoughts? -Kurt
Re: [NEW] devel/jdk/1.8
On Tue, June 9, 2015 10:56 am, Kurt Miller wrote: On Mon, 2015-06-08 at 19:24 -0400, trondd wrote: On 2015-06-08 10:47, Kurt Miller wrote: Thanks Tim for the testing and research into this issue. I'll take a look later at reducing the default CompressedClassSpaceSize. What ulimits were you running with? -Kurt There is an extra layer, I've just realized. I'm running java in chroot and had just upgraded my snapshot so now chroot is aware of user login classes. So at this point, I think that means it's using the default class. I believe the only change I have made there is: :datasize-max=2G:\ :datasize-cur=1536M:\ I don't increase the limit from -cur. Ok thanks again. I've looked into this a bit and found this nice description of the 1.7 - 1.8 changes that eliminated the permanent generation in 1.7 and replaced it with metaspace plus compressed class space in 1.8: http://java-latte.blogspot.in/2014/03/metaspace-in-java-8.html Currently the compressed class space is fixed size like perm gen was. Oracle set a large default of 1G but only uses it in chunks as needed by java applications. I can reduce the default in our port, but it may come as a surprise that our default is smaller and cause the need for increasing it at startup for vary large applications. Alternatively, I can keep the large default but it would require a large datasize ulimit (2G may be enough) for 1.8. For users who want to run with smaller datasize ulimits they have the two options you noted: 1) Disable compressed class pointers via: -XX:+UseCompressedClassPointers 2) Reduce the size of the compressed class space via: -XX:CompressedClassSpaceSize=256M I haven't decided which approach is better for us. Requiring a 2G datasize ulimit to run does seem excessive. Thoughts? -Kurt Someone else might have a better idea of what other ports have done but based on Firefox and newer KDE stuff it seems the precedent is to leave the port at the defaults and let it fail. And add a note in pkg-readme with the options available. I'd list the Java options and the ulimit setting and let the person decide how they want to solve it. Then the mailing list can field the complaints of Java apps not starting until the end of time because people don't know about pkg-readmes. :) Tim.
Re: [NEW] devel/jdk/1.8
On Tue, 2015-06-09 at 12:48 -0400, Ian Darwin wrote: On 2015-06-09 12:40, trondd wrote: Someone else might have a better idea of what other ports have done but based on Firefox and newer KDE stuff it seems the precedent is to leave the port at the defaults and let it fail. And add a note in pkg-readme with the options available. I'd list the Java options and the ulimit setting and let the person decide how they want to solve it. Then the mailing list can field the complaints of Java apps not starting until the end of time because people don't know about pkg-readmes. :) Tim. An FAQ entry in addition? I'm leaning towards reducing it. The 'just works' philosophy applies I think. OpenBSD's ulimits are different then other OS's since our datasize limit is also effectively our virtual memory limit and since we randomize mmap's we need to increase it further to have room for randomization. PermGenSize was 96m on 1.7/amd64, so setting CompressedClassSpaceSize to 256m is a lot larger but not enormous. Very large java application can add the -XX:CompressedClassSpaceSize= argument. I doubt any of the ports we have will require this. -Kurt
Re: [NEW] devel/jdk/1.8
On Tue, Jun 09, 2015 at 08:24:20PM +0100, Stuart Henderson wrote: On 2015/06/09 13:03, Kurt Miller wrote: On Tue, 2015-06-09 at 12:48 -0400, Ian Darwin wrote: On 2015-06-09 12:40, trondd wrote: Someone else might have a better idea of what other ports have done but based on Firefox and newer KDE stuff it seems the precedent is to leave the port at the defaults and let it fail. And add a note in pkg-readme with the options available. I'd list the Java options and the ulimit setting and let the person decide how they want to solve it. Then the mailing list can field the complaints of Java apps not starting until the end of time because people don't know about pkg-readmes. :) Tim. An FAQ entry in addition? I'm leaning towards reducing it. The 'just works' philosophy applies I think. OpenBSD's ulimits are different then other OS's since our datasize limit is also effectively our virtual memory limit and since we randomize mmap's we need to increase it further to have room for randomization. PermGenSize was 96m on 1.7/amd64, so setting CompressedClassSpaceSize to 256m is a lot larger but not enormous. Very large java application can add the -XX:CompressedClassSpaceSize= argument. I doubt any of the ports we have will require this. -Kurt I think reducing the size is a reasonable approach here, a pkg-readme entry seems good enough as somewhere to explain it, it's the go-to place to find important information about running specific ports on OpenBSD, knowing how to find information there is required for all sorts of common things in packages. I fully agree. -- Antoine
Re: [NEW] devel/jdk/1.8
On 2015/06/09 13:03, Kurt Miller wrote: On Tue, 2015-06-09 at 12:48 -0400, Ian Darwin wrote: On 2015-06-09 12:40, trondd wrote: Someone else might have a better idea of what other ports have done but based on Firefox and newer KDE stuff it seems the precedent is to leave the port at the defaults and let it fail. And add a note in pkg-readme with the options available. I'd list the Java options and the ulimit setting and let the person decide how they want to solve it. Then the mailing list can field the complaints of Java apps not starting until the end of time because people don't know about pkg-readmes. :) Tim. An FAQ entry in addition? I'm leaning towards reducing it. The 'just works' philosophy applies I think. OpenBSD's ulimits are different then other OS's since our datasize limit is also effectively our virtual memory limit and since we randomize mmap's we need to increase it further to have room for randomization. PermGenSize was 96m on 1.7/amd64, so setting CompressedClassSpaceSize to 256m is a lot larger but not enormous. Very large java application can add the -XX:CompressedClassSpaceSize= argument. I doubt any of the ports we have will require this. -Kurt I think reducing the size is a reasonable approach here, a pkg-readme entry seems good enough as somewhere to explain it, it's the go-to place to find important information about running specific ports on OpenBSD, knowing how to find information there is required for all sorts of common things in packages.
Re: [NEW] devel/jdk/1.8
On 2015-06-08 10:47, Kurt Miller wrote: Thanks Tim for the testing and research into this issue. I'll take a look later at reducing the default CompressedClassSpaceSize. What ulimits were you running with? -Kurt There is an extra layer, I've just realized. I'm running java in chroot and had just upgraded my snapshot so now chroot is aware of user login classes. So at this point, I think that means it's using the default class. I believe the only change I have made there is: :datasize-max=2G:\ :datasize-cur=1536M:\ I don't increase the limit from -cur. Tim.
Re: [NEW] devel/jdk/1.8
On Sun, 2015-06-07 at 20:21 -0400, trondd wrote: On 2015-06-07 16:19, Kurt Miller wrote: OpenJDK 1.8 u45 for amd64 and i386. i386 has the same intermittent crash 1.7 has. Works well enough to self bootstrap using the native_bootstrap flavor. Needs some real world use now. Built and installed fine (amd64) but ran into this problem: Error occurred during initialization of VM Could not allocate metaspace: 1073741824 bytes Not a problem with the port it seems. I fixed it by adding -XX:-UseCompressedClassPointers to my java options. Also works with -XX:CompressedClassSpaceSize=256m. Someone fixed it by increasing the RAM to 8G in the VM they were running in, but I have a physical box with only 4G in it. Might show up for people with a restrictive login class regardless of physical memory. http://bugs.java.com/view_bug.do?bug_id=8043516 https://bugs.openjdk.java.net/browse/JDK-8055515 http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-April/011319.html Thanks Tim for the testing and research into this issue. I'll take a look later at reducing the default CompressedClassSpaceSize. What ulimits were you running with? -Kurt
Re: [NEW] devel/jdk/1.8
On 2015-06-07 16:19, Kurt Miller wrote: Better later then never... OpenJDK 1.8 u45 for amd64 and i386. i386 has the same intermittent crash 1.7 has. Works well enough to self bootstrap using the native_bootstrap flavor. Needs some real world use now. Cool. Building now. I have an always running java-based service I can test. Tim.
Re: [NEW] devel/jdk/1.8
On 2015-06-07 16:19, Kurt Miller wrote: OpenJDK 1.8 u45 for amd64 and i386. i386 has the same intermittent crash 1.7 has. Works well enough to self bootstrap using the native_bootstrap flavor. Needs some real world use now. Built and installed fine (amd64) but ran into this problem: Error occurred during initialization of VM Could not allocate metaspace: 1073741824 bytes Not a problem with the port it seems. I fixed it by adding -XX:-UseCompressedClassPointers to my java options. Also works with -XX:CompressedClassSpaceSize=256m. Someone fixed it by increasing the RAM to 8G in the VM they were running in, but I have a physical box with only 4G in it. Might show up for people with a restrictive login class regardless of physical memory. http://bugs.java.com/view_bug.do?bug_id=8043516 https://bugs.openjdk.java.net/browse/JDK-8055515 http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-April/011319.html Tim.
