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 corr
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
h
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 ca
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
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
+++ b/test/jdk/java/foreign/libNativeAcc
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
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:[email protected]>> wrote:
>
> On 5/25/20 2:38 PM, Aleks
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
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:
htt
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 f
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 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 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
> [here](https://m
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: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
`st
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 https://github.com/openjdk/jdk/pull
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 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
>> "f
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
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
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 che
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 heap s
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 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 u
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
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 remo
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.
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
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
unti
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 passes
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
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: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
>> t
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 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
>
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 bett
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
> be
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, please ta
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)
This pull request has now
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 mcimadam
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 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
> para
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 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 [JDK-8252359](https://bugs.openjdk.java.net/bro
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 requ
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
> wh
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 as
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 meth
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 concurren
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 concurre
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 t
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 ?
-
P
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.
>
> Testi
On 5/30/19 6:48 PM, Roger Riggs wrote:
> There are several ways to monitor the progress/"completion" of gc,
> including visible affects on WeakReference, etc., Runtime.availableMemory,
> etc.
> Without the ("or ever"), the case can be made that eventually some kind of
> completion
> should be/mus
On 7/17/19 8:48 AM, Kazunori Ogata wrote:
> Webrev: http://cr.openjdk.java.net/~ogatak/8227831/webrev/
Note this is generally not safe: it introduces data race on langReflectAccess
field access. It has
to be proved that everything that implements LangReflectAccess interface makes
this data race
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?
>
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8224974
> webre
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, an
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 VM_Version::supports_cpu
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
>> Buil
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 probl
On 7/31/19 12:55 PM, Andrew Dinn wrote:
>> So if pre wbsync is no-op, why do we need to handle it everywhere? We seem
>> to be falling through all
>> the way to the stub to do nothing there, maybe we should instead cut much
>> earlier, e.g. when
>> inlining Unsafe.writeBackPresync0? Would it be b
On 8/6/19 2:12 PM, Andrew Dinn wrote:
> On 01/08/2019 12:16, Aleksey Shipilev wrote:
>> On 7/31/19 12:55 PM, Andrew Dinn wrote:
>> I am more concerned that the writeback call enters the pre sync stub
>> unnecessarily.
>
> The stub? I hope you mean when executing th
On 8/6/19 10:31 PM, Lance Andersen wrote:
> The webrev can be found at
> http://cr.openjdk.java.net/~lancea/8226530/webrev.00/index.html
Looks good to me.
I spot-tested my test cases that used to fail, and they all pass with this
patch.
Thanks!
-Aleksey
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:
>
> http://cr.openjdk.java.net/~mchung/jdk14//8193325/webr
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 reg
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 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 be
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/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/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/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 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/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 r
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 "st
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 backpor
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 d
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 com
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/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/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/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/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.
> --- a/test/jdk
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 maintai
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 un
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 JD
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
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:
>>
>
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 chan
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
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:[email protected]>> wrote:
>>
>> Test bug:
>> https://bugs.openjdk.java.net/browse/JDK-8239007
>>
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
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 M
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 des
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
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/24/20 6:38 PM, Paul Sandoz wrote:
> I’ll bite :-) +1
Thanks. Would you also, per chance, consider it trivial?
--
-Aleksey
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 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,
j
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 (UncheckedIOEx
1 - 100 of 1073 matches
Mail list logo
