On Fri, 5 May 2023 07:43:17 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version
On Fri, 5 May 2023 23:32:33 GMT, Alex Menkov wrote:
>> The fix updates JVMTI spec updates description of heap functions to support
>> virtual threads.
>> Virtual threads are not heap roots by design, so
>> FollowReference/IterateOverReachableObjects specs are updated to note only
>> platform
On Fri, 5 May 2023 22:21:36 GMT, Chris Plummer wrote:
> This test was very rarely failing with a exitValue 143 from the debuggee. It
> only happened when the machine was under a lot of stress. After some
> investigation it was realized that on unix OSes it should *always* expect
> exitValue
This test was very rarely failing with a exitValue 143 from the debuggee. It
only happened when the machine was under a lot of stress. After some
investigation it was realized that on unix OSes it should *always* expect
exitValue 143, but for some reason was normally getting exitValue 0. The
The SA document `transported_core.html` contains some tips on getting core
files to work when debugging it on a machine other than the one that produced
it. There are a few improvements that can be made based on information provided
in [JDK-8306437](https://bugs.openjdk.org/browse/JDK-8306437)
> The fix updates JVMTI spec updates description of heap functions to support
> virtual threads.
> Virtual threads are not heap roots by design, so
> FollowReference/IterateOverReachableObjects specs are updated to note only
> platform threads.
> References from thread stacks (including virtual
On Fri, 5 May 2023 05:59:49 GMT, Serguei Spitsyn wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated test
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp
> line
> The fix updates JVMTI FollowReferences implementation to report references
> from virtual threads:
> - unmounted vthreads are detected, their stack references for
> JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL;
> - stacks of mounted vthreads are splitted into 2 parts
On Fri, 5 May 2023 05:48:04 GMT, Serguei Spitsyn wrote:
>> JNI local reporting uses this tricky _is_top_frame/_last_entry_frame stuff
>> I think it would be better to have it in the main do_frame method for better
>> readability
>
> Sorry, I do not see how this improves readability.
> Big
On Fri, 5 May 2023 16:43:10 GMT, Aleksey Shipilev wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8304074: [JMX] Add an approximation of total bytes allocated on the Java
>> heap by the JVM
>
>
On Fri, 5 May 2023 15:11:26 GMT, Volker Simonis wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8304074: [JMX] Add an approximation of total bytes allocated on the Java
>> heap by the JVM
>
>
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method, I've updated the JMM_VERSION to
> 4, but would be happy
On Fri, 5 May 2023 17:29:30 GMT, Paul Hohensee wrote:
>> I agree we should strive to get the value as accurate as possible. I think
>> for operational use at scale, we need to avoid doing safepoints. Holding a
>> `ThreadLock` might also penalize other code that (ab)uses threading (we
>>
On Fri, 5 May 2023 06:43:20 GMT, David Holmes wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8304074: [JMX] Add an approximation of total bytes allocated on the Java
>> heap by the JVM
>
>
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method, I've updated the JMM_VERSION to
> 4, but would be happy
On Fri, 5 May 2023 16:16:37 GMT, Aleksey Shipilev wrote:
>> Paul Hohensee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8304074: [JMX] Add an approximation of total bytes allocated on the Java
>> heap by the JVM
>
>
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method, I've updated the JMM_VERSION to
> 4, but would be happy
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method, I've updated the JMM_VERSION to
> 4, but would be happy
On Fri, 5 May 2023 14:50:30 GMT, Afshin Zafari wrote:
>> The `finalize()` method is removed from base classes/interfaces and are
>> replaced by a Cleaner callback..
>
> Afshin Zafari has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains
On Fri, 5 May 2023 14:44:37 GMT, Afshin Zafari wrote:
>> The `finalize()` method is removed from base classes/interfaces and are
>> replaced by a Cleaner callback..
>
> Afshin Zafari has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Thu, 4 May 2023 15:12:43 GMT, Leonid Mesnik wrote:
> 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate
> objects
>
> caused significant regressions in some benchmarks and should be reverted.
>
> This fix backout changes and update problemlist bugs to new issue.
>
> The fix updates JVMTI FollowReferences implementation to report references
> from virtual threads:
> - unmounted vthreads are detected, their stack references for
> JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL;
> - stacks of mounted vthreads are splitted into 2 parts
On Fri, 5 May 2023 17:19:11 GMT, Daniel D. Daugherty wrote:
> Slowdebug had a better stack trace:
>
>
>
> --- T H R E A D ---
>
>
>
> Current thread (0x7fe4ad0062d0): WorkerThread "GC Thread#0"
> [id=19715, stack(0x74416000,0x74516000)
On Fri, 5 May 2023 16:42:29 GMT, Aleksey Shipilev wrote:
>> The API specification clearly states that this method returns "*an
>> approximation of the total amount of memory allocated in heap*" so in my
>> opinion it is OK to keep it simple here and don't start messing with looks
>> and
On Fri, 5 May 2023 16:49:38 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 5 May 2023 06:45:10 GMT, David Holmes wrote:
>> Please review this addition to com.sun.management.ThreadMXBean that returns
>> the total number of bytes allocated on the Java heap since JVM launch by
>> both terminated and live threads.
>>
>> Because this PR adds a new interface
On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote:
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method,
On Fri, 5 May 2023 06:45:10 GMT, David Holmes wrote:
>> Please review this addition to com.sun.management.ThreadMXBean that returns
>> the total number of bytes allocated on the Java heap since JVM launch by
>> both terminated and live threads.
>>
>> Because this PR adds a new interface
On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote:
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method,
On Fri, 5 May 2023 14:59:36 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with
On Fri, 5 May 2023 14:59:36 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
> This fix just excludes a few hotspot/jdk tests which are not compatible with
> test thread factory. So
> `make -- run-test JTREG_VERBOSE=all JTREG_RETAIN=all
> JTREG_TEST_THREAD_FACTORY=Virtual TEST=:tier1`
> could be executed clearly.
Leonid Mesnik has updated the pull request
On Fri, 5 May 2023 01:06:09 GMT, Leonid Mesnik wrote:
>> 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate
>> objects
>>
>> caused significant regressions in some benchmarks and should be reverted.
>>
>> This fix backout changes and update problemlist bugs to new
On Fri, 5 May 2023 14:59:36 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 5 May 2023 14:59:36 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 5 May 2023 14:59:36 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 5 May 2023 14:48:35 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 172 commits:
>>
>> - Merge branch 'master' into JDK-8291555-v2
>> - Disable new lightweight locking in
On Fri, 5 May 2023 14:53:32 GMT, Daniel D. Daugherty wrote:
>> src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 2562:
>>
>>> 2560: Register lock = op->lock_opr()->as_register();
>>> 2561: if (LockingMode == LM_MONITOR) {
>>> 2562: if (op->info() != null) {
>>
>> Hmmm... other
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with
On Fri, 5 May 2023 14:40:52 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Relax zapped-entry test when calling thread is not owning thread
>
> src/hotspot/share/runtime/lockStack.cpp
On Fri, 5 May 2023 13:38:58 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with
On Fri, 5 May 2023 07:16:12 GMT, Serguei Spitsyn wrote:
>> Afshin Zafari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/
>> and /jpda that are used in
> The `finalize()` method is removed from base classes/interfaces and are
> replaced by a Cleaner callback..
Afshin Zafari has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commits:
- Merge branch 'master' into _8305083
-
> The `finalize()` method is removed from base classes/interfaces and are
> replaced by a Cleaner callback..
Afshin Zafari has updated the pull request incrementally with one additional
commit since the last revision:
8305083: 8305083: Remove finalize() from
On Fri, 5 May 2023 05:54:29 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Fri, 5 May 2023 07:42:17 GMT, Afshin Zafari wrote:
>> Default methods for interface classes were invented to solve a problem of
>> compatibility if I remember correctly. Forcing subclasses to implement the
>> interface method or have a superclass of the subclass to implement the
>>
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with
> This change adds a fast-locking scheme as an alternative to the current
> stack-locking implementation. It retains the advantages of stack-locking
> (namely fast locking in uncontended code-paths), while avoiding the overload
> of the mark word. That overloading causes massive problems with
On Tue, 11 Apr 2023 10:20:25 GMT, Afshin Zafari wrote:
> The `removal` warnings are suppressed out.
> Test:
> `FinalizerInfoTest` and `RunFinalizationTest` are executed locally.
This pull request has now been integrated.
Changeset: f143bf7c
Author:Afshin Zafari
Committer: Coleen
On Fri, 5 May 2023 13:05:39 GMT, Coleen Phillimore wrote:
> You're going to end up with things not overriding this method that should.
??? We are controlling all the classes - we know if anything would need to have
a different implementation of this method.
-
PR Comment:
On Sat, 29 Apr 2023 15:54:23 GMT, Afshin Zafari wrote:
>> The `finalize()` method is removed from base classes/interfaces and are
>> replaced by a Cleaner callback..
>
> Afshin Zafari has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Sat, 29 Apr 2023 15:54:23 GMT, Afshin Zafari wrote:
>> The `finalize()` method is removed from base classes/interfaces and are
>> replaced by a Cleaner callback..
>
> Afshin Zafari has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Fri, 5 May 2023 09:56:44 GMT, Aleksey Shipilev wrote:
> Full `make images` for `macosx-aarch64-zero-fastdebug` requires #13827. After
> that, it survives the build with all two `LockingModes`, but not with
> LockingMode = LM_LIGHTWEIGHT:
This requires significantly more time to implement
On 4 May 2023, at 21:32, Dan Heidinga
mailto:heidi...@redhat.com>> wrote:
I’ve read this draft a number of times and each time I struggled with the
framing of the problem given Java’s success over the past almost 30 years.
The old regime worked when: 1. Almost all the runtime was written in
On Fri, 5 May 2023 02:13:32 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove return variable from remove lambda, fix formatting.
>
>
On Thu, 4 May 2023 22:32:36 GMT, Coleen Phillimore wrote:
> The ResourceHashtable conversion for JDK-8292741 didn't add the resizing
> code. The old hashtable code was tuned for resizing in anticipation of large
> hashtables for JVMTI tags. This patch ports over the old hashtable resizing
>
> The ResourceHashtable conversion for JDK-8292741 didn't add the resizing
> code. The old hashtable code was tuned for resizing in anticipation of large
> hashtables for JVMTI tags. This patch ports over the old hashtable resizing
> code. It also adds a ResourceHashtable::put_fast()
On Thu, 4 May 2023 18:11:56 GMT, Chris Plummer wrote:
>> Unless this test is run as root, it needs sudo privileges. If it gets them,
>> the test runs fine, but leaves a file with root ownership. So jtreg cannot
>> delete it, and you see errors when "make clean" tries to delete it.
>> It's
On Fri, 5 May 2023 08:44:12 GMT, Aleksey Shipilev wrote:
> > ```
> > * zero builds are still failing in the Oracle CI; can you check out zero
> > builds on your end?
> > ```
>
> Can you tell which Zero builds exactly? GHA Zero sanity checks look fine.
>
> My local Zero builds are fine with
On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote:
> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
>
> Please review.
>
> Thanks,
> Adam
This pull request has now been integrated.
Changeset: 3b430b9f
On Thu, 4 May 2023 21:54:11 GMT, Roman Kennke wrote:
> * zero builds are still failing in the Oracle CI; can you check out zero
> builds on your end?
Can you tell which Zero builds exactly? GHA Zero sanity checks look fine.
My local Zero builds are fine with `make hotspot`:
> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
>
> Please review.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
updated
On Fri, 5 May 2023 03:33:51 GMT, Serguei Spitsyn wrote:
>> This small change ensures that repeated bytecode rewrites necessitated by
>> class pool index updates are applied cumulatively when updating the method
>> line number table. The current code applies each change to the original
>>
On Thu, 4 May 2023 17:17:19 GMT, Andrew Dinn wrote:
>> This small change ensures that repeated bytecode rewrites necessitated by
>> class pool index updates are applied cumulatively when updating the method
>> line number table. The current code applies each change to the original
>> table
On Thu, 4 May 2023 09:26:33 GMT, Andrew Dinn wrote:
> This small change ensures that repeated bytecode rewrites necessitated by
> class pool index updates are applied cumulatively when updating the method
> line number table. The current code applies each change to the original table
> which
On Thu, 4 May 2023 17:56:59 GMT, Coleen Phillimore wrote:
> To solve the duplicated registerCleanup() cases, the two other classes could
> extend FinalizableObject then inherit its implementation of registerCleanup().
The other two cases already extend the `Log.Logger` and cannot extend
> Hi all,
>
> Please review the implementation of Generational ZGC, which can be turned on
> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
> ZGC is a major rewrite of the non-generational ZGC version that exists in the
> openjdk/jdk repository. It splits the heap
On Thu, 4 May 2023 15:50:02 GMT, Adam Sotona wrote:
> Most of the manpages were updated a few years ago but some references remain.
> This patch renames remaining references to "macOS".
>
> Please review.
>
> Thanks,
> Adam
Marked as reviewed by sspitsyn (Reviewer).
-
PR Review:
On Sat, 29 Apr 2023 15:54:23 GMT, Afshin Zafari wrote:
>> The `finalize()` method is removed from base classes/interfaces and are
>> replaced by a Cleaner callback..
>
> Afshin Zafari has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Sat, 29 Apr 2023 15:54:23 GMT, Afshin Zafari wrote:
>> The `finalize()` method is removed from base classes/interfaces and are
>> replaced by a Cleaner callback..
>
> Afshin Zafari has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Fri, 5 May 2023 06:28:59 GMT, Yadong Wang wrote:
>> Thanks for reporting. It would be interesting to see what address you get
>> and compare it to the range [ZAddressHeapBase,
>> ZAddressHeapBase+ZAddressOffsetMax).
>
> We emailed to erik to discuss this issue two months ago, and maybe he
On Fri, 5 May 2023 01:06:09 GMT, Leonid Mesnik wrote:
>> 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate
>> objects
>>
>> caused significant regressions in some benchmarks and should be reverted.
>>
>> This fix backout changes and update problemlist bugs to new
On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote:
> Please review this addition to com.sun.management.ThreadMXBean that returns
> the total number of bytes allocated on the Java heap since JVM launch by both
> terminated and live threads.
>
> Because this PR adds a new interface method,
On Thu, 4 May 2023 22:11:56 GMT, Daniel D. Daugherty wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address @dcubed-ojdk review comments
>
> I have a Tier3 test failure:
>
On Fri, 5 May 2023 05:17:44 GMT, Stefan Karlsson wrote:
>> test/hotspot/gtest/gc/z/test_zForwarding.cpp line 68:
>>
>>> 66:
>>> 67: bool reserved =
>>> os::attempt_reserve_memory_at((char*)ZAddressHeapBase, ZGranuleSize, false
>>> /* executable */);
>>> 68: ASSERT_TRUE(reserved);
>>
On Fri, 5 May 2023 06:21:18 GMT, David Holmes wrote:
> Updates look good to me. Thanks.
Nice, thank you!
The PR has 4 approvals now. Are we good to go, or should I wait for others to
approve? (And if so, who?)
-
PR Comment:
On Fri, 5 May 2023 05:54:29 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Thu, 4 May 2023 23:20:21 GMT, Alex Menkov wrote:
>> The fix updates JVMTI FollowReferences implementation to report references
>> from virtual threads:
>> - unmounted vthreads are detected, their stack references for
>> JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL;
>> -
80 matches
Mail list logo
