Re: Expected vs. observed performance of java.util.zip.CRC32 in Java 7 and 8

. The benchmark also prints out the java.version property which confirms that JDK 7 is really going that fast. Regards, Ariel On Wed, Jan 21, 2015, at 03:15 PM, Ariel Weisberg wrote: > Hi, > > I cleaned up the results and converted to bytes and megabytes/second by > multiplying byte

Re: Expected vs. observed performance of java.util.zip.CRC32 in Java 7 and 8

/21/2015 05:34 PM, Ariel Weisberg wrote: > > If you could shed any light on what the performance should be it would > > help when choosing whether to use the JDK CRC32 implementation or > > another depending on the currently runtime. > > Please normalize the output to b

Expected vs. observed performance of java.util.zip.CRC32 in Java 7 and 8

Hi, Hopefully this is the right mailing list. I have some questions about the performance of java.util.zip.CRC32 in OpenJDK. I heard that CRC32 became an intrinsic in Java 8 that uses hardware support if available. I tried it out, but got some odd numbers and I am having trouble nailing down the

Re: Review/comment needed for the new public java.util.Base64 class

is being > pushed going that direction though:-) > > -Sherman > > On 10/12/2012 11:39 AM, Michael Schierl wrote: > > Hello, > > > > (sorry if the threading is broken, but I was not subscribed to the list > > and only found the discussion on Twitter and read it

Re: Review/comment needed for the new public java.util.Base64 class

Hi, It looks like it tackles the issue of encoding binary data as text in an isolated fashion and doesn't seem open to adding other ways of encoding binary data as text such as hex or yEnc. Having a common interface in java.util for different encodings would be great. I am not asking for more impl

Re: JNI UTF-8 encoding bug with some characters

ation > with an "external" system), as long as it provides a round-trip > conversion, > should be not an issue. The character you are using here is a > supplementary > character, this is why you are seeing the difference here. > > -Sherman > > [1] http

Re: JNI UTF-8 encoding bug with some characters

5, 2012, at 11:38 AM, Ariel Weisberg wrote: > Hi all, > > Not sure what list this should go to. > > I found an issue with JNI's GetStringUTFChars which is supposed to > return a Java string in UTF-8 encoding. There is an attached test case. > I tested on Ubuntu 12.0

JNI UTF-8 encoding bug with some characters

Hi all, Not sure what list this should go to. I found an issue with JNI's GetStringUTFChars which is supposed to return a Java string in UTF-8 encoding. There is an attached test case. I tested on Ubuntu 12.04 (Linux aweisberg-desktop 2.6.32-41-generic #89-Ubuntu SMP Fri Apr 27 22:18:56 UTC 2012

Re: Objects.nonNull()

Hi all, As a user the first name that came to mind was expect. Expect doesn't imply a specific error signaling pattern, but it does imply that it is an error if the condition is not as expected. Expect is only one letter less than throwIf, but it doesn't include a capital letter. expectNonNull: I

Re: Timer death

n OOM occurs in one thread it might have occurred in another (one not necessarily managed by your application) at a point that is not exception safe. http://stackoverflow.com/questions/2679330/catching-java-lang-outofmemoryerror Regards, Ariel Weisberg On Fri, 09 Jul 2010 10:32 -0700, "Paw

Re: Timer death

for some more magic) in order to make sure you can catch and handle exceptions thrown by tasks. It's interesting that the javadoc for Timer doesn't mention STPE. Might be a worthwhile enhancement. Hope this helps, Ariel Weisberg On Fri, 09 Jul 2010 10:32 -0700, "Pawel Veselov"

Re: [concurrency-interest] LinkedBlockingDeque deadlock?

test application although the actual app (messaging system) does have this issue on the 610s. I am very interested in hearing about what happens when other people run it. I am also interested in confirming that this is a sane use of Selectors, SocketChannels, and SelectionKeys. Thanks, Ariel Wei

Re: [concurrency-interest] LinkedBlockingDeque deadlock?

issue on them although given how difficult the socket issue is to reproduce it may be that I have not run them long enough. On the AMD machines I did not use -XX:+UseMembar. Ariel On Mon, 13 Jul 2009 18:59 -0400, "Ariel Weisberg" wrote: Hi all. Sorry Martin I missed reading your last

RE: [concurrency-interest] LinkedBlockingDeque deadlock?

e stops the socket from being selected (for both read and write), and eventually the socket fills up and can't be written to by the other side. If I can get my VPN access together tomorrow I will run with -XX:+UseMembar and also try running on some 8-core AMD machines. Otherwise I will have t

RE: [concurrency-interest] LinkedBlockingDeque deadlock?

> OpenJDK6 build relates to. > > Make sure you haven't missed any exceptions occurring in other threads. > > David Holmes > > > -Original Message- > > From: concurrency-interest-boun...@cs.oswego.edu > > [mailto:concurrency-interest-boun...@cs.oswego.