On Tue, 4 Jun 2024 20:51:52 GMT, Cesar Soares Lucas wrote:
> Please, consider this patch to remove unused methods from the code base. To
> the best of my knowledge, these methods are only defined but never used.
>
> Here is a list with names of delete methods:
>
On Fri, 5 Apr 2024 12:32:30 GMT, Stefan Karlsson wrote:
> The GCs scan and handles nmethods and ignores CodeBlobs of other kinds. The I
> propose that we stop sending in CodeBlobs to the GCs and make sure to only
> give them nmethods.
>
> I removed `void CodeCache::blobs_do(CodeBlobClosure*
On Wed, 14 Jun 2023 01:02:09 GMT, Alex Menkov wrote:
> If virtual thread has frames in stackChunks, need to apply load barriers
> before processing nmethods (javaVFrame::locals() and
> javaVFrame::expressions() do it internally)
>
> Testing: tier1-tier5;
> 400 runs of VThreadStackRefTest.java
jdk) repository.
>
> The commit being backported was authored by Axel Boldt-Christmas on 20 Jun
> 2023 and was reviewed by Stefan Karlsson, Erik Österlund and Thomas Stuefe.
>
> Thanks!
Looks good.
-
Marked as reviewed by eosterlund (Reviewer).
PR Review: https:/
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote:
> Generational ZGC changed the location where the heap object iterator called
> the visit function. It used to be called when the objects were popped and
> then followed, but it was changed so that the function where called
>
On Fri, 16 Jun 2023 11:41:14 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
On Tue, 9 May 2023 07:27:46 GMT, Kim Barrett wrote:
>> Stefan Karlsson has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Workaround failed reservation in ZForwardingTest
>
> src/hotspot/share/code/relocInfo.hpp line 1105:
>
>> 1103:
: Stefan Karlsson
>>Co-authored-by: Per Liden
>>Co-authored-by: Albert Mingkun Yang
>>Co-authored-by: Erik Österlund
>>Co-authored-by: Axel Boldt-Christmas
>>Co-authored-by: Stefan Johansson
>> - UPSTREAM: Introduce check_oop infrastructure
On Sat, 6 May 2023 08:14:24 GMT, Quan Anh Mai wrote:
>> src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp line 310:
>>
>>> 308: // A not relocatable object could have spurious raw null pointers
>>> in its fields after
>>> 309: // getting promoted to the old generation.
>>> 310:
On Thu, 4 May 2023 12:08:28 GMT, Stefan Johansson wrote:
> Please review this fix to avoid a tier1 test failure.
>
> **Summary**
> The newly added test wrongfully assumed that one of the transformed classes
> would be in use. This seem to be the case in most runs, but there is no
> guarantee.
On Wed, 3 May 2023 09:04:50 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 that
On Mon, 27 Mar 2023 18:47:31 GMT, Roman Kennke wrote:
> > > > > > @rkennke Question about ZGC and LockStack::contains(): how does
> > > > > > this work with colored pointers? Don't we have to mask the color
> > > > > > bits out somehow when comparing? E.g. using `ZAddress::offset()` ?
>
> > >
On Mon, 27 Mar 2023 17:30:03 GMT, Roman Kennke wrote:
> > > > @rkennke Question about ZGC and LockStack::contains(): how does this
> > > > work with colored pointers? Don't we have to mask the color bits out
> > > > somehow when comparing? E.g. using `ZAddress::offset()` ?
>
> > >
>
> > >
On Mon, 27 Mar 2023 15:53:47 GMT, Roman Kennke wrote:
> > @rkennke Question about ZGC and LockStack::contains(): how does this work
> > with colored pointers? Don't we have to mask the color bits out somehow
> > when comparing? E.g. using `ZAddress::offset()` ?
>
>
>
> That would be a
On Thu, 23 Mar 2023 08:27:23 GMT, Johannes Bechberger
wrote:
> The best alternative to me is to take the perf hit and disable the caching
> when we're in forte (possibly only on Mac).
Sounds like a plan.
-
PR Comment:
On Thu, 23 Mar 2023 07:27:14 GMT, Johannes Bechberger
wrote:
> > You now effectively disable execution of generated code for the whole
> > extend of AGCT?
>
>
>
> That's exactly what async-profiler does already
>
On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger
wrote:
> Fixes the issue by transitioning the thread into the WXWrite mode while
> walking the stack in AsyncGetCallTrace.
>
> Tested on my M1 mac.
Drive by comment: how async safe is WX enabler? If a thread is in the middle of
it and we
On Thu, 16 Feb 2023 08:38:42 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> The original issue was when thread 1 asked to deopt nmethod set X and thread
> 2 asked for the same or a subset of X.
> All method will already be marked, but the actual deoptimizing, not entrant,
> patching PC
On Wed, 25 Jan 2023 15:56:49 GMT, Coleen Phillimore wrote:
> We thought we didn't need the keep-alive call but we do for heap walking.
> Tested with failing test case locally, and tier1-4 in progress.
Looks good!
-
Marked as reviewed by eosterlund (Reviewer).
PR:
On Mon, 9 Jan 2023 14:50:50 GMT, Erik Österlund wrote:
>> Please review this change to remove GCCause::_wb_conc_mark and the supporting
>> implementation. After JDK-8293824 it is no longer used as the cause when
>> requesting a GC.
>>
>> Note: The implementatio
On Sat, 7 Jan 2023 17:41:04 GMT, Kim Barrett wrote:
> Please review this change to remove GCCause::_wb_conc_mark and the supporting
> implementation. After JDK-8293824 it is no longer used as the cause when
> requesting a GC.
>
> Note: The implementation in ZGC appears to have never been used.
On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore wrote:
> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror
> so that the verification has the right mirror, but it really should just copy
> it. Replacing an OopHandle in the ClassLoaderData didn't set the
>
On Fri, 18 Nov 2022 12:30:19 GMT, Erik Österlund wrote:
> There is a stack walk in JvmtiExport::post_exception_throw() that has
> safepoints in it. This trips up the stack watermark code. This patch adds a
> RAII object to JvmtiExport::post_exception_throw() that keeps the thread a
On Fri, 11 Nov 2022 16:16:18 GMT, Erik Österlund wrote:
> The current loom code makes some assumptions about GC that will not work with
> generational ZGC. We should make this code more GC agnostic, and provide a
> better interface for talking to the GC.
>
> In particular,
&g
On Mon, 28 Nov 2022 15:49:30 GMT, Erik Österlund wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>>
On Wed, 30 Nov 2022 10:09:14 GMT, Serguei Spitsyn wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add comment
>
> Thank you for the update. I agree with David that it is not v
stead.
> Currently there is no more than one of these, so doing it lazily per frame
> seems a bit overkill.
>
> 3) Refactoring the stack chunk allocation code
>
> Tested with tier1-5 and manually running Skynet. No regressions detected. We
> have also been running with this (yet
On Mon, 21 Nov 2022 12:17:02 GMT, Patricio Chilano Mateo
wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix Richard comments
>
> I went through the changes and all looks g
stead.
> Currently there is no more than one of these, so doing it lazily per frame
> seems a bit overkill.
>
> 3) Refactoring the stack chunk allocation code
>
> Tested with tier1-5 and manually running Skynet. No regressions detected. We
> have also been running with this (yet
On Fri, 18 Nov 2022 12:30:19 GMT, Erik Österlund wrote:
> There is a stack walk in JvmtiExport::post_exception_throw() that has
> safepoints in it. This trips up the stack watermark code. This patch adds a
> RAII object to JvmtiExport::post_exception_throw() that keeps the thread a
n.
> Testing: tier1-7 of ZGC tests on linux x86_64 debug and manual testing of the
> test that failed.
Erik Österlund has updated the pull request incrementally with one additional
commit since the last revision:
Add comment
-
Changes:
- all: https://git.openjdk.org/jd
There is a stack walk in JvmtiExport::post_exception_throw() that has
safepoints in it. This trips up the stack watermark code. This patch adds a
RAII object to JvmtiExport::post_exception_throw() that keeps the thread and
its stack fully processed throughout the function.
Testing: tier1-7 of
On Thu, 17 Nov 2022 11:16:52 GMT, Richard Reingruber wrote:
>> The compiler should be able to do that already. We devirtualize calls into
>> oop closures, and the closure is stack allocated. So the compiler should be
>> able to do that if it finds that it is a good idea. I'd prefer to leave
On Thu, 17 Nov 2022 11:23:07 GMT, Richard Reingruber wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix Richard comments
>
> Marked as reviewed by rrich (Reviewer).
Th
On Wed, 16 Nov 2022 15:47:37 GMT, Richard Reingruber wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Indentation fix
>
> Hi @fisk, I've skimmed the changes. They look good to m
stead.
> Currently there is no more than one of these, so doing it lazily per frame
> seems a bit overkill.
>
> 3) Refactoring the stack chunk allocation code
>
> Tested with tier1-5 and manually running Skynet. No regressions detected. We
> have also been running with this (yet
On Tue, 15 Nov 2022 09:39:27 GMT, Fei Yang wrote:
>> PS: I see JVM crashes when running Skynet with extra VM option:
>> -XX:+VerifyContinuations on linux-aarch64 platform.
>>
>> $java --enable-preview -XX:+VerifyContinuations Skynet
>>
>>
>> # A fatal error has been detected by the Java
On Sat, 12 Nov 2022 08:08:15 GMT, Fei Yang wrote:
>> The current loom code makes some assumptions about GC that will not work
>> with generational ZGC. We should make this code more GC agnostic, and
>> provide a better interface for talking to the GC.
>>
>> In particular,
>> 1) All GCs have a
stead.
> Currently there is no more than one of these, so doing it lazily per frame
> seems a bit overkill.
>
> 3) Refactoring the stack chunk allocation code
>
> Tested with tier1-5 and manually running Skynet. No regressions detected. We
> have also been running with this (yet
On Mon, 14 Nov 2022 10:43:23 GMT, Stefan Karlsson wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix verification and RISC-V support
>
> Looks good to me. I wrote parts of
On Sat, 12 Nov 2022 08:08:15 GMT, Fei Yang wrote:
> PS: I see JVM crashes when running Skynet with extra VM option:
> -XX:+VerifyContinuations on linux-aarch64 platform.
>
> $java --enable-preview -XX:+VerifyContinuations Skynet
>
> ```
> # A fatal error has been detected by the Java Runtime
On Sat, 12 Nov 2022 01:30:57 GMT, Fei Yang wrote:
> > Nice to have PR 1. It's gonna take a long time until we see 11.
>
> Nice PR number :-) May I ask if you could also add handling for riscv while
> you are at it? We have ported loom to this platform recently [1]. I can help
>
stead.
> Currently there is no more than one of these, so doing it lazily per frame
> seems a bit overkill.
>
> 3) Refactoring the stack chunk allocation code
>
> Tested with tier1-5 and manually running Skynet. No regressions detected. We
> have also been running with this (yet
On Fri, 11 Nov 2022 16:16:18 GMT, Erik Österlund wrote:
> The current loom code makes some assumptions about GC that will not work with
> generational ZGC. We should make this code more GC agnostic, and provide a
> better interface for talking to the GC.
>
> In particular,
&g
The current loom code makes some assumptions about GC that will not work with
generational ZGC. We should make this code more GC agnostic, and provide a
better interface for talking to the GC.
In particular,
1) All GCs have a way of encoding oops inside of the heap differently to oops
outside
On Fri, 11 Nov 2022 14:26:20 GMT, Stefan Karlsson wrote:
> The sorted blocks of includes have deteriorated to the point that I felt
> compelled to clean up some of the issues.
>
> One of the more prevalent issues is that files in src/hotspot/share/include
> are not properly sorted. There has
On Thu, 3 Nov 2022 12:46:00 GMT, Coleen Phillimore wrote:
>> Use identity_hash for objects in the JVMTI TagMap table. If the object has
>> no hashcode, it's not in the table.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit
On Wed, 2 Nov 2022 22:23:57 GMT, Coleen Phillimore wrote:
>> Use identity_hash for objects in the JVMTI TagMap table. If the object has
>> no hashcode, it's not in the table.
>> Tested with tier1-6.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit
On Thu, 3 Nov 2022 03:41:26 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove now-unused function that I missed.
>
> src/hotspot/share/gc/z/zHeap.inline.hpp line 48:
>
>> 46: inline
On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman wrote:
> > There is a bunch of VM code for this too. Should we clean that up
> > separately?
>
>
>
> Yes chatted with @dholmes-ora about this recently and he suggested separating
> out so there is a follow-on JBS issue created for that. Aside
On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote:
> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for
> removal, and remove the remaining special handling of ThreadDeath from the
> JDK.
>
> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2
On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class DeoptimizationMarkerClosure : StackObj {
On Mon, 11 Jul 2022 14:58:07 GMT, Axel Boldt-Christmas wrote:
> 8290074: Remove implicit arguments for RegisterMap constructor
Looks good except for a spurious semicolon. Don't need another review for that.
src/hotspot/share/runtime/frame.cpp line 85:
> 83: RegisterMap::RegisterMap(oop
53 matches
Mail list logo
