On Tue, 11 Oct 2022 00:05:05 GMT, Valerie Peng wrote:
> Mach5 result looks ok. There is one unexpected test failure but it seems
> unrelated
> (https://mach5.us.oracle.com:10060/api/v1/results/vpeng-jdkOh-20221010-1957-37280778-open_test_lib-test-linux-x64-122-1665432715-16/log)
> . So, it sho
On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a Ma
On Mon, 10 Oct 2022 19:05:45 GMT, Xue-Lei Andrew Fan wrote:
> Anyone can help run Mach5 testing in case I missed something?
Sure, I can help with that.
-
PR: https://git.openjdk.org/jdk/pull/10568
On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a Ma
On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a Ma
On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a Ma
> Hi,
>
> May I have the code clean up reviewed?
>
> There is a lot of computation in AESCrypt class load, which could be avoid by
> using the computation result directly. The computation takes 6.971875
> milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but
> removing
On Mon, 10 Oct 2022 16:46:25 GMT, Mark Powers wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a MacOS M1
On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the code clean up reviewed?
>
> There is a lot of computation in AESCrypt class load, which could be avoid by
> using the computation result directly. The computation takes 6.971875
> milliseconds in a MacOS M1 l
On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the code clean up reviewed?
>
> There is a lot of computation in AESCrypt class load, which could be avoid by
> using the computation result directly. The computation takes 6.971875
> milliseconds in a MacOS M1 l
On Wed, 5 Oct 2022 18:03:09 GMT, Xue-Lei Andrew Fan wrote:
> But please let me know, if you have a strong preference to have it, I will
> try to integrate the table generation code.
Your explanation sounds reasonable to me. I will leave it to security-libs
reviewers and maintainers to make the
On Wed, 5 Oct 2022 17:44:39 GMT, Daniel Fuchs wrote:
> I wonder if it would be worthwhile to have a static method that could be
> called in an assert (or in a test using --patch-module) to verify that the
> various statically initialized arrays are the same than those that would have
> been co
On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the code clean up reviewed?
>
> There is a lot of computation in AESCrypt class load, which could be avoid by
> using the computation result directly. The computation takes 6.971875
> milliseconds in a MacOS M1 l
Hi,
May I have the code clean up reviewed?
There is a lot of computation in AESCrypt class load, which could be avoid by
using the computation result directly. The computation takes 6.971875
milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but
removing the computation
14 matches
Mail list logo
