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
Amy,
I will take care of pushing this on Friday.
Kumar
On 10/16/2014 12:36 AM, Amy Lu wrote:
Thank you Kumar for your review.
I need a sponsorfor push this fix. Alan, may I get your help?
Thanks,
Amy
On 10/16/14, 8:31 AM, Kumar Srinivasan wrote:
Looks good!
Kumar
On 10/14/2014 7:42 PM, A
I created an issue in Jira to track this investigation:
https://bugs.openjdk.java.net/browse/JDK-8061244
The latest webrev of proposed patch is still:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ClassLoader.CNFE/webrev.02/
I invite the public to review it.
Thanks.
Peter
On 10/16/2014 10:44
Konstantin,
I haven't looked at code religiously, so I wouldn't say that I have
reviewed it. however I have some comments, please see them inline.
On 10/16/2014 02:03 PM, Konstantin Shefov wrote:
Paul,
Thanks for reviewing
In the jtreg scripts of the three existing LFCaching tests timeout i
Paul,
Thanks for reviewing
In the jtreg scripts of the three existing LFCaching tests timeout is
set explicitly to 300 seconds. The file currently being changed is not a
test itself, it is parent class of tests.
In fact we can unset this explicit timeout and use the current fix
together with
On 16/10/2014 10:30, Paul Sandoz wrote:
:
45 private static final long TIMEOUT = 30;
Does jtreg define a system property for this value? and is 300s the same as
what jtreg defines as the default?
The online documentation (jtreg -onlineHelp) says the default is 2 minutes, but
that m
On Oct 16, 2014, at 10:43 AM, Konstantin Shefov
wrote:
> Gently reminder
>
> On 14.10.2014 16:58, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review the test bug fix
>> https://bugs.openjdk.java.net/browse/JDK-8059070
>> Webrev is http://cr.openjdk.java.net/~kshefov/8059070/webrev.00/
>>
Hi Peter,
The changes look good indeed. Actually in real environments the benefits
would be larger due to much deeper stack traces.
Perhaps the the doc of ClassLoader.findClass should advise calling the
super instead of throwing a new CNFE?
Stanimir
On Thu, Oct 16, 2014 at 11:44 AM, Peter Levar
Approved for jdk8u-dev.
regards,
Sean.
On 16/10/2014 09:51, Konstantin Shefov wrote:
Sean, Rob
I have to reviews of this backport request (Vladimir is jdk 9
reviewer, but not 8u40).
Can I get an approval for 8u40 in this case?
Thanks
-Konstantin
On 14.10.2014 14:50, Paul Sandoz wrote:
On O
Sean, Rob
I have to reviews of this backport request (Vladimir is jdk 9 reviewer,
but not 8u40).
Can I get an approval for 8u40 in this case?
Thanks
-Konstantin
On 14.10.2014 14:50, Paul Sandoz wrote:
On Oct 14, 2014, at 10:26 AM, Konstantin Shefov
wrote:
Gently reminder
Please, review
Hi,
As for usage of SharedSecrets, they are not needed to access CNFE
package-private constructor from java.lang.ClassLoader, since they are
in the same package, and from java.net.URLClassLoader, the call to
super.findClass(name) does the job. So here's an updated webrev that
also includes mo
Gently reminder
On 14.10.2014 16:58, Konstantin Shefov wrote:
Hello,
Please review the test bug fix
https://bugs.openjdk.java.net/browse/JDK-8059070
Webrev is http://cr.openjdk.java.net/~kshefov/8059070/webrev.00/
Thanks
-Konstantin
Thank you Kumar for your review.
I need a sponsorfor push this fix. Alan, may I get your help?
Thanks,
Amy
On 10/16/14, 8:31 AM, Kumar Srinivasan wrote:
Looks good!
Kumar
On 10/14/2014 7:42 PM, Amy Lu wrote:
On 10/15/14, 4:44 AM, Kumar Srinivasan wrote:
Amy,
The modifications you have mad
On 10/16/2014 01:49 AM, Stanimir Simeonoff wrote:
First, really nice tests.
As for hiding: missing the real classloader impl. might be quite a bumper
for some middleware implementations. That would make pretty hard to trace
dependency issues without explicit logging, the latter is usually availa
14 matches
Mail list logo
