On Sat, 28 Nov 2020 09:43:15 GMT, Aleksey Shipilev wrote:
>> Vladimir Kozlov has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
On Wed, 25 Nov 2020 19:48:40 GMT, Aleksey Shipilev wrote:
>>> I just pulled the fresh master, applied this patch on top, enabled
>>> `_PhantomReference_refersTo0` in `c2compiler.cpp`, and ran
>>> `CONF=linux-x86_64-server-fastdebug make images run-test TEST=t
On Wed, 25 Nov 2020 17:48:54 GMT, Vladimir Kozlov wrote:
> @shipilev 2 new tests added by JDK-8188055 does not trigger C2 compilation.
That sounds like a testbug to me! Since this PR adds C2 intrinsics, I thought
it is expected that new tests trigger it in default test configs...
> You need
On Wed, 25 Nov 2020 16:30:16 GMT, Jorn Vernee wrote:
>> The VM "entry" changes seem better now. Thanks.
>>
>> The use of CATCH as a safety-net is also good.
>
> I've applied open comments. Please let me know if this is ok to merge.
Still looks fine to me. Merge from master to get the fixes for
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Tue, 24 Nov 2020 13:21:08 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was
On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was
On Mon, 23 Nov 2020 18:58:15 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was
On Thu, 19 Nov 2020 15:00:54 GMT, Poonam Bajaj wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java
>> line 79:
>>
>>> 77: .forEach(entry -> createSubSystemController(subsystem,
>>> entry));
>>> 78:
>>> 79: } catch
On Thu, 19 Nov 2020 17:04:15 GMT, Poonam Bajaj wrote:
>> Hi,
>>
>> Please review this simple change that catches UncheckedIOException that can
>> occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the
>> system, or if there is an interrupt while these are being read.
>>
On Thu, 19 Nov 2020 01:22:01 GMT, Poonam Bajaj wrote:
> Hi,
>
> Please review this simple change that catches UncheckedIOException that can
> occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the
> system, or if there is an interrupt while these are being read.
>
>
On Mon, 16 Nov 2020 12:30:53 GMT, Maurizio Cimadamore
wrote:
> This simple patch fixes a build issue on Windows x86 introduced by the new
> scoped memory access changes. The culprit is a signature mismatch between hpp
> and cpp function definition.
Already handled by #1222 ?
-
On Mon, 9 Nov 2020 09:19:44 GMT, Jie Fu wrote:
> Hi all,
>
> May I get reviews for this change?
>
> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some
> of our testing platforms.
> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller
> than
On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi wrote:
>> …AccessorImpl object
>>
>> We met real problem when using protobuf with option optimized for code size,
>> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>>
>> Optimize solution is adding a new boolean field to detect
On Sun, 8 Nov 2020 05:07:07 GMT, Hui Shi wrote:
>> …AccessorImpl object
>>
>> We met real problem when using protobuf with option optimized for code size,
>> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>>
>> Optimize solution is adding a new boolean field to detect
On Thu, 5 Nov 2020 02:52:05 GMT, Hui Shi wrote:
> …AccessorImpl object
>
> We met real problem when using protobuf with option optimized for code size,
> detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>
> Optimize solution is adding a new boolean field to detect concurrent
On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung wrote:
> Record classes are now a standard feature in 16. @SuppressWarnings can be
> removed from sun.misc.Unsafe.
Looks fine to me. I see there are Shenandoah-related failures in testing,
that's not the fault of this patch.
-
Marked
On Tue, 3 Nov 2020 00:04:58 GMT, Brian Burkhalter wrote:
> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load
> bytes into a sequence of intermediate arrays. If an intermediate array is not
> completely filled before being added to the list of arrays the contents of
>
On Thu, 29 Oct 2020 00:59:56 GMT, Jason Tatton
wrote:
>> Please review the improvements which I have made to the
>> java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any
>> further improvements are required.
>>
>> Thanks,
>> Jason
>
> Jason Tatton has updated the pull
On Fri, 23 Oct 2020 15:51:47 GMT, Severin Gehwolf wrote:
>> Test only change. With
>> [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has
>> been added on the hotspot side, but nothing for the Java Metrics code. Same
>> for
On Tue, 27 Oct 2020 12:43:47 GMT, Jorn Vernee wrote:
> Hi,
>
> Currently, if MethodHandles::permuteArguments is used with a reorder array
> that is the wrong size, or one of the indexes in it is out of bounds of the
> new type, we simply get the exception message:
>
> bad reorder array
On Sat, 24 Oct 2020 21:44:22 GMT, Rafael Winterhalter
wrote:
> A method's or constructor's owner type might carry annotations on its
> potential type parameters but is never represented as parameterized type what
> makes these parameters inaccessible at runtime, despite the presence of
>
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first,
On Tue, 27 Oct 2020 13:48:34 GMT, Maurizio Cimadamore
wrote:
>> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>>
>> Testing:
>> - [x] Affected test on Linux x86_64 (still passes)
>> - [x] Affected test on Linux x86_32 (now ignored)
>
> Marked as reviewed by
On Fri, 23 Oct 2020 10:42:14 GMT, Aleksey Shipilev wrote:
> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>
> Testing:
> - [x] Affected test on Linux x86_64 (still passes)
> - [x] Affected test on Linux x86_32 (now ignored)
This pull request has now
On Mon, 26 Oct 2020 07:41:16 GMT, Aleksey Shipilev wrote:
>> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>>
>> Testing:
>> - [x] Affected test on Linux x86_64 (still passes)
>> - [x] Affected test on Linux x86_32 (now ignored)
>
&
On Fri, 23 Oct 2020 10:42:14 GMT, Aleksey Shipilev wrote:
> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>
> Testing:
> - [x] Affected test on Linux x86_64 (still passes)
> - [x] Affected test on Linux x86_32 (now ignored)
@mcimadamore, ple
On Fri, 23 Oct 2020 12:37:10 GMT, Aleksey Shipilev wrote:
> It currently fails on x86_32 with `java.lang.IllegalStateException:
> Misaligned access at address: 12`. I checked that once JDK-8254162
> integrates, that issue is gone. Until then, having clean x86_32 testing is
>
On Fri, 23 Oct 2020 15:39:41 GMT, Maurizio Cimadamore
wrote:
>>> Yes - another thing worth considering though is: if 32bit alignment is the
>>> best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a
>>> double[] it seems, from what you are getting), then I think an even
On Fri, 23 Oct 2020 15:25:47 GMT, Maurizio Cimadamore
wrote:
> Yes - another thing worth considering though is: if 32bit alignment is the
> best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a
> double[] it seems, from what you are getting), then I think an even better
>
ffected test on Linux x86_64 (still passes)
> - [x] Affected test on Linux x86_32 (now ignored)
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Fix it instead of problem-listing
-
Changes:
- all: https://git.openj
On Fri, 23 Oct 2020 14:57:06 GMT, Maurizio Cimadamore
wrote:
>> Thing is, I don't think there is a way to problem list the _TestNG_
>> testcase, is it? There is only a way to problem list the entire jtreg test
>> or its separate `@run` with ID. Which is what the patch does. I would think
>>
On Fri, 23 Oct 2020 15:01:48 GMT, Aleksey Shipilev wrote:
>> Can you see if this helps?
>>
>> diff --git
>> a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
>>
>> b/test/jdk/java/util/stream/tes
On Fri, 23 Oct 2020 14:33:11 GMT, Maurizio Cimadamore
wrote:
>> I'm not sure I get as to why the test fails on 32 bits - in the sense that
>> it does not seem to rely on platform specific assumptions (at least on a
>> quick look). On top of my head I'm not aware of what might have caused this
It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned
access at address: 12`. I checked that once JDK-8254162 integrates, that issue
is gone. Until then, having clean x86_32 testing is beneficial for other work.
Testing:
- [x] Affected test on Linux x86_64 (still
I would like to have clean x86_32 test runs until JDK-8254162 arrives.
Testing:
- [x] Affected test on Linux x86_64 (still passes)
- [x] Affected test on Linux x86_32 (now ignored)
-
Commit messages:
- 8255331: Problemlist java/foreign/TestMismatch.java on 32-bit platforms
On 10/21/20 11:17 AM, Severin Gehwolf wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8250984
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/
Looks fine to me.
--
Thanks,
-Aleksey
On Mon, 19 Oct 2020 18:13:59 GMT, Vladimir Kozlov wrote:
>> Aleksey Shipilev has refreshed the contents of this pull request, and
>> previous commits have been removed. The
>> incremental views will show differences compared to the previous content of
>> the PR.
5261.564 ± 8.524 ns/op
> LinkedChainBench.linkedChain 100 avgt5 3367.192 ± 21.128 ns/op
> LinkedChainBench.linkedChain1000 avgt5 34148.851 ± 373.080 ns/op
Aleksey Shipilev has refreshed the contents of this pull request, and previous
commits have been r
5261.564 ± 8.524 ns/op
> LinkedChainBench.linkedChain 100 avgt5 3367.192 ± 21.128 ns/op
> LinkedChainBench.linkedChain1000 avgt5 34148.851 ± 373.080 ns/op
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. Th
On Wed, 14 Oct 2020 15:23:31 GMT, Claes Redestad wrote:
>> Thanks for fixing these problems.
>
> Thanks for reviewing, @RogerRiggs - hopefully this is the last of 'em
The benchmark is oddly written. I submitted
https://bugs.openjdk.java.net/browse/JDK-8254782 -- to let original authors
fix it
This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point
in JDK that can use the intrinsic like
this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2
intrinsic now, hook it up to
`Instrumentation`, and let the tools use that fast path today.
With
On Thu, 24 Sep 2020 08:35:24 GMT, Aleksey Shipilev wrote:
> JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it.
> @requires tests the OS RAM size, but you can
> easily have the x86_32 host with more than 4G ram, yet JVM would fail to
> acquire that hea
On Thu, 24 Sep 2020 09:48:55 GMT, Thomas Schatzl wrote:
>> JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it.
>> @requires tests the OS RAM size, but you can
>> easily have the x86_32 host with more than 4G ram, yet JVM would fail to
>> acquire that heap size. Need to
JDK-8246697 added -Xmx4g to test configurations. 32-bit VMs cannot do it.
@requires tests the OS RAM size, but you can
easily have the x86_32 host with more than 4G ram, yet JVM would fail to
acquire that heap size. Need to check for
bitness explicitly.
Testing:
- [x] java/util/StringJoiner
On Fri, 18 Sep 2020 08:53:34 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/lang/String.java line 3186:
>>
>>> 3184: * caller.
>>> 3185: *
>>> 3186: * @param fa function to apply
>>
>> Shouldn't this be "_the_ function to apply"? Grep for other instance of
>>
On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote:
> To confirm that this would not require a CSR I asked Joe Darcy. Joe replied
> that this would NOT require a CSR.
Changing the review from "Request Changes" to just "Comment.
-
PR: https://git.openjdk.java.net/jdk/pull/238
On Fri, 18 Sep 2020 08:27:44 GMT, Pavel Rappo wrote:
> To confirm that this would not require a CSR I asked Joe Darcy. Joe replied
> that this would NOT require a CSR.
Changes requested by shade (Reviewer).
src/java.base/share/classes/java/lang/String.java line 3186:
> 3184: * caller.
>
On 9/17/20 2:57 PM, Andrew Leonard wrote:
Hi,
Please can I request a review of this test fix to explicitly specify
-XX:+CompactStrings which is required for the tests in question,
specifically for VMs (openj9) that do not default to +CompactStrings, see:
PR
On Wed, 9 Sep 2020 12:53:41 GMT, Galder Zamarreño
wrote:
>> Ah yes, my bad 臘♂️
>
> Updated PR.
Now I wonder (after reading the discussion), why not
`UNSAFE.storeStoreFence()`? I am basically okay with either, given
they currently map to the same thing. But it seems that semantically only
On Wed, 9 Sep 2020 13:04:38 GMT, Aleksey Shipilev wrote:
>> Updated PR.
>
> Now I wonder (after reading the discussion), why not
> `UNSAFE.storeStoreFence()`? I am basically okay with either, given
> they currently map to the same thing. But it seems that semantically only
On Wed, 9 Sep 2020 12:35:06 GMT, Galder Zamarreño
wrote:
> * Release fence guarantees that cacheArray field will published with a
> non-null value.
> * Without this fix, CacheValueMap.cacheArray can sometimes be seen as null.
>
> This is a follow up to @PaulSandoz's feedback
>
On Tue, 8 Sep 2020 22:05:13 GMT, rgiulietti
wrote:
>> This is a follow-up of the Mercurial-based workflow initiated on the
>> core-lib-devs mailing list [0]. Not sure if this
>> one is strictly necessary or if the patches sent on the list are sufficient.
>> Anyway, I exploit this PR as a test
On 6/18/20 3:09 PM, Chris Hegarty wrote:
>> On 18 Jun 2020, at 13:43, Aleksey Shipilev wrote:
>> Again, JDK-8247532 is the writing on the wall: we don't need 3rd party
>> developers to tell if Record
>> serialization works fast in 15 -- we already know it does not.
>
On 6/17/20 6:50 PM, Mandy Chung wrote:
> On 6/17/20 8:11 AM, Aleksey Shipilev wrote:
>> On 6/15/20 11:58 PM, Mandy Chung wrote:
>> Amusingly, with the rest of Unsafe available the barn is still full open.
>> Here's the sketch for the
>> workaround: get the field
On 6/15/20 11:58 PM, Mandy Chung wrote:
> This patch also proposes `sun.misc.Unsafe::objectFieldOffset` and
> `sun.misc.Unsafe::staticField{Offset/Base}` not to support records.
Note this would break otherwise innocuous introspection for records, for
example dumping the VM
layout with JOL:
On 5/25/20 6:51 PM, Aleksey Shipilev wrote:
> Thanks!
>
> Maurizio, want to ack this too?
Nevermind, I pushed with Thomas' review and triviality rule.
--
Thanks,
-Aleksey
Thanks!
Maurizio, want to ack this too?
-Aleksey
On 5/25/20 4:13 PM, Thomas Stüfe wrote:
> Seems fine and trivial.
>
> ..Thomas
>
> On Mon 25. May 2020 at 16:09, Aleksey Shipilev <mailto:sh...@redhat.com>> wrote:
>
> On 5/25/20 2:38 PM, Aleks
On 5/25/20 2:38 PM, Aleksey Shipilev wrote:
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8245722
>
> This is similar to JDK-8236634, and fix takes the same form:
>
> diff -r d52c2e540934 test/jdk/java/foreign/libNativeAccess.c
> --- a/test/jdk/java/foreign/libNative
Bug:
https://bugs.openjdk.java.net/browse/JDK-8245722
This is similar to JDK-8236634, and fix takes the same form:
diff -r d52c2e540934 test/jdk/java/foreign/libNativeAccess.c
--- a/test/jdk/java/foreign/libNativeAccess.c Mon May 25 12:03:30 2020 +0200
+++
On 5/22/20 3:55 PM, Claes Redestad wrote:
> There are no guarantees any particular fallback is not going to break in
> similar ways or - more likely - bit rot and break sooner. Seeing how all
> but the default strategy sees rather superficial testing in practice, I
> think you are exaggerating the
On 5/22/20 2:16 PM, Claes Redestad wrote:
> What I'm asking for is whether there exist any operational issues that
> means users have to use any of the fallback strategies in the wild on
> JDK 11/14 today. That would be a good argument to keep maintaining the
> code, but I've not heard of such a
On 5/22/20 1:53 PM, Claes Redestad wrote:
> Do you have any example of a case when one of the fallbacks was used to
> work around any issues? We've heard of no such case.
For example, the bug in j.l.invoke caused semantic bug in String concat:
https://bugs.openjdk.java.net/browse/JDK-8200118
On 5/22/20 11:52 AM, Claes Redestad wrote:
> Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/
The experience with dealing with string concat bugs tells me we better leave at
least one strategy
as the fallback. It does not have to be very optimized, but it needs to be
definitely
On 4/8/20 2:25 AM, Kim Barrett wrote:
> Webrev:
> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
src/hotspot/share/prims/jvm.cpp:
*) Do we really need a typedef (L3250) for something that is used once at
L3253?
3248 JVM_ENTRY(jboolean, JVM_ReferenceRefersTo(JNIEnv* env, jobject ref,
On 3/24/20 6:40 PM, Severin Gehwolf wrote:
> On Tue, 2020-03-24 at 12:03 +0100, Aleksey Shipilev wrote:
>> On 3/23/20 9:35 PM, Alan Bateman wrote:
>>> On 23/03/2020 19:22, Aleksey Shipilev wrote:
>>>> +import java.io.InputStream;
>>>>
On 3/24/20 6:38 PM, Paul Sandoz wrote:
> I’ll bite :-) +1
Thanks. Would you also, per chance, consider it trivial?
--
-Aleksey
On 3/23/20 3:02 PM, Aleksey Shipilev wrote:
> This change in JDK-8240629 was not correct and slipped the review?
> https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5
>
> Also, other file has not updated the copyright line.
>
> Fix:
>
> diff -r 35ff74547c64 sr
On 3/23/20 9:35 PM, Alan Bateman wrote:
> On 23/03/2020 19:22, Aleksey Shipilev wrote:
>> +import java.io.InputStream;
>> import java.io.IOException;
>> import java.lang.ProcessBuilder.Redirect;
>> @@ -314,5 +315,8 @@
>> String relat
RFE:
https://bugs.openjdk.java.net/browse/JDK-8241462
In some of my testing pipelines that deal with huge .so-s due to specific build
configuration, tests
that use the StripNativeDebugSymbols plugin fail with OOME. It can be fixed by
using the method that
copies the InputStream straight to
This change in JDK-8240629 was not correct and slipped the review?
https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2#l2.5
Also, other file has not updated the copyright line.
Fix:
diff -r 35ff74547c64 src/java.base/share/native/libjli/args.c
--- a/src/java.base/share/native/libjli/args.c
Good. Pushed.
Cheers,
-Aleksey
On 2/13/20 7:14 PM, Brian Burkhalter wrote:
> Works for me.
>
> Brian
>
>> On Feb 13, 2020, at 10:13 AM, Aleksey Shipilev wrote:
>>
>> Thanks. Trivial?
>>
>> On 2/13/20 7:12 PM, Brian Burkhalter wrote:
>>> +1
Thanks. Trivial?
On 2/13/20 7:12 PM, Brian Burkhalter wrote:
> +1
>
> Brian
>
>> On Feb 13, 2020, at 10:10 AM, Aleksey Shipilev > <mailto:sh...@redhat.com>> wrote:
>>
>> Test bug:
>> https://bugs.openjdk.java.net/browse/JDK-8239007
>>
Test bug:
https://bugs.openjdk.java.net/browse/JDK-8239007
Fix:
https://cr.openjdk.java.net/~shade/8239007/webrev.01/
Follows the precedent of:
https://hg.openjdk.java.net/jdk/jdk/rev/848859723503
Testing: affected tests on Linux {x86_64, x86_32}
--
Thanks,
-Aleksey
Thank you, pushed.
-Aleksey
On 1/13/20 5:41 PM, Andy Herrick wrote:
> sure
>
> /Andy
>
> On 1/13/2020 11:03 AM, Aleksey Shipilev wrote:
>> You good for this to go to jdk14?
>>
>> On 1/13/20 4:15 PM, Andy Herrick wrote:
>>> I'm fine with this change.
&
You good for this to go to jdk14?
On 1/13/20 4:15 PM, Andy Herrick wrote:
> I'm fine with this change.
>
> /Andy
>
> On 12/23/2019 6:52 PM, Alex Kashchenko wrote:
>> Hi,
>>
>> Please review this minor change to jpackage, that is required for
>> successful compilation with VS2013 toolchain:
>>
On 1/13/20 1:22 PM, Maurizio Cimadamore wrote:
> Hi Alex,
> has this been addressed by Nick changes (JDK-8236634) ?
Seems to be, I already closed my issue as duplicate.
--
Thanks,
-Aleksey
On 1/9/20 1:01 PM, Maurizio Cimadamore wrote:
> On 09/01/2020 08:10, Nick Gasson wrote:
>> http://cr.openjdk.java.net/~ngasson/8236634/webrev.1/index.html
Looks fine.
The long/doubleHandle changes probably clash with JDK-8236939.
The test changes probably benefit from cleaner accessors like in
Bug:
https://bugs.openjdk.java.net/browse/JDK-8236920
Fix:
https://cr.openjdk.java.net/~shade/8236920/webrev.01/
This breaks x86_32 test builds. I would like to have this fix in 14.
Testing: Linux {x86_64, x86_32} builds; java/foreign (still passes on x86_64;
still fails on x86_32,
seems
On 1/10/20 10:24 AM, Alan Bateman wrote:
> On 10/01/2020 09:11, Aleksey Shipilev wrote:
>> :
>> No other takers? I would then push this trivial patch for Alex under my
>> single review.
>>
> I think it's okay but would be nice if one of the jpackager maintainers
On 1/10/20 7:06 PM, Leonid Mesnik wrote:
> I am going to push it in jdk/jdk only and not in jdk14.
I suspect there would be some work around x86_32 before RDP2 hits, so maybe
this can go into
jdk/jdk14 as well? This would minimize the jdk/jdk14 -> jdk/jdk merge chore
next week.
> ---
On 1/8/20 10:12 AM, Aleksey Shipilev wrote:
> On 1/8/20 9:45 AM, Aleksey Shipilev wrote:
>> On 1/7/20 7:50 AM, Aleksey Shipilev wrote:
>>> On 1/6/20 1:48 PM, Alex Kashchenko wrote:
>>>> [...]
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>
On 1/8/20 9:45 AM, Aleksey Shipilev wrote:
> On 1/7/20 7:50 AM, Aleksey Shipilev wrote:
>> On 1/6/20 1:48 PM, Alex Kashchenko wrote:
>>>>>>> [...]
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>>>>>> Webrev:
On 1/7/20 7:50 AM, Aleksey Shipilev wrote:
> On 1/6/20 1:48 PM, Alex Kashchenko wrote:
>>>>>> [...]
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236125
>>>>>> Webrev: http://cr.openjdk.java.net/~akasko/jdk/8236125/webrev.00/
On 1/6/20 1:48 PM, Alex Kashchenko wrote:
> On 01/06/2020 10:54 AM, Aleksey Shipilev wrote:
>> On 1/6/20 10:57 AM, Alex Kashchenko wrote:
>>> On 12/24/2019 11:54 AM, Alex Kashchenko wrote:
>>>> On 12/24/2019 01:39 AM, Philip Race wrote:
>>>>> Have you
On 1/6/20 10:57 AM, Alex Kashchenko wrote:
> On 12/24/2019 11:54 AM, Alex Kashchenko wrote:
>> On 12/24/2019 01:39 AM, Philip Race wrote:
>>> Have you verified this with VS 2017 ?
>>> Not that I can see a problem but I doubt we want to trade breaking
>>> 2017 to fix 2013 ...
>>
>> Yes, VS 2017
On 9/18/19 10:23 PM, Evgeny Mandrikov wrote:
> So AFAIU from the above wiki page - first 8142543 should be closed as dup of
> 8073347,
For this case, I would comment in JDK-8142543 that JDK-8073347 fixes the same
thing, without closing
as dup yet. Then finish the backport, then maybe close as
On 9/18/19 9:29 PM, Evgeny Mandrikov wrote:
> Hello,
>
> Please review this 8u backport [1] of JDK-8073347 [2] that resolves
> JDK-8142543 [3].
Wait, that's not how it works, sorry. Please read this:
https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix
Since you are
On 8/19/19 10:08 PM, Brian Burkhalter wrote:
> [2] http://cr.openjdk.java.net/~bpb/8229845/webrev.00/
Two drive-by comments:
*) It seems the "signum == 0" case in smallToString is regressing? Before, it
just returned the
constant-pooled "0", now it goes via StringBuilder;
*) This might be
On 8/20/19 1:14 AM, Arthur Eubanks wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8229899
> Webrev: http://cr.openjdk.java.net/~aeubanks/8229899/webrev.00/
Right, the new code turns data race benign. In older code, the first read of
"status" could have
returned "!null", while the second
On 8/15/19 9:01 PM, Aleksey Shipilev wrote:
> On 8/15/19 6:46 PM, Evgeny Mandrikov wrote:
>> [1] http://cr.openjdk.java.net/~godin/8152467/webrev.00/
>
> This looks good.
I also believe this qualifies as trivial patch. I will be sponsoring the push.
Now running through
jdk-s
On 8/15/19 9:11 PM, Mandy Chung wrote:
> On 8/15/19 11:59 AM, Aleksey Shipilev wrote:
>> On 8/14/19 9:42 PM, Mandy Chung wrote:
>>> http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.05/
>> Looks good.
>>
>> So, to reiterate, we do not need to ini
On 8/15/19 6:46 PM, Evgeny Mandrikov wrote:
> [1] http://cr.openjdk.java.net/~godin/8152467/webrev.00/
This looks good.
--
Thanks,
-Aleksey
On 8/14/19 9:42 PM, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.05/
Looks good.
So, to reiterate, we do not need to initialize bci to -1 for StackFrameInfo,
because it is not
exposed anywhere?
--
Thanks,
-Aleksey
On 8/13/19 3:33 AM, Mandy Chung wrote:
> On 8/12/19 5:13 PM, Frederic Parain wrote:
> 96 // VM adds 1 to the code index to StackFrameInfo::bci field such that
> 97 // zero (and negative values) indicates invalid BCI. So substract 1.
>
> http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.04/
On 8/12/19 9:01 PM, Mandy Chung wrote:
> import jdk.internal.access.JavaLangInvokeAccess;
> import jdk.internal.access.SharedSecrets;
> +import jdk.internal.vm.annotation.Stable;
Not needed anymore.
> + private final int bci = -1; // BCI set by VM
AFAIU, this sets up the field to
On 8/12/19 8:12 PM, Mandy Chung wrote:
> On 8/11/19 9:49 PM, David Holmes wrote:
>> On 11/08/2019 2:50 pm, Mandy Chung wrote:
>>> On 8/10/19 12:30 AM, Aleksey Shipilev wrote:
>>>> I wonder if bci=-1 is meaningful, and should be returned when BCI is not
>>
On 8/12/19 12:13 PM, Claes Redestad wrote:
> Hi core-libs,
>
> analysis shows that a handful of small ConcurrentHashMaps used during
> bootstrap is subject to some amount of resizing. Initializing these to
> slightly larger values improves startup metrics measurably on default
> images without
On 8/9/19 10:19 PM, Mandy Chung wrote:
> An earlier version of this patch was reviewed [1] but I
> didn't get back to explore the other approach. I rebase
> the patch and take out the hotspot change which will be
> covered by JDK-8229375:
>
>
301 - 400 of 1039 matches
Mail list logo
