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
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
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
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
e 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 patch was
;
}
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 corrupt
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:
http
probably 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
<sergey.kukse...@oracle.com <mailto:sergey.kuks
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
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
and multiple string instances being
returned. The new implementation, at small cost, prevents multiple different
instances from being returned.
Mike
--
Best regards,
Sergey Kuksenko
regards,
Sergey Kuksenko
.
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 Kuksenko sergey.kukse...@oracle.com
wrote
the discussion.
— John
On Sep 11, 2013, at 12:03 PM, Sergey Kuksenko sergey.kukse...@oracle.com
wrote:
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
to LambdaMetafactory.
The modification gives +10% - +35% to lambda linkage performance
(depends on amount of lambdas).
--
Best regards,
Sergey Kuksenko
%
to 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
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 MethodHandles.Lookup now? Is it known to have that type
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 understand this is about interpreter
of
operation, for example, inline block.accept instead of store the
character to a local var also helps.
Cheers,
Henry
--
Best regards,
Sergey Kuksenko
there is the liberty of distributing N threads over M
hardware threads (N M)
-Aleksey.
--
Best regards,
Sergey Kuksenko
naturally.
--
Best regards,
Sergey Kuksenko
22 matches
Mail list logo
