On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Mon, 25 Apr 2022 15:51:35 GMT, Coleen Phillimore wrote:
>> Albert Mingkun Yang has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove REF_ enum for java.lang.ref.Reference
>>
>> Signed-off-by: Albert Yang
>
> src/hotspot/share/o
On Fri, 22 Apr 2022 09:04:37 GMT, Kim Barrett wrote:
> > > Using REF_SOFT seems too hacky.
> >
> >
> > Just to put all alternatives on the table. The use of `REF_SOFT` is
> > ephemeral.
> > [...]
> > I have no particular preference. What does everyone think?
>
> I also think using REF_SOFT li
On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> review
Using REF_SOFT seems too hacky. If we
On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> review
That's unfortunate. The allocate_inst
On Thu, 21 Apr 2022 11:30:20 GMT, Albert Mingkun Yang wrote:
>> Simple rename and some comments update.
>>
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> review
Do we even need REF_OTHER / REF_REFER
On Fri, 15 Apr 2022 07:40:04 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on hotspot, and accepted those changes where it indeed
> discovered real typos.
>
> You'd be surprised over the many implementions of instrinsics and other
> intructions accross all archtectures I've encounted, so
On Mon, 22 Nov 2021 13:49:02 GMT, Erik Österlund wrote:
> The VM_HeapDumper code uses a C heap allocated ParallelObjectIterator. It is
> constructed right before running a parallel operation with a work gang, but
> freed in the destructor of the VM_HeapDumper. This means it is created on one
>
On Mon, 11 Oct 2021 09:21:21 GMT, Per Liden wrote:
> I propose that we clean up our GangWorker/WorkGang and related classes, to
> remove abstractions we no longer need (after CMS was removed, MutexDispatcher
> was removed, Parallel is now using WorkGang, etc) and adjusting names as
> follows:
Hi Simeon,
On 2021-06-23 12:39, S A wrote:
Hi all,
my colleagues recently ran into a crash in libjdwp, when measuring
performance with OpenJDK 17 (early access build). The same crash was
observed with OpenJDK 16.0.1, but not with OpenJDK 15.
We are hoping to get a fix for the crash, before the
On Tue, 22 Jun 2021 07:17:00 GMT, Guoxiong Li wrote:
>> Hi all,
>>
>> Considering the consistency of `JavaThread` and other threads, such as
>> WorkerThread and CompilerThread, `JavaThread` could use a method named
>> `cast` to replace the method `Thread::as_Java_thread()`. It can reduce the
On Thu, 20 May 2021 11:55:05 GMT, Stefan Karlsson wrote:
> I'd like to propose a small adjustment to how we write .inline.hpp files, in
> the hope to reduce include problems because of circular dependencies between
> inline headers.
>
> This is a small, contrived example
On Mon, 31 May 2021 06:44:45 GMT, Stefan Karlsson wrote:
>> I'd like to propose a small adjustment to how we write .inline.hpp files, in
>> the hope to reduce include problems because of circular dependencies between
>> inline headers.
>>
>> This is a s
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blan
On Fri, 28 May 2021 13:42:30 GMT, Martin Doerr wrote:
>> We need a fix for crashes in get_current_contended_monitor due to concurrent
>> modification of memory locations which are not declared volatile. See bug
>> for details.
>
> Martin Doerr has updated the pull request incrementally with one
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank
On Thu, 27 May 2021 04:01:17 GMT, Leonid Mesnik wrote:
> 8265148: StackWatermarkSet being updated during AsyncGetCallTrace
Looks good. Could you verify the fix with ZGC? G1 doesn't use it, so testing
with G1 will only show that we don't hit the failing assert anymore.
-
Marked as
On Wed, 26 May 2021 18:00:54 GMT, Stefan Karlsson wrote:
>> I'd like to propose a small adjustment to how we write .inline.hpp files, in
>> the hope to reduce include problems because of circular dependencies between
>> inline headers.
>>
>> This is a s
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank
On Wed, 26 May 2021 02:18:06 GMT, David Holmes wrote:
> Hi Stefan,
>
> I think this policy makes a lot of sense!
>
> I only scanned through the changes to get a sense of them but it all seemed
> fine.
>
> Thanks,
> David
Thanks a lot for reviewing!
> doc/hotspot-style.html line 97:
>
>> 95
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include and a e
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include and a extra blank
On Mon, 24 May 2021 00:14:06 GMT, Kim Barrett wrote:
>> Stefan Karlsson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Clean up assembler_.inline.hpp
>
> Code changes look fine. This needs an update t
hould be moved. I have not done that.
> 2) Some .inline.hpp files don't have a corresponding .hpp file. I could
> either try to fix that in this patch, or we could take care of that as
> separate patches later.
> 3) The style I chose was to add the .hpp include a
I'd like to propose a small adjustment to how we write .inline.hpp files, in
the hope to reduce include problems because of circular dependencies between
inline headers.
This is a small, contrived example to show the problem:
// a.hpp
#pragma once
void a1();
void a2();
// a.inline.hpp
#pragm
On Wed, 5 May 2021 01:35:11 GMT, Yasumasa Suenaga wrote:
> `ZAddress::address()` has been removed since
> [JDK-8235748](https://bugs.openjdk.java.net/browse/JDK-8235748), however SA
> has not followed it. Thus some SA tests would fail with ZGC.
> After this change, more than half of jtreg tests
On Wed, 14 Apr 2021 00:35:55 GMT, Tom Rodriguez wrote:
> 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of
> nmethods
src/hotspot/share/prims/jvmtiExport.cpp line :
> 1109: : JvmtiMethodEventMark(thread,methodHandle(thread,
> nm->method())) {
> 1110: _
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Thu, 25 Mar 2021 07:27:58 GMT, Kim Barrett wrote:
> Please review this change to OopStorage to allow the MEMFLAGS value for
> associated allocations to be specified when the storage object is
> constructed. This allows a subsystem that needs an OopStorage object to
> associate its allocati
On Mon, 15 Mar 2021 12:35:47 GMT, Stefan Karlsson wrote:
> JavaValue is a small wrapper class that wraps values used to pass arguments
> and results between native and Java.
>
> When JavaCalls::call returns an object, the value stored in the JavaValue is
> not a handliezed j
On Mon, 15 Mar 2021 21:27:54 GMT, Coleen Phillimore wrote:
>> JavaValue is a small wrapper class that wraps values used to pass arguments
>> and results between native and Java.
>>
>> When JavaCalls::call returns an object, the value stored in the JavaValue is
>> not a handliezed jobject. Inst
On Mon, 15 Mar 2021 21:25:30 GMT, Coleen Phillimore wrote:
>> JavaValue is a small wrapper class that wraps values used to pass arguments
>> and results between native and Java.
>>
>> When JavaCalls::call returns an object, the value stored in the JavaValue is
>> not a handliezed jobject. Inst
JavaValue is a small wrapper class that wraps values used to pass arguments and
results between native and Java.
When JavaCalls::call returns an object, the value stored in the JavaValue is
not a handliezed jobject. Instead it's a raw oop. So, most of the code handling
the `result`, fetches the
On Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov wrote:
>> src/hotspot/share/runtime/thread.cpp line 2515:
>>
>>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread
>>> *thread) {
>>> 2514: // Enable WXWrite: called directly from interpreter native wrapper.
>>> 2515: MA
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 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 the
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
>> th
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 that poi
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 that poi
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 has
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
>> ta
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 that
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
> table
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: https://git.openjdk.java
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 and self
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 stack,
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 # asser
List-zgc.txt Five 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
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 # asser
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(processing_started()) failed: Processing should already
have started
The stack traces for thi
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. S
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 interprete
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 fra
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 fra
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 fra
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 fra
ds=100" 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.
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
"
*Date: *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(G
-
From: "Hohensee, Paul"
Date: Thursday, July 23, 2020 at 6:48 AM
To: "linzang(臧琳)" , Stefan Karlsson ,
"serguei.spit...@oracle.com" , David Holmes , ser
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
https://cr.openjdk.jav
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 of
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 all
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 colle
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 at
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 helpe
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
ProcessTools.createJavaProcessBuil
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 bo
;
wrote:
Dear Stefan,
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
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 elsewher
er check 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
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 t
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
+++ b
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: http:/
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 suggesti
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, wh
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.
W
ushed 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-1
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 cou
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 t
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
3) JVMCI maintainers
Thanks,
StefanK
On 2019-08-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
08-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 ver
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 where
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 Kar
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 t
1 - 100 of 220 matches
Mail list logo
