On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Fri, 5 Feb 2021 16:07:09 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Mon, 25 Jan 2021 19:38:16 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Fri, 13 Nov 2020 19:25:57 GMT, Serguei Spitsyn wrote:
>> The ap01t001 test creates six extra instances of the tested class, let them
>> die, and then checks that it gets exactly six ObjectFree callbacks. The
>> problem is that this is verified in the VMDeath callback and at that point
>>
On Fri, 13 Nov 2020 14:11:23 GMT, Stefan Karlsson wrote:
> The ap01t001 test creates six extra instances of the tested class, let them
> die, and then checks that it gets exactly six ObjectFree callbacks. The
> problem is that this is verified in the VMDeath callback and at t
On Fri, 13 Nov 2020 14:11:23 GMT, Stefan Karlsson wrote:
> The ap01t001 test creates six extra instances of the tested class, let them
> die, and then checks that it gets exactly six ObjectFree callbacks. The
> problem is that this is verified in the VMDeath callback and at t
The ap01t001 test creates six extra instances of the tested class, let them
die, and then checks that it gets exactly six ObjectFree callbacks. The problem
is that this is verified in the VMDeath callback and at that point the instance
has gone out-of-scope and and a seventh ObjectFree event
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Mon, 2 Nov 2020 12:58:49 GMT, Coleen Phillimore wrote:
> GC callers shouldn't really have to know what processing we're doing here.
I completely disagree with this. It's extremely important that the GC and
Runtime code agrees on what this code does and where the GC *must* call it.
Knowing
On Mon, 2 Nov 2020 12:58:49 GMT, Coleen Phillimore wrote:
> GC callers shouldn't really have to know what processing we're doing here.
I completely disagree with this. It's extremely important that the GC and
Runtime code agrees on what this code does and where the GC *must* call it.
Knowing
On Mon, 2 Nov 2020 08:25:28 GMT, Stefan Karlsson wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so t
On Mon, 2 Nov 2020 08:25:28 GMT, Stefan Karlsson wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so t
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote:
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
>
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote:
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
>
On Mon, 19 Oct 2020 12:21:27 GMT, Lin Zang wrote:
> Dear @stefank,
> I have update this PR that use a claimer to help worker thread do parallel
> iteration. would you like to help review
> again? Thanks,
> Lin
Wrong Stefan, I think you mean @kstefanj
-
PR:
On Fri, 16 Oct 2020 14:29:46 GMT, Stefan Karlsson wrote:
> The cm03t001 test creates a local JNI handle in the prepare function. It
> later uses that handle from a callback
> function, from another thread. When the callback runs, ZGC applies a load
> barrier to that handle an
On Sat, 17 Oct 2020 08:38:10 GMT, Per Liden wrote:
>> The cm03t001 test creates a local JNI handle in the prepare function. It
>> later uses that handle from a callback
>> function, from another thread. When the callback runs, ZGC applies a load
>> barrier to that handle and self-heals it in
The cm03t001 test creates a local JNI handle in the prepare function. It later
uses that handle from a callback
function, from another thread. When the callback runs, ZGC applies a load
barrier to that handle and self-heals it in
the other threads stack. Later when that thread verifies its
On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote:
> I hit the following assert in some tests runs that I've been doing:
> # Internal Error
> (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67),
> pid=828170,
> tid=828734 # assert(pro
tests consistently
> asserts with this command line. All tests pass
> with the proposed fix.
> Recommendations of tests to run are welcome. I intend to get this run through
> tier1-3, but haven't yet.
Stefan Karlsson has updated the pull request incrementally with one additional
comm
On Tue, 13 Oct 2020 12:48:05 GMT, Richard Reingruber wrote:
>> Stefan Karlsson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review 1
>
> Hi Stefan,
>
> thanks for fixing.
>
> With this cha
On Tue, 13 Oct 2020 09:25:55 GMT, Stefan Karlsson wrote:
> I hit the following assert in some tests runs that I've been doing:
> # Internal Error
> (/home/stefank/git/alt/open/src/hotspot/share/runtime/stackWatermark.inline.hpp:67),
> pid=828170,
> tid=828734 # assert(pro
On Tue, 29 Sep 2020 06:42:54 GMT, Erik Österlund wrote:
>> I think the previous assert was intentionally weaker: `is_in` checks that
>> argument points to a committed area in the
>> heap, which can include the oops not yet fixed. It does not check if oop is
>> valid as far as GC is concerned.
On Wed, 23 Sep 2020 13:57:11 GMT, Erik Österlund wrote:
>> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
>> Processing" (cf.
>> https://openjdk.java.net/jeps/376).
>> Basically, this patch modifies the epilog safepoint when returning from a
>> frame (supporting
On Wed, 23 Sep 2020 12:50:51 GMT, Erik Österlund wrote:
>> src/hotspot/share/gc/z/zDriver.cpp line 108:
>>
>>> 106: return false;
>>> 107: }
>>> 108:
>>
>> Group needs_inactive_gc_locker, skip_thread_oop_barriers, and
>> allow_coalesced_vm_operations together?
>>
>> Add a comment about
On Tue, 22 Sep 2020 11:43:41 GMT, Erik Österlund wrote:
> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
> Processing" (cf.
> https://openjdk.java.net/jeps/376).
> Basically, this patch modifies the epilog safepoint when returning from a
> frame (supporting interpreter
On Tue, 22 Sep 2020 11:43:41 GMT, Erik Österlund wrote:
> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
> Processing" (cf.
> https://openjdk.java.net/jeps/376).
> Basically, this patch modifies the epilog safepoint when returning from a
> frame (supporting interpreter
On Tue, 22 Sep 2020 11:43:41 GMT, Erik Österlund wrote:
> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
> Processing" (cf.
> https://openjdk.java.net/jeps/376).
> Basically, this patch modifies the epilog safepoint when returning from a
> frame (supporting interpreter
On Tue, 22 Sep 2020 11:43:41 GMT, Erik Österlund wrote:
> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack
> Processing" (cf.
> https://openjdk.java.net/jeps/376).
> Basically, this patch modifies the epilog safepoint when returning from a
> frame (supporting interpreter
On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith wrote:
>> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will
>> enable and run microbenchmarks and scaling
>> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015
>> (heap and multi-JVM) scaling
0" successfully, including
your patch for 8251570.
This 8251835 patch looks good to me.
Thanks!
StefanK
Thanks,
Paul
On 8/14/20, 7:49 AM, "Stefan Karlsson" wrote:
Hi all,
Please review this patch to fix a recently introduced jmap bug.
https://cr.openjdk.java.
Hi all,
Please review this patch to fix a recently introduced jmap bug.
https://cr.openjdk.java.net/~stefank/8251835/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8251835
I added the same kind of checks that we have in histo.
Testing:
- Tested locally with the failing test
- Tier1-tier5
*Wednesday, August 5, 2020 at 1:02 PM
*To: *"linzang(臧琳)" , "Hohensee, Paul"
, Stefan Karlsson ,
David Holmes , serviceability-dev
, "hotspot-gc-...@openjdk.java.net"
*Subject: *Re: RFR(L): 8215624: add parallel heap inspection support for
jmap histo(G1)(Internet mai
-
From: "Hohensee, Paul"
Date: Thursday, July 23, 2020 at 6:48 AM
To: "linzang(臧琳)" , Stefan Karlsson ,
"serguei.spit...@oracle.com" , David Holmes , serviceability-dev
, "hotspot-gc-...@openjdk.ja
Hi Coleen,
On 2020-06-17 23:25, coleen.phillim...@oracle.com wrote:
Summary: Remove JVMTI oops_do calls from JVMTI and GCs
Tested with tier1-3, also built shenandoah to verify shenandoah changes.
open webrev at http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev
Looks good.
StefanK
On 2020-06-10 23:00, Schmelter, Ralf wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8237354 added a test, which
did not properly protect against explicitly set GCs (for serial,
parallel and G1 GC). This fixes it by adding the corresponding
@requires tag for each
Looks good.
StefanK
On 2020-05-27 01:07, Chris Plummer wrote:
Hello,
Please review the following trivial change to remove FreeChunk.java:
https://bugs.openjdk.java.net/browse/JDK-8244622
http://cr.openjdk.java.net/~cjplummer/8244622/webrev.00/index.html
Tested with tier1 and also running
Hi Mikael,
On 2020-05-04 07:12, Mikael Vidstedt wrote:
Please review this change which implements part of JEP 381:
JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
webrev:
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/hotspot/open/webrev/
I went over this patch and
On 2020-05-01 21:34, Chris Plummer wrote:
On 4/30/20 2:07 AM, Stefan Karlsson wrote:
...
There was one odd thing in jdi that requires extra scrutiny:
https://cr.openjdk.java.net/~stefank/8244078/webrev.01/test/jdk/com/sun/jdi/lib/jdb/Debuggee.java.udiff.html
Yes, that did look a odd
On 2020-04-30 12:22, Stefan Karlsson wrote:
Hi David,
On 2020-04-30 11:59, David Holmes wrote:
...
---
test/hotspot/jtreg/gc/arguments/GCArguments.java
Isn't the String[] <-> List conversion already handled in
ProcessTools?
This looks like an area where GC added its own helper uti
Hi David,
On 2020-04-30 11:59, David Holmes wrote:
Hi Stefan,
On 30/04/2020 7:07 pm, Stefan Karlsson wrote:
Hi all,
Please review this patch to make it less likely that we accidentally
add or fail to add test.java.opts and test.vm.opts to our spawned
test JVMs.
https
On 2020-04-30 11:24, Alan Bateman wrote:
On 30/04/2020 10:07, Stefan Karlsson wrote:
Hi all,
Please review this patch to make it less likely that we accidentally
add or fail to add test.java.opts and test.vm.opts to our spawned
test JVMs.
https://cr.openjdk.java.net/~stefank/8244078/webrev
Hi all,
Please review this patch to make it less likely that we accidentally add
or fail to add test.java.opts and test.vm.opts to our spawned test JVMs.
https://cr.openjdk.java.net/~stefank/8244078/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8244078
Looks good.
StefanK
On 2020-04-29 06:41, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8244066/webrev.00
16 lines changed: 0 ins; 0 del; 16 mod;
Hi all,
could you please review this trivial cleanup in tests?
from JBS:
ClassFileInstaller is a test utility class which copies
Looks good.
StefanK
On 2020-04-25 00:30, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8243568/webrev.00
8 lines changed: 0 ins; 6 del; 2 mod;
Hi all,
could you please review this small and trivial patch which updates
serviceability/logging/TestLogRotation.java test to pass
Thanks a lot! I agree with you to decouple the heap
inspection code with GC's.
I will start from your POC code, may discuss with you
later.
BRs,
Lin
On 2020/4/22, 5:14 PM, "Stefan Karlsson"
wrote:
Hi Lin,
I took a look at this earlier and saw that the heap inspection code is
strongly coupled with the CollectedHeap and G1CollectedHeap. I'd prefer
if we'd abstract this away, so that the GCs only provide a "parallel
object iteration" interface, and the heap inspection code is kept
eck as Ioi suggested in
startApp method.
+ public static void startApp(LingeredApp theApp, String...
additionalJvmOpts) throws IOException {
+ startAppExactJvmOpts(theApp,
Utils.appendTestJavaOpts(additionalJvmOpts));
+ }
Leonid
On 3/25/20 10:14 AM, Stefan Karlsson wrote:
On 2020-03-25 1
On 2020-03-25 17:40, Igor Ignatyev wrote:
Hi Leonid,
I have briefly looked at the patch, a few comments so far:
test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java:
- at L#114, could you please call static method using class name (as the
opposite of using instance)? or was it meant to be
HotSpot changes look good.
StefanK
On 2020-03-20 14:15, Magnus Ihse Bursie wrote:
Can I get some hotspot reviewers on this as well? And is this trivial,
from the Hotspot PoV?
/Magnus
On 2020-03-20 14:05, Erik Joelsson wrote:
Looks good!
/Erik
On 2020-03-20 03:58, Magnus Ihse Bursie
Looks good.
StefanK
On 2020-03-18 05:52, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8240906
diff --git a/test/hotspot/jtreg/ProblemList-zgc.txt
b/test/hotspot/jtreg/ProblemList-zgc.txt
--- a/test/hotspot/jtreg/ProblemList-zgc.txt
+++
Looks good. This is left-overs from the CMS removal.
StefanK
On 2020-02-25 19:02, Chris Plummer wrote:
Adding hotspot-gc-dev.
Chris
On 2/25/20 2:21 AM, linzang(臧琳) wrote:
Hi,
Please review the following change:
Bugs: https://bugs.openjdk.java.net/browse/JDK-8239916
webrev:
Hi Zhengyu,
On 2020-02-17 15:51, Zhengyu Gu wrote:
Hi Stefan,
Thanks for the review and suggestions, updated accordingly:
http://cr.openjdk.java.net/~zgu/JDK-8238633/webrev.01/
Thanks for moving the code. I think this looks good.
If you're up for it, I have a couple of style change
Hi Zhengyu,
On 2020-02-07 16:53, Zhengyu Gu wrote:
Hi,
I would like purpose this change that allows GC to provide ObjectMarker
during JVMTI heap walk.
Currently, JVMTI heap walk uses oop markword's 'marked' pattern to
indicate 'visited' oop.
Unfortunately, it conflicts with Shenandoah,
Thanks. Created JDK-8237639.
StefanK
On 2020-01-22 10:50, David Holmes wrote:
Hi Stefan,
Thanks David. Would you accept it if I created a follow-up RFR to
investigate if we could change order of the combined flags?
Sure, no problem.
Thanks,
David
On 22/01/2020 6:58 pm, Stefan Karlsson
Hi David,
On 2020-01-22 05:28, David Holmes wrote:
Hi Stefan,
Thanks for tackling this.
On 22/01/2020 12:58 am, Stefan Karlsson wrote:
Hi all,
Please review this patch to change our usages of LingeredApp and
getVmOptions() to instead use getTestJavaOpts().
https://cr.openjdk.java.net
initialized testVmArgs with an
array of the final sized, and then lazily initialize the runtime data.
Copyrights need updating.
Other than that it looks good.
Thanks for reviewing,
StefanK
thanks,
Chris
On 1/21/20 6:58 AM, Stefan Karlsson wrote:
Hi all,
Please review this patch to change
Hi all,
Please review this patch to change our usages of LingeredApp and
getVmOptions() to instead use getTestJavaOpts().
https://cr.openjdk.java.net/~stefank/8237111/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8237111
This issue was encountered by both Coleen and I, independently.
Thanks, Erik!
StefanK
On 2019-12-19 09:22, Erik Joelsson wrote:
Looks good!
/Erik
On 2019-12-18 18:58, Stefan Karlsson wrote:
Adding build-dev.
StefanK
On 2019-12-18 18:52, Stefan Karlsson wrote:
Hi all,
Please review this patch to add a configure check to see if the SDK
supports
Adding build-dev.
StefanK
On 2019-12-18 18:52, Stefan Karlsson wrote:
Hi all,
Please review this patch to add a configure check to see if the SDK
supports the APIs needed to build ZGC on Windows.
https://cr.openjdk.java.net/~stefank/8236110
https://bugs.openjdk.java.net/browse/JDK-8236110
this yesterday to make the JDK 14 fork cut-off.
Thanks,
StefanK
Thanks,
Serguei
On 12/12/19 07:23, Stefan Karlsson wrote:
In the interest to get this integrated before the RDP cut-off I'm
going to push this ASAP. This has gone through tier1-tier3 testing.
StefanK
On 2019-12-12 13:01, Stefan
Thanks, Dan.
StefanK
On 2019-12-12 17:06, Daniel D. Daugherty wrote:
src/hotspot/share/gc/shared/generationSpec.hpp
No comments.
test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatGcCapacityResults.java
No comments.
Thumbs up.
Dan
On 12/12/19 10:23 AM, Stefan Karlsson
In the interest to get this integrated before the RDP cut-off I'm going
to push this ASAP. This has gone through tier1-tier3 testing.
StefanK
On 2019-12-12 13:01, Stefan Karlsson wrote:
Hi all,
Please review this patch to fix a problem with unintialized values in
our generation counters
Hi all,
Please review this patch to fix a problem with unintialized values in
our generation counters.
https://cr.openjdk.java.net/~stefank/8226797/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8226797
The jstat values NGCMN and OGCMN both return uninitialized values.
I stumbled upon
Thanks, Erik.
StefanK
On 2019-11-22 15:24, Erik Joelsson wrote:
Build change looks good.
/Erik
On 2019-11-21 13:11, Stefan Karlsson wrote:
Hi,
I'm looking for a review for this tiny build change:
https://cr.openjdk.java.net/~stefank/8233299/webrev.01/make/autoconf/hotspot.m4.udiff.html
11:18:20 +0100
From: Stefan Karlsson
To: hotspot-gc-dev
Hi all,
Please review this patch to add ZGC support on Windows.
https://cr.openjdk.java.net/~stefank/8233299/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8233299
As mentioned in the JEP (https://openjdk.java.net/jeps/365
Hi
I have a Synology DiskStation DS718+, and in the *Package Center* app, the
SVN server is listed for installation.
But its on old one, it's version 1.9.7.0119.
So, I have asked Synology support about it, but only got the answer:
>
> Unfortunately as we are not the developer of this package we
On 2019-08-16 00:59, Kim Barrett wrote:
On Aug 15, 2019, at 7:46 AM, Stefan Karlsson wrote:
Thanks Kim, Roman, Dan and Coleen for reviews and feedback.
I rebased the patch, fixed more alignments, renamed the bug, and rerun the test
through tier1-3.
https://cr.openjdk.java.net/~stefank
14 11:11, Roman Kennke wrote:
Am 14.08.19 um 01:26 schrieb Kim Barrett:
On Aug 12, 2019, at 12:19 PM, Stefan Karlsson
wrote:
Hi Roman,
Kim helped me figuring out how to get past the volatile issues I had
with the class markWord { uintptr_t value; ... } version. So, I've
created a
11:11, Roman Kennke wrote:
Am 14.08.19 um 01:26 schrieb Kim Barrett:
On Aug 12, 2019, at 12:19 PM, Stefan Karlsson
wrote:
Hi Roman,
Kim helped me figuring out how to get past the volatile issues I had with the
class markWord { uintptr_t value; ... } version. So, I've created a version
Thanks, Serguei.
StefanK
On 2019-07-02 17:57, serguei.spit...@oracle.com wrote:
Hi Stefan,
It looks good.
Thanks,
Serguei
On 7/2/19 06:53, Stefan Karlsson wrote:
Hi all,
Please review this patch to read objects with AS_NO_KEEPALIVE in the
HeapDumper.
http://cr.openjdk.java.net
Thanks, Kim.
StefanK
On 2019-07-03 00:11, Kim Barrett wrote:
On Jul 2, 2019, at 9:53 AM, Stefan Karlsson wrote:
Hi all,
Please review this patch to read objects with AS_NO_KEEPALIVE in the HeapDumper.
http://cr.openjdk.java.net/~stefank/8227086/webrev.01/
https://bugs.openjdk.java.net
Hi all,
Please review this patch to read objects with AS_NO_KEEPALIVE in the
HeapDumper.
http://cr.openjdk.java.net/~stefank/8227086/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8227086
Found this while running some extra verification code through our
barriers. This is one place
HelloSleep VM.flags -name=UseSerialGC
371:
bool UseSerialGC = false
{product} {default}
Let's see if anyone else has some feedback regarding this.
Thanks,
StefanK
Just my 5c
.. Thomas
On Tue, May 21, 2019, 12:14 Stefan Karlsson
Hi all,
Please review this patch to introduce a new diagnostic command: VM.get_flag.
http://cr.openjdk.java.net/~stefank/8224479/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8224479
Today we have:
- VM.set_flag - which allows the user to set a manageable flag
- VM.flags - which allows
Looks good!
StefanK
On 2019-04-08 03:49, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8221584
webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/
I'm really just sponsoring this fix as the problem was diagnozed by
Robbin Ehn and Stefan Karlsson - thanks guys
Looks good.
StefanK
On 2019-03-25 10:59, Per Liden wrote:
Clean up serviceability/sa/TestUniverse.java to remove the need for the
withZ/withoutZ option we currently pass in. This also changes the test
to only run with the selected GC instead of testing all GCs every time,
which should save
When doing an update on the working copy, since twenty commit has been made
since last update, I got the following:
---
Subversion Exception!
---
Subversion encountered a serious problem.
Please take the time to report this on the Subversion
Thanks, Serguei!
StefanK
On 2019-03-12 22:50, serguei.spit...@oracle.com wrote:
Hi Stefan,
The fix looks good to me.
Testing the tiers 1-7 for different GC's has to be good enough.
Thanks,
Serguei
On 3/12/19 8:19 AM, Stefan Karlsson wrote:
Hi all,
Please review and/or comment
On 2019-03-14 10:21, Erik Helin wrote:
On 12 Mar 2019, at 16:19, Stefan Karlsson wrote:
Hi all,
Hey StefanK,
Please review and/or comment on this change to remove
CodeCache::scavenge_root_nmehods_do from
VM_HeapWalkOperation::collect_simple_roots.
http://cr.openjdk.java.net/~stefank
Hi all,
Please review and/or comment on this change to remove
CodeCache::scavenge_root_nmehods_do from
VM_HeapWalkOperation::collect_simple_roots.
http://cr.openjdk.java.net/~stefank/8220342/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8220342
Thanks, Igor!
StefanK
On 2019-02-22 22:02, Igor Ignatyev wrote:
Hi Stefan,
LGTM.
-- Igor
On Feb 22, 2019, at 1:00 PM, Stefan Karlsson wrote:
Hi all,
Please review this patch to ProblemList
serviceability/sa/TestJmapCoreMetaspace.java
https://cr.openjdk.java.net/~stefank/8219571/webrev
Hi all,
Please review this patch to ProblemList
serviceability/sa/TestJmapCoreMetaspace.java
https://cr.openjdk.java.net/~stefank/8219571/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8219571
Original bug:
https://bugs.openjdk.java.net/browse/JDK-8219443
Thanks,
StefanK
Thanks, Erik.
StefanK
On 2019-02-18 10:35, Erik Österlund wrote:
Hi Stefan,
Looks good!
Thanks,
/Erik
On 2019-02-15 20:25, Stefan Karlsson wrote:
Testing showed that the re-enabling of the retiring of TLABs was
broken. This has been fixed with this patch:
http://cr.openjdk.java.net
nters have the correct colors, otherwise we'll end up crashing when
-XX:+ZUnmapBadViews are used.
With this fix, the patches passes tier1,tier2, and tier3 testing.
Thanks,
StefanK
On 2019-02-13 15:52, Stefan Karlsson wrote:
Hi all,
Please review / comment on this patch to enable a best-effort
these changes:
https://cr.openjdk.java.net/~stefank/zgc/zSABitMapsAndLiveRegions/webrev/
StefanK
Thanks
Kevin
On 14/02/2019 17:12, Stefan Karlsson wrote:
Hi again,
I've separated the live regions iteration refactoring into this patch:
https://cr.openjdk.java.net/~stefank/8219003/webrev.01
Thanks, Yasumasa!
StefanK
On 2019-02-15 01:54, Yasumasa Suenaga wrote:
Hi Stefan,
Both changes look good to me!
Thanks,
Yasumasa
2019年2月15日(金) 2:12 Stefan Karlsson :
Hi again,
I've separated the live regions iteration refactoring into this patch:
https://cr.openjdk.java.net/~stefank
. The copyright year for some of the files need updation.
Sure.
This looks good to me otherwise.
Thanks for reviewing.
StefanK
Thanks,
Jini.
On 2/11/2019 2:09 PM, Stefan Karlsson wrote:
Hi all,
Please review this patch to fix the resolving of oops inside the (VM)
OopHandles.
https
Hi again,
I've separated the live regions iteration refactoring into this patch:
https://cr.openjdk.java.net/~stefank/8219003/webrev.01/
And use this RFE for the ZGC specific parts:
https://cr.openjdk.java.net/~stefank/8218922/webrev.02/
Thanks,
StefanK
On 2019-02-14 14:39, Stefan Karlsson
401 - 500 of 668 matches
Mail list logo
