Hi,
i wonder why all usages of decode should be replaced.
Since Integer.valueOf(text,radix) =
Integer.valueOf(Ineger.parseInt(text,radix))
The double allocation with
result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;
could
On Tue, 10 Aug 2021 21:06:00 GMT, Сергей Цыпанов
wrote:
>> The code in `Integer.decode()` and `Long.decode()` might allocate two
>> instances of Integer/Long for the negative values less than -127:
>>
>> Integer result;
>>
>> result = Integer.valueOf(nm.substring(index), radix);
>> result =
> The code in `Integer.decode()` and `Long.decode()` might allocate two
> instances of Integer/Long for the negative values less than -127:
>
> Integer result;
>
> result = Integer.valueOf(nm.substring(index), radix);
> result = negative ? Integer.valueOf(-result.intValue()) : result;
>
> To
On Tue, 10 Aug 2021 17:39:01 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/java/lang/Integer.java line 1450:
>>
>>> 1448:
>>> 1449: try {
>>> 1450: result = parseInt(nm.substring(index), radix);
>>
>> Possibly a follow-up, but I think using `parseInt/-Long(nm,
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
>
On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman wrote:
> It would be useful to get up to date performance data on using Charset vs.
> charset name. At least historically, the charset name versions were faster
> (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)).
The code in
On Tue, 10 Aug 2021 14:56:11 GMT, Claes Redestad wrote:
>> The code in `Integer.decode()` and `Long.decode()` might allocate two
>> instances of Integer/Long for the negative values less than -127:
>>
>> Integer result;
>>
>> result = Integer.valueOf(nm.substring(index), radix);
>> result =
On Mon, 9 Aug 2021 18:08:53 GMT, Valerie Peng wrote:
>> I do not understand this comment
>
> Doesn't implGCMCrypt(...) return an int telling how much bytes it has
> processed? Then we adjust the index and remain input length with this value.
> But here we didn't save the return value which
On Fri, 6 Aug 2021 19:27:30 GMT, Martin Balao wrote:
> I'd like to propose a fix for JDK-8270137 [1].
>
> This bug is triggered when using a previously stored referral ticket (in the
> Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral.
> The mistakenly-used referral
On Tue, 10 Aug 2021 16:16:39 GMT, Weijun Wang wrote:
>> The TGS in "the TGS is the one" is clientSvcTicketEnc indeed. I admit that
>> all these names are a bit confusing -but so it is the underlying protocol-.
>> I'll take the 'user" suggestion and rename it to userSvcTicketEnc -in the
>>
On Tue, 10 Aug 2021 14:48:08 GMT, Martin Balao wrote:
>> Not adding the type is OK, I said it's just to be a little clearer. I think
>> you're right about the cname. It's always the one that actually sends the
>> request.
>>
>> What is "the TGS" (in "the TGS is the one")?
> I'd like to propose a fix for JDK-8270137 [1].
>
> This bug is triggered when using a previously stored referral ticket (in the
> Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral.
> The mistakenly-used referral ticket matched the client and service names but
> it
On Tue, 10 Aug 2021 13:16:42 GMT, Сергей Цыпанов
wrote:
> The code in `Integer.decode()` and `Long.decode()` might allocate two
> instances of Integer/Long for the negative values less than -127:
>
> Integer result;
>
> result = Integer.valueOf(nm.substring(index), radix);
> result =
On Tue, 10 Aug 2021 14:08:24 GMT, Weijun Wang wrote:
>> Hmm.. in my view, adding the S4U2Type to the key will provide not much value
>> other than minor consistency checks (in the form of debug-mode assertions)
>> because the assumptions that a key with a non-null 'user' value is of
>>
> I'd like to propose a fix for JDK-8270137 [1].
>
> This bug is triggered when using a previously stored referral ticket (in the
> Referrals Cache) at the moment of following a S4U2Proxy cross-realm referral.
> The mistakenly-used referral ticket matched the client and service names but
> it
On Tue, 10 Aug 2021 13:45:22 GMT, Martin Balao wrote:
>> src/java.security.jgss/share/classes/sun/security/krb5/internal/ReferralsCache.java
>> line 59:
>>
>>> 57: private byte[] clientSvcTicketEnc; // S4U2Proxy only
>>> 58: ReferralCacheKey (PrincipalName cname, PrincipalName
On Mon, 9 Aug 2021 19:54:21 GMT, Weijun Wang wrote:
>> I'd like to propose a fix for JDK-8270137 [1].
>>
>> This bug is triggered when using a previously stored referral ticket (in the
>> Referrals Cache) at the moment of following a S4U2Proxy cross-realm
>> referral. The mistakenly-used
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
>
On Mon, 9 Aug 2021 19:48:24 GMT, Weijun Wang wrote:
>> I'd like to propose a fix for JDK-8270137 [1].
>>
>> This bug is triggered when using a previously stored referral ticket (in the
>> Referrals Cache) at the moment of following a S4U2Proxy cross-realm
>> referral. The mistakenly-used
The code in `Integer.decode()` and `Long.decode()` might allocate two instances
of Integer/Long for the negative values less than -127:
Integer result;
result = Integer.valueOf(nm.substring(index), radix);
result = negative ? Integer.valueOf(-result.intValue()) : result;
To avoid this we can
On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath wrote:
>> I would like to submit AES-GCM optimization for x86_64 architectures
>> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES
>> and GHASH operations.
>> Performance gain of ~1.5x - 2x for message sizes 8k and above.
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
>
22 matches
Mail list logo
