On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Thu, 26 May 2022 15:43:57 GMT, XenoAmess wrote:
> > Is there any practical scenario where the current code (skip buffer
> > allocation on each invocation) creates issues?
>
> @kuksenko Not found any yet :)
In that case, what is the value of this PR? Do we need a code change for the
sake of
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
I fixed the spec. No changes in
code/tests.
Also please review the associated CSR:
https://bugs.openjdk.java.net/browse/JDK-8227666
I updated it, according to Joe Darcy's comments.
An additional explanation and background is copied below from my
original e-mail [2] for your convenience:
The
}
On 2017-03-28 21:22, Sergey Kuksenko wrote:
Friendly reminder.
Have you have chance to review the latest version?
On 03/17/2017 12:45 PM, Sergey Kuksenko wrote:
Hi, All.
I realized (thanks Tagir V.) that if we don't check modCount after
calling mapping function we may get corr
Friendly reminder.
Have you have chance to review the latest version?
On 03/17/2017 12:45 PM, Sergey Kuksenko wrote:
Hi, All.
I realized (thanks Tagir V.) that if we don't check modCount after
calling mapping function we may get corrupted tree structure.
new webrev for review:
ably not your job though (it may be mine!)
I would probably try hand-injecting some bugs into a copy of the code
and seeing if our jtreg tests catch it, to increase coverage confidence.
On Thu, Mar 16, 2017 at 12:04 PM, Sergey Kuksenko
mailto:sergey.kukse...@oracle.com>> wrote:
76894
SK> http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/
SK> The issue was created for JDK10 in order to don't disturb JDK9 before
SK> launch.
--
Best regards,
Sergey Kuksenko
; Please, review:
SK> https://bugs.openjdk.java.net/browse/JDK-8176894
SK> http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/
SK> The issue was created for JDK10 in order to don't disturb JDK9 before
SK> launch.
--
Best regards,
Sergey Kuksenko
Hi All,
Please, review:
https://bugs.openjdk.java.net/browse/JDK-8176894
http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/
The issue was created for JDK10 in order to don't disturb JDK9 before
launch.
--
Best regards,
Sergey Kuksenko
,
Sergey Kuksenko
lt and multiple string instances being
returned. The new implementation, at small cost, prevents multiple different
instances from being returned.
Mike
--
Best regards,
Sergey Kuksenko
heckPTypes.
On 09/26/2013 11:09 PM, John Rose wrote:
> (Quick note on format: I have changed the subject line to include the
> conventional bug number and size estimate. The bug number makes it easier to
> track in mailers.)
>
> On Sep 26, 2013, at 9:22 AM, Sergey Kuksenk
ks are performed.
if we didn't find MethodType in the table we always create a new one
(with checks) that is required in less than 1% cases. And we remove at
least one obstacle for scalar replacement. Unfortunately, scalaer
replacement for expression "internTable.get(new MethodType(rtype,
pty
noticed that.
Tomorrow I'll do other webrev - will try to pay attention to all
comments and we may continue the discussion.
>
> — John
>
> On Sep 11, 2013, at 12:03 PM, Sergey Kuksenko
> wrote:
>
>> On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
>>> On 09
tch to the bug report.
>
> — John
>
> On Sep 11, 2013, at 9:23 AM, Sergey Kuksenko
> wrote:
>
>> Please review the webrev at:
>>
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>>
>> LambdaMetafactory is is a quite
On 09/11/2013 09:01 PM, Aleksey Shipilev wrote:
> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.00/
>
> As much as I hate to see the hand code tweaking instead of relying on
> compiler to do it's job, I u
> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote:
>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/
>
> * webrev metadata: "invokation" -> "invocation"
misprint. Should I fix it right now, or may it be done later?
> * Why $caller is Meth
lambda linkage performance.
Minor performance improvement: private method "checkPtype" was inlined
and eliminated. "checkRtype" and "checkPtypes" were refactored for
better perfomance in HotSpot interpreter (important for lambda linkage).
overall result +1%.
--
Best regards,
Sergey Kuksenko
LambdaMetafactory.
The modification gives +10% - +35% to lambda linkage performance
(depends on amount of lambdas).
--
Best regards,
Sergey Kuksenko
when there is the liberty of distributing N threads over M
hardware threads (N < M)
-Aleksey.
--
Best regards,
Sergey Kuksenko
se, mainly from reduce of
operation, for example, inline block.accept instead of store the
character to a local var also helps.
Cheers,
Henry
--
Best regards,
Sergey Kuksenko
orkjoined naturally.
--
Best regards,
Sergey Kuksenko
24 matches
Mail list logo
