On 07/09/2015 01:10 PM, Pavel Rappo wrote:
On 9 Jul 2015, at 20:46, Remi Forax wrote:
just to be complete , there is also
ArrayList l = new ArrayList<>();
Collections.addAll(l, "1", "2", "3", "4", "5");
which avoid the allocation of the intermediary list.
Thanks Remi, I forgot about t
large server application.
Thanks,
Staffan
On 06/23/2015 12:56 PM, Xueming Shen wrote:
looks good!
-Sherman
On 06/23/2015 12:47 PM, Staffan Friberg wrote:
Hi Sherman,
Removed the check,
http://cr.openjdk.java.net/~sfriberg/JDK-8080640/webrev.4
Cheers,
Staffan
On 06/23/2015 11:22 AM
oks good.
Thanks,
-Sherman
On 06/23/2015 10:54 AM, Staffan Friberg wrote:
Hi Sherman,
Thanks for the review. I removed the unused import and the changes to
reduce the lock region.
New webrev, http://cr.openjdk.java.net/~sfriberg/JDK-8080640/webrev.3
Thanks,
Staffan
On 06/08/2015 02:37 PM, Xuem
ut if the latest change might have a negative impact.
The getBytes() implementation looks good to me.
Thanks!
-Sherman
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-March/006355.html
On 06/05/2015 11:09 AM, Staffan Friberg wrote:
Hi Sherman,
I have a new webrev which reverts
ed by wrapping the returned byte[] from getBytes(ZipEntry) at
user's
site. I would suggest to file a separate rfe on this disagreement and
move on
with the agreed getBytes() for now.
Thanks,
-Sherman
On 06/02/2015 10:27 AM, Staffan Friberg wrote:
On 05/22/2015 01:15 PM, Staffan Friberg wro
On 05/22/2015 01:15 PM, Staffan Friberg wrote:
On 05/22/2015 11:51 AM, Xueming Shen wrote:
On 05/22/2015 11:41 AM, Staffan Friberg wrote:
On 05/21/2015 11:00 AM, Staffan Friberg wrote:
On 05/21/2015 09:48 AM, Staffan Friberg wrote:
On 05/20/2015 10:57 AM, Xueming Shen wrote:
On 05/18
On 05/22/2015 11:51 AM, Xueming Shen wrote:
On 05/22/2015 11:41 AM, Staffan Friberg wrote:
On 05/21/2015 11:00 AM, Staffan Friberg wrote:
On 05/21/2015 09:48 AM, Staffan Friberg wrote:
On 05/20/2015 10:57 AM, Xueming Shen wrote:
On 05/18/2015 06:44 PM, Staffan Friberg wrote:
Hi,
Wanted
On 05/21/2015 11:00 AM, Staffan Friberg wrote:
On 05/21/2015 09:48 AM, Staffan Friberg wrote:
On 05/20/2015 10:57 AM, Xueming Shen wrote:
On 05/18/2015 06:44 PM, Staffan Friberg wrote:
Hi,
Wanted to get reviews and feedback on this performance improvement
for reading from JAR/ZIP files
On 05/21/2015 09:48 AM, Staffan Friberg wrote:
On 05/20/2015 10:57 AM, Xueming Shen wrote:
On 05/18/2015 06:44 PM, Staffan Friberg wrote:
Hi,
Wanted to get reviews and feedback on this performance improvement
for reading from JAR/ZIP files during classloading by reducing
unnecessary
On 05/20/2015 10:57 AM, Xueming Shen wrote:
On 05/18/2015 06:44 PM, Staffan Friberg wrote:
Hi,
Wanted to get reviews and feedback on this performance improvement
for reading from JAR/ZIP files during classloading by reducing
unnecessary copying and reading the entry in one go instead of in
Hi,
Wanted to get reviews and feedback on this performance improvement for
reading from JAR/ZIP files during classloading by reducing unnecessary
copying and reading the entry in one go instead of in small portions.
This shows a significant improvement when reading a single entry and for
a la
19 AM, Staffan Friberg wrote:
Hi,
Here is a small fix that avoids calling deprecated sun.misc.Unsafe
methods, which allows the @SuppressWarnings to be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8067289
Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.00
Regards,
Staffan
Hi,
Here is a small fix that avoids calling deprecated sun.misc.Unsafe
methods, which allows the @SuppressWarnings to be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8067289
Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.00
Regards,
Staffan
ffan
On 11/20/2014 08:41 PM, David Chase wrote:
On 2014-11-20, at 7:45 AM, Staffan Friberg wrote:
Hi,
Anyone who can be the second Reviewer?
Thanks,
Staffan
I can review, but I am not a Reviewer.
CRC32C.java:
56 /**
57 * CRC-32C Polynom
58 */
“Polynomial”, perhaps?
Hi,
Anyone who can be the second Reviewer?
Thanks,
Staffan
On 11/06/2014 04:03 PM, Staffan Friberg wrote:
Hi Andrej,
Thanks for your comments. New webrev,
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.08
Indeed more common :)
jdk/src/java.base/share$ grep -R "private
24];
314 -}
Since the byteTabeleN are properly assigned during the class init based on the
endianess of the systen. Of course, there won't be any performance benefits
since hotspot should constant fold the code
but it'll be easier to maintain and read.
Hi Andrej,
Thanks for your comments. New webrev,
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.08
Indeed more common :)
jdk/src/java.base/share$ grep -R "private final static" *|wc -l
282
jdk/src/java.base/share$ grep -R "private static final" *|wc -l
3274
//Staffan
On 11/06/2014
Anyone have time to be the second reviewer?
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.07
The CCC request has been approved for the new API.
Regards;
Staffan
On 10/22/2014 12:16 AM, Staffan Friberg wrote:
Thanks for the review. Updated the @implSpec.
Also includes Peter's
adOnlyBuffer().
Stanimir
On Thu, Oct 23, 2014 at 3:06 AM, Staffan Friberg <
staffan.frib...@oracle.com <mailto:staffan.frib...@oracle.com>>
wrote:
Hi,
I was thinking about this earlier when I started writing the
patch
and then I forgot about it again. I haven'
If you feel like, add a test with a heap bytebuffer.asReadOnlyBuffer().
Stanimir
On Thu, Oct 23, 2014 at 3:06 AM, Staffan Friberg
mailto:staffan.frib...@oracle.com>> wrote:
Hi,
I was thinking about this earlier when I started writing the patch
and then I forgot about i
Just realized that in the Checksum default case we will actually end up
there for Direct buffers.
//Staffan
On 10/22/2014 05:06 PM, Staffan Friberg wrote:
Hi,
I was thinking about this earlier when I started writing the patch and
then I forgot about it again. I haven't been able to f
of the
array which is processed at once?
This is an excellent catch.
Should not be too large, probably 4k or so.
Stanimir
Am Tue, 21 Oct 2014 10:28:50 -0700
schrieb Staffan Friberg mailto:staffan.frib...@oracle.com>>:
> Hi Peter,
>
> Thanks for the
ffan
On 10/21/2014 10:56 PM, Peter Levart wrote:
On 10/21/2014 11:34 PM, Staffan Friberg wrote:
I believe it must be <, as it is in the tail loop as well, because
end is (off+len or limit) so end is exclusive, similar to
subString(begin,end).
Makes sense?
//Staffan
On 10/21/2014 01:46 PM
o use
buffer.remaining(), instead of the buffer.limit() - buffer.position()
in Checksum.udpate(ByteBuffer)'s #implSpec
The rest looks fine for me.
-Sherman
On 10/21/2014 01:11 PM, Staffan Friberg wrote:
Converted.
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.05
//Staffan
On
et much out of it, so you decide if it's worth complication.
//Staffan
On 10/21/2014 10:28 AM, Staffan Friberg wrote:
Hi Peter,
Thanks for the comments..
217 if (Unsafe.ADDRESS_SIZE == 4) {
218 // On 32 bit platforms read two ints
instead of a single 64bit
Hi Peter,
Thanks for catching!
I would like to keep to 8 since the crc32c instruction on SPARC will
require it, the plan is to add an intrinsic for it.
Thanks,
Staffan
On 10/21/2014 01:30 PM, Peter Levart wrote:
On 10/21/2014 08:49 PM, Staffan Friberg wrote:
Hi,
Got an offline comment
AM, Staffan Friberg wrote:
Hi,
Got an offline comment that the package.html should be update as well
to cover CRC-32C.
Otherwise there are no code changes in this new webrev.
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.04
//Staffan
On 10/21/2014 10:28 AM, Staffan Friberg wrote
Hi,
Got an offline comment that the package.html should be update as well to
cover CRC-32C.
Otherwise there are no code changes in this new webrev.
http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.04
//Staffan
On 10/21/2014 10:28 AM, Staffan Friberg wrote:
Hi Peter,
Thanks for the
Hi Peter,
Thanks for the comments..
217 if (Unsafe.ADDRESS_SIZE == 4) {
218 // On 32 bit platforms read two ints instead of a
single 64bit long
When you're reading from byte[] using Unsafe (updateBytes), you have
the option of reading 64bit values on 6
Hi David,
The intrinsic that can be implemented for CRC32C will probably be even faster
as it can make use of the specific crc32c instruction instead of using carry
less multiplication.
It might not hurt to mock up a quick benchmark using the CRC32C
instruction against jdk8’s java.util.zip.CR
, 2014 at 9:58 PM, Staffan Friberg
mailto:staffan.frib...@oracle.com>
> wrote:
> On 10/17/2014 04:05 AM, Alan Bateman wrote:
>
>> On 17/10/2014 02:42, Staffan Friberg wrote:
>>
>>> Hi,
>>>
>>> This RFE adds a CRC-32C
y so only the null check will remain.
My microbenchmark shows no difference between implementing the method or
relying on the default method.
Thanks,
Staffan
On 10/17/2014 12:56 PM, Ulf Zibis wrote:
Am 17.10.2014 um 20:58 schrieb Staffan Friberg:
Here is a new webrev with the updates from A
converted
to an intrinsic. There’s a certain amount of brain-hurt involved in the
fork/join code, but it works.
I’m still trying to figure out if the whole thing is just bit-flipped.
David
On 2014-10-17, at 4:50 PM, David Chase wrote:
On 2014-10-17, at 2:53 PM, Staffan Friberg wrote:
Fully agree
PrivilegedAction() {
@Override
public String run() {
return System.getProperty("os.arch",
"x64")+System.getProperty("sun.arch.data.model"", ");
}
});
is64Bit = p.indexOf("64&quo
On 10/17/2014 04:05 AM, Alan Bateman wrote:
On 17/10/2014 02:42, Staffan Friberg wrote:
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating
the CRC checksum.
CRC-32C implementation uses slicing-by-8
eBuffer. Unsafe is pretty ugly
overall, though and personally I try to avoid it giving up performance.
On 64bit machines you might be better off with java.nio.LongBuffer
instead.
Stanimir
On Fri, Oct 17, 2014 at 9:06 PM, Staffan Friberg
mailto:staffan.frib...@oracle.com>> wro
On 10/17/2014 01:46 AM, Peter Levart wrote:
On 10/17/2014 03:42 AM, Staffan Friberg wrote:
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating
the CRC checksum.
CRC-32C implementation uses slicing
Hi,
This RFE adds a CRC-32C class. It implements Checksum so it will have
the same API CRC-32, but use a different polynomial when calculating the
CRC checksum.
CRC-32C implementation uses slicing-by-8 to achieve high performance
when calculating the CRC value.
A part from adding the new c
38 matches
Mail list logo
