Hello!
Pattern.compile fails with IOOB when normalizing a pattern that contains
a surrogate pair.
Would you please help review a trivial 1-line fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8228352
WEBREV: http://cr.openjdk.java.net/~igerasim/8228352/00/webrev/
--
With kind regards,
Hi Andrew,
Just a small comment about the tests. As you can see, some of tests in
jdk/java/nio/channels/FileChannel check various modes, arguments, and
expected exceptions. E.g. see MapTest, Mode and Args.
I noticed that in your changes for the new map mode there are new
exceptions thrown
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8215181
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8215181/webrev.00/
This is to enable "accounting" style currency formatting (negative
values in parentheses) with CLDR.
Thanks, Laurent. I can sponsor this fix, get a RFR thread going for
JDK-8226297, keep webrevs updated as the review progresses, etc.
However I've uncovered an issue with the fix that should be resolved
before proceeding.
Specifically, the new Arrays.COMMON_PARALLELISM static constant causes
Hi Peter, Daniel
On 7/31/19 1:44 AM, Peter Levart wrote:
On 7/31/19 9:59 AM, Peter Levart wrote:
Hi,
I think Daniel is talking about the "dispatch" semantics of
unreflectSpecial here, right Daniel?
Thanks for clarifying this.
The findSpecial / unreflectSpecial is a MethodHandle
Hi Andrew,
I did a quick check of the change across our platforms. Arm32 and x86_64
built successfully. But I see it fails due to minor issues on aarch64
and x86_32 with webrev.09.
Can you please have a look at this?
> src/hotspot/cpu/aarch64/aarch64.ad:2202:1: error: expected ‘;’ before
On 31/07/2019 16:46, Aleksey Shipilev wrote:
> On 7/31/19 4:46 PM, Andrew Dinn wrote:
>> Well, the failure happened during the build process so I didn't
>> (couldn't) debug it. I disabled the assert in supports_cpuflush() in
>> order to allow the build to complete and then ran up the resulting JVM
On 7/31/19 4:46 PM, Andrew Dinn wrote:
> Well, the failure happened during the build process so I didn't
> (couldn't) debug it. I disabled the assert in supports_cpuflush() in
> order to allow the build to complete and then ran up the resulting JVM
> inside gdb to check what was going on. The
On 31/07/2019 12:40, Aleksey Shipilev wrote:
> On 7/31/19 1:29 PM, Andrew Dinn wrote:
>> I have an update regarding the change to the computation of the
>> CPU_FLUSH flag. After posting the new webrev I built a debug version
>> with the change that tests the clflush bit on x86_64. It crashed when
On 7/31/19 3:08 PM, Andrew Dinn wrote:
> On 31/07/2019 13:01, Boris Ulasevich wrote:
> I'm surprised by the x86_32 result as I /thought/ I had pushed the very
> same change set to the submit repo and it came back with no errors:
>
>> Job: mach5-one-adinn-JDK-8224974-8-20190730-1325-4068436
>>
On 31/07/2019 13:01, Boris Ulasevich wrote:
> I did a quick check of the change across our platforms. Arm32 and x86_64
> built successfully. But I see it fails due to minor issues on aarch64
> and x86_32 with webrev.09.
> Can you please have a look at this?
>
>>
On 7/31/19 1:29 PM, Andrew Dinn wrote:
> I have an update regarding the change to the computation of the
> CPU_FLUSH flag. After posting the new webrev I built a debug version
> with the change that tests the clflush bit on x86_64. It crashed when
> the assert is reached in
Hi Aleksey,
I have an update regarding the change to the computation of the
CPU_FLUSH flag. After posting the new webrev I built a debug version
with the change that tests the clflush bit on x86_64. It crashed when
the assert is reached in VM_Version::supports_cpuflush:
# A fatal error has been
Hi Aleksey
On 30/07/2019 17:00, Aleksey Shipilev wrote:
> On 7/30/19 5:04 PM, Andrew Dinn wrote:
>> JEP 352 has now been targeted for inclusion in JDK14. The latest webrev
>> for the implementation JIRA has been rebased to apply to the current
>> tree. Is it now ok to push this change set?
>>
>>
Hi Peter, Mandy,
On 31/07/2019 09:44, Peter Levart wrote:
Expanding on this a little. The javadocs of MethodHandles.Lookup starts
talking about the Lookup factory methods methods and their equivalence
to bytecode instructions, but then present the equivalence between find*
and Java source
On 7/31/19 11:46 AM, chengjingwei wrote:
> Would someone help to approve the backport of the following issues?
Same here. You have to follow the process outlined here:
https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
At very least, do not lump multiple issues together,
Hi Peter, Mandy,
On 31/07/2019 08:59, Peter Levart wrote:
Hi,
I think Daniel is talking about the "dispatch" semantics of
unreflectSpecial here, right Daniel?
Yes, exactly!
The findSpecial / unreflectSpecial is a MethodHandle equivalent for
bytecode instruction invokespecial (sans actual
Hi, all
Would someone help to approve the backport of the following issues?
- Issue list:
JDK-8151788
JDK-8026049
JDK-8149469
JDK-8149469
- Details:
JDK-8151788
Reproduced on 8u:[Yes]
Bug: https://bugs.openjdk.java.net/browse/JDK-8151788
Patch is clean:[Yes]
JDK9 Changeset:
On 7/31/19 9:59 AM, Peter Levart wrote:
Hi,
I think Daniel is talking about the "dispatch" semantics of
unreflectSpecial here, right Daniel?
The findSpecial / unreflectSpecial is a MethodHandle equivalent for
bytecode instruction invokespecial (sans actual invoking).
invokespecial is
Hi,
I think Daniel is talking about the "dispatch" semantics of
unreflectSpecial here, right Daniel?
The findSpecial / unreflectSpecial is a MethodHandle equivalent for
bytecode instruction invokespecial (sans actual invoking). invokespecial
is typically used for implementing the
20 matches
Mail list logo
