On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote:
>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
>> capabilities are enabled and --enable-preview.
>>
>> It restores the same behavior as it was before
>> https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable
On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote:
> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
> capabilities are enabled and --enable-preview.
>
> It restores the same behavior as it was before
> https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape
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,
On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched
On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched
On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched
On Thu, 10 Feb 2022 08:46:50 GMT, Emanuel Peter wrote:
>> Deprecated ExtendedDTraceProbes.
>> Edited help messages and man pages accordingly, added the 3 flags to man
>> pages.
>> Added flag to VMDeprecatedOptions test.
>> Replaced the flag with 3 flags in SDTProbesGNULinuxTest.java.
>>
>>
Hi
The question about dropping DTrace support in HotSpot VM rose during discussion 8278423: "ExtendedDTraceProbes should be
deprecated" [1].
It is not clear for me about Oracle support for it after we dropped SPARC. Do we still need to support it or we can drop
it (remove code from HotSpot)?
On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote:
> This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to
> JDK 18.
>
> Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in
> unloaded nmethods, but redefinition doesn't keep this metadata
On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote:
> This PR contains a relatively simple test which verifies that JVMTI-agents
> are correctly informed about exceptions caught in C2-compiled code. The
> 8269574 introduces pre-allocated exceptions in some paths, so the test tries
> to
On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote:
> This PR contains a relatively simple test which verifies that JVMTI-agents
> are correctly informed about exceptions caught in C2-compiled code. The
> 8269574 introduces pre-allocated exceptions in some paths, so the test tries
> to
On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin wrote:
> This PR contains a relatively simple test which verifies that JVMTI-agents
> are correctly informed about exceptions caught in C2-compiled code. The
> 8269574 introduces pre-allocated exceptions in some paths, so the test tries
> to
On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich
wrote:
> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be
> qualified.
> Testing:
> - `make test TEST="gtest"`: Passed
> - `make run-test TEST="tier1"`: Passed
> - `make run-test TEST="tier2"`: Passed
> - `make
On Tue, 2 Nov 2021 23:03:22 GMT, Evgeny Astigeevich
wrote:
> Is NULL method holder an acceptable situation? Could it be a sign of a bug?
You are right, all methods should have class holders. I just followed code
pattern.
> BTW, `Klass::external_name()` returns `` if `Klass::name()` is
>
On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich
wrote:
> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be
> qualified.
> Testing:
> - `make test TEST="gtest"`: Passed
> - `make run-test TEST="tier1"`: Passed
> - `make run-test TEST="tier2"`: Passed
> - `make
On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich
wrote:
> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be
> qualified.
> Testing:
> - `make test TEST="gtest"`: Passed
> - `make run-test TEST="tier1"`: Passed
> - `make run-test TEST="tier2"`: Passed
> - `make
On Mon, 1 Nov 2021 20:51:39 GMT, Evgeny Astigeevich
wrote:
> This PR changes nmethods names in `METHOD NAMES for CodeHeap` section to be
> qualified.
> Testing:
> - `make test TEST="gtest"`: Passed
> - `make run-test TEST="tier1"`: Passed
> - `make run-test TEST="tier2"`: Passed
> - `make
On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote:
> This logic no longer seems to be necessary since the adjustCompilationLevel
> callback has been removed.
Yes, running locally with GraalVM is fine.
-
Marked as reviewed by kvn (Reviewer).
PR:
On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote:
> This logic no longer seems to be necessary since the adjustCompilationLevel
> callback has been removed.
@tkrodriguez Did you test this changes with GraalVM?
Would be nice to run it with command line which Serguei pointed.
We will be
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>> could you please review this big tedious and trivial(-ish) patch which moves
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>
>> the majority of the patch is the following substitutions:
>>
On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this big tedious and trivial(-ish) patch which moves
> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>
> the majority of the patch is the following substitutions:
> -
On Tue, 27 Jul 2021 09:24:38 GMT, Nick Gasson wrote:
> This test fails reliably with `-XX:TieredStopAtLevel=1` since JDK-8251462.
> MDOs are no longer allocated in this mode so the clhsdb `printmdo -a` command
> prints nothing. The failure is basically the same as JDK-8236042 which
>
On Fri, 16 Jul 2021 10:24:56 GMT, Nick Gasson wrote:
> The clhsdb jstack command crashes when the debugged program is run with
> `-Xcomp -XX:+StressGCM -XX:StressSeed=2` on AArch64:
>
>
> sun.jvm.hotspot.utilities.AssertionFailure: sanity check
> at
On Fri, 2 Jul 2021 07:03:50 GMT, David Holmes wrote:
> Please review this simple refactoring to share the common code used to create
> j.l.Thread instances for the internal VM JavaThreads. (Also fix a missing
> space from my previous change in thread.cpp.)
>
> It is all very straight-forward.
On Thu, 1 Jul 2021 22:17:27 GMT, David Holmes wrote:
>> Please see the JBS issue for more details, but basically we have 8 different
>> kinds of internal VM JavaThreads (grouping the three types of CompilerThread
>> together) that all basically duplicated the logic for initializing
>>
On Thu, 1 Jul 2021 22:02:40 GMT, David Holmes wrote:
>> src/hotspot/share/compiler/compileBroker.cpp line 939:
>>
>>> 937: && comp->num_compiler_threads() > 0) {
>>> 938: // The new thread is not known to Thread-SMR yet so we can just
>>> delete.
>>> 939: delete new_thread;
On Thu, 1 Jul 2021 04:18:28 GMT, David Holmes wrote:
>> Please see the JBS issue for more details, but basically we have 8 different
>> kinds of internal VM JavaThreads (grouping the three types of CompilerThread
>> together) that all basically duplicated the logic for initializing
>>
On Wed, 30 Jun 2021 17:27:00 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList sun/management/jdp/JdpDefaultsTest.java on
> Linux-aarch64.
trivial
-
Marked as reviewed by kvn (Reviewer).
PR: https://git.openjdk.java.net/jdk17/pull/182
On Wed, 16 Jun 2021 12:52:46 GMT, Coleen Phillimore wrote:
> This change removes the mark_for_evol_deoptimization method and removes the
> flag that all dependencies are recorded. Before the change to walk the
> entire nmethod looking for "old" (redefined) methods with metadata_do(), we
>
On Fri, 28 May 2021 07:24:37 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 to show the
On Tue, 11 May 2021 01:56:21 GMT, David Holmes wrote:
>> Our code is littered with API's that take, or manifest, a Thread* and then
>> assert/guarantee that it must be a JavaThread, rather than
>> taking/manifesting a JavaThread in the first place. The main reason for this
>> is that the
On Thu, 8 Apr 2021 15:23:52 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 V
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains six commits:
- Merge
On Wed, 14 Apr 2021 00:35:55 GMT, Tom Rodriguez wrote:
> 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of
> nmethods
Good.
-
Marked as reviewed by kvn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3481
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Address review comments
-
On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/methodCounters.
On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/jvmci/jvmciCodeInsta
On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/instanc
On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/code/comp
On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/memory/heap.h
On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/globalDefinit
On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/compiledIC_x86.c
On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov wrote:
>> Hi Vladimir,
>>
>> This looks good to me - I went through all the files.
>>
>> It was nice to see how nicely compartmentalized the AOT feature was - that
>> made checking the cha
On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes wrote:
> Hi Vladimir,
>
> This looks good to me - I went through all the files.
>
> It was nice to see how nicely compartmentalized the AOT feature was - that
> made checking the changes quite simple. The one exception was the
> fingerprinting
On Thu, 8 Apr 2021 20:59:59 GMT, Coleen Phillimore wrote:
> There's a comment above
> void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) {
> that should be rewritten, so I think we should just file an RFE to remove it
> afterwards.
https://bugs.openjdk.java.net/browse/JDK-8264941
On Thu, 8 Apr 2021 20:00:30 GMT, Vladimir Kozlov wrote:
>> GC changes look good.
>
>> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
>> This function, its caller and the function in jvmtiRedefineClasses.cpp that
>> calls it can be del
On Thu, 8 Apr 2021 19:58:11 GMT, Stefan Karlsson wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> GC change
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request incrementally with one additional
commit since the last revision:
Remove exports from Graal module t
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Merge
y `#if INCLUDE_AOT`
>
> Additionally, remove tests as well as code in makefiles related to AoT
> compilation.
>
> Tested hs-tier1-4
Vladimir Kozlov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two commits:
- Merge
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
- related HotSpot code guarded by `#if INCLUDE_AOT`
Additionally,
On Wed, 3 Mar 2021 13:28:21 GMT, Lutz Schmidt wrote:
>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of
>> method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow
>> probability way out (> 500 years in case
On Tue, 2 Mar 2021 17:23:23 GMT, Lutz Schmidt wrote:
>> src/hotspot/cpu/x86/vtableStubs_x86_32.cpp line 159:
>>
>>> 157: return NULL;
>>> 158: }
>>> 159:
>>
>> Why you did not update asm instruction to update `nof_megamorphic_calls` in
>> this file?
>
> The reason is plain simple:
On Thu, 25 Feb 2021 09:01:10 GMT, Lutz Schmidt wrote:
>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of
>> method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow
>> probability way out (> 500 years in case
On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote:
>> This change removes the legacy compilation policy and an emulation mode to
>> the tiered policy to simulate the old behavior with
>> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter
>> code, devirtualizes the
On Sun, 24 Jan 2021 03:53:00 GMT, Igor Veresov wrote:
>> This change removes the legacy compilation policy and an emulation mode to
>> the tiered policy to simulate the old behavior with
>> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter
>> code, devirtualizes the
On Fri, 22 Jan 2021 20:17:24 GMT, Igor Veresov wrote:
>> I don't think so:
>>> java -Xint -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -version
>> Java HotSpot(TM) 64-Bit Server VM warning: JVMCI Compiler disabled due to
>> -Xint.
>>
>>> java -Xint -XX:+UnlockExperimentalVMOptions
On Fri, 22 Jan 2021 19:50:48 GMT, Igor Veresov wrote:
>> src/hotspot/share/compiler/compilerDefinitions.cpp line 84:
>>
>>> 82: } else if (CompilerConfig::is_c2_or_jvmci_compiler_only()) {
>>> 83: _mode = Mode::HIGH_ONLY;
>>> 84: } else if (CompilerConfig::is_jvmci_compiler() &&
On Fri, 22 Jan 2021 18:26:43 GMT, Igor Veresov wrote:
>> Hmm, may be we don't need these funxctions.
>> Seems is_c1_only() will be true only when JVMCI is off. Right? We can also
>> reinforce it to exclude AOT too.
>> And AOT and JVMCI are disabled with -Xint.
>
> It's not so easy. You can have
On Fri, 22 Jan 2021 18:15:40 GMT, Igor Veresov wrote:
>> src/hotspot/share/compiler/compilerDefinitions.cpp line 62:
>>
>>> 60: }
>>> 61: } else if (strcmp(CompilationMode, "high-only") == 0) {
>>> 62: if (!CompilerConfig::has_c2() &&
>>> !CompilerConfig::is_jvmci_compiler()) {
On Fri, 22 Jan 2021 15:19:39 GMT, Igor Veresov wrote:
>> src/hotspot/share/compiler/compilerDefinitions.hpp line 234:
>>
>>> 232: static bool is_interpreter_only() {
>>> 233: return Arguments::is_interpreter_only() || TieredStopAtLevel ==
>>> CompLevel_none;
>>> 234: }
>>
>> Can you
On Fri, 22 Jan 2021 17:14:15 GMT, Igor Veresov wrote:
>> src/hotspot/share/aot/aotCodeHeap.cpp line 194:
>>
>>> 192: // AOT libs are loaded before heap initialized so shift values are
>>> not set.
>>> 193: // It is okay since ObjectAlignmentInBytes flag which defines shifts
>>> value is
On Fri, 22 Jan 2021 14:21:52 GMT, Roland Westrelin wrote:
> I noticed that the SA's dumpreplaydata command fails with:
>
> java.lang.AssertionError: CLHSDB wasn't run successfully: Opening core file,
> please wait...
> hsdb> Exception in thread "main" java.lang.InternalError: ciMetadata does
On Tue, 12 Jan 2021 05:04:11 GMT, Igor Veresov wrote:
>> This change removes the legacy compilation policy and an emulation mode to
>> the tiered policy to simulate the old behavior with
>> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter
>> code, devirtualizes the
On Thu, 7 Jan 2021 23:06:19 GMT, Igor Veresov wrote:
>> This change removes the legacy compilation policy and an emulation mode to
>> the tiered policy to simulate the old behavior with
>> ```-XX:-TieredCompilation```. The change removed a bunch of interpreter
>> code, devirtualizes the
On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote:
> This moves the mirroring of vmSymbols in ciSymbols to a separate file,
> ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the
> ciSymbol namespace). In a few places code is moved from .hpp to .cpp to
> facilitate
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote:
> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
> experimental feature. We shipped Graal as an experimental JIT compiler in JDK
> 10. We haven't seen much use of these features, and the effort
On Sun, 1 Nov 2020 20:15:01 GMT, Igor Veresov wrote:
>> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
>> experimental feature. We shipped Graal as an experimental JIT compiler in
>> JDK 10. We haven't seen much use of these features, and the effort required
>> to
We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
experimental feature. We shipped Graal as an experimental JIT compiler in JDK
10. We haven't seen much use of these features, and the effort required to
support and enhance them is significant. We therefore intend to disable
On Thu, 29 Oct 2020 14:53:54 GMT, Richard Reingruber wrote:
>> The following test cases try to provoke VMOutOfMemoryException during object
>> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>>
>> EAPopFrameNotInlinedReallocFailure
>>
On Tue, 27 Oct 2020 10:16:29 GMT, Richard Reingruber wrote:
>> The following test cases try to provoke VMOutOfMemoryException during object
>> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>>
>> EAPopFrameNotInlinedReallocFailure
>>
On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty
wrote:
> Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java
> for ZGC.
Good.
-
Marked as reviewed by kvn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/787
On Wed, 21 Oct 2020 17:31:37 GMT, Aleksey Shipilev wrote:
>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
>> point in JDK that can use the intrinsic like this:
>> `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2
>> intrinsic now, hook it up
On Tue, 20 Oct 2020 17:54:21 GMT, Vladimir Kozlov wrote:
>> ...or I can put new test into a separate file. But the existing test is
>> quite inferior compared to the new one, so it
>> does not seem to make a lot of sense to keep it.
>
> It was mistake in 8253191 (I
On Tue, 20 Oct 2020 17:43:07 GMT, Aleksey Shipilev wrote:
>> Well, I am replacing the entire file. There is a recent precedent of the
>> similar change
>> [here](https://github.com/openjdk/jdk/commit/6d13c766#diff-0daf75421f8fdb55a5640742ef6f12730fe1b370cc864311c188ad6b51fe).
>> Either that
On Mon, 19 Oct 2020 06:57:24 GMT, Aleksey Shipilev wrote:
>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
>> point in JDK that can use the intrinsic like
>> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the
>> C1/C2 intrinsic now, hook it up
On Tue, 20 Oct 2020 10:24:35 GMT, Aleksey Shipilev wrote:
>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
>> point in JDK that can use the intrinsic like
>> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the
>> C1/C2 intrinsic now, hook it up
On Mon, 19 Oct 2020 06:57:24 GMT, Aleksey Shipilev wrote:
>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry
>> point in JDK that can use the intrinsic like
>> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the
>> C1/C2 intrinsic now, hook it up
On Sat, 10 Oct 2020 08:34:23 GMT, Richard Reingruber wrote:
>> Hi,
>>
>> this is the continuation of the review of the implementation for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>>
>> It allows for JIT optimizations based on
On Thu, 8 Oct 2020 16:55:31 GMT, Richard Reingruber wrote:
>> Hi,
>>
>> this is the continuation of the review of the implementation for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>>
>> It allows for JIT optimizations based on
On Thu, 8 Oct 2020 16:55:31 GMT, Richard Reingruber wrote:
>> Hi,
>>
>> this is the continuation of the review of the implementation for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>>
>> It allows for JIT optimizations based on
0/300 runs, ReservedCodeCacheSize=30m with "-
XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -
XX:+UseJVMCICompiler"
Thanks,
Fairoz
-Original Message-
From: Vladimir Kozlov
Sent: Monday, August 17, 2020 11:22 PM
To: Fairoz Matte ; hotspot-compiler-
d...@openjdk.java.net; serviceability-dev
alVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler"
Thanks,
Fairoz
-Original Message-
From: Vladimir Kozlov
Sent: Monday, August 17, 2020 11:22 PM
To: Fairoz Matte ; hotspot-compiler-
d...@openjdk.java.net; serviceability-dev@openjdk.java.net
Cc: Coleen Phillimore ; Dean Long
Subject:
Hi Fairoz,
How you determine that +10Mb is enough with Graal?
Thanks,
Vladimir
On 8/17/20 5:46 AM, Fairoz Matte wrote:
Hi,
Please review this small test change to work with Graal.
Background:
Graal require more code cache compared to c1/c2. but the test case always set
it to
Fix is good.
I think next are reasons you don't get MDO in this scenario.
Tier1 (C1 compilation) does not generate profiling code and does not created MDO. C1 request MDO only with tiers 2 and 3
[1][2].
With -Xcomp flag a Java method is not executed in Interpreter but requests its
Thank you, David
Vladimir K
On 7/3/20 3:18 PM, David Holmes wrote:
On 4/07/2020 4:30 am, Vladimir Kozlov wrote:
Thank you, David, for looking on changes.
I will remember to update tests. I filed RFE 8248815 [1] for tracking.
Can you approve this fix now?
Yes - thanks.
David
Thanks
l sense.
Thanks,
David
-
-- Igor
On Jul 2, 2020, at 7:25 PM, David Holmes wrote:
Hi Vladimir,
On 3/07/2020 12:02 pm, Vladimir Kozlov wrote:
https://cr.openjdk.java.net/~kvn/8247527/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8247527
Test should have @requires which excludes runnin
Thank you, Igor
Vladimir K
On 7/2/20 7:24 PM, igor.ignat...@oracle.com wrote:
LGTM
— Igor
On Jul 2, 2020, at 7:03 PM, Vladimir Kozlov wrote:
https://cr.openjdk.java.net/~kvn/8247527/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8247527
Test should have @requires which excludes
https://cr.openjdk.java.net/~kvn/8247527/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8247527
Test should have @requires which excludes running Graal with GC which it does
not support.
Testing: hs-tier1,hs-tier4-graal
Thanks,
Vladimir
Vladimir Ivanov is on break currently.
It looks good to me.
Thanks,
Vladimir K
On 5/26/20 7:31 AM, Reingruber, Richard wrote:
Hi Vladimir,
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
Not an expert in JVMTI code base, so can't comment on the actual changes.
On 5/21/20 9:11 PM, David Holmes wrote:
Hi Mikael,
Looks good.
+1
I assume the change to GraalHotSpotVMConfig.java is to allow it to work with
older VMs?
Yes. stackBias will be set to 0 if STACK_BIAS is not present. Otherwise it will
be set to STACK_BIAS value.
Thanks,
Vladimir
I filed Graal issue to change mx script to filter out SPARC code when we do
sync Graal changes into JDK.
For Graal shared code we may need to have versioning for latest JDK as we do in
other cases.
Regards,
Vladimir
On 5/4/20 2:29 PM, Igor Ignatyev wrote:
Hi Mikael,
the changes in /test/
JIT, AOT, JVMCI and Graal changes seem fine to me.
It would be interesting to see shared code execution coverage change. There are places where we use flags and setting
instead of #ifdef SPARC which may not be executed now or executed partially. We may simplify such code too.
Thanks,
ment
when the actual changes will have to operate correctly in a tiered environment (and JVMCI).
Thanks,
David
Thanks, Richard.
-Original Message-
From: Vladimir Kozlov
Sent: Donnerstag, 12. Dezember 2019 19:20
To: David Holmes ; hotspot-runtime-...@openjdk.java.net;
hotspot-compiler-...@ope
analysis may be
affected if C1 compiler is also used.
Richard may clarify this.
thanks,
Vladimir
On 12/11/19 1:04 PM, David Holmes wrote:
On 12/12/2019 5:21 am, Vladimir Kozlov wrote:
I will do full review later. I want to comment about test command line.
You don't need
I am fine with changes but we need to ask PPC64 supporter to verify that tests
passed now.
Thanks,
Vladimir K
On 12/4/19 11:52 AM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8235353/webrev.00
9 lines changed: 0 ins; 0 del; 9 mod;
Hi all,
could you please review this small
It is also not clear to me that it is bug. Based on all description this functionality is used to
catch leaks in Java heap. But scalar replaced objects do not exists. JVMTI should not even see them.
Thanks,
Vladimir
On 9/24/19 3:37 PM, Vladimir Kozlov wrote:
can_tag_objects is "a
can_tag_objects is "always" capability.
If it is true then EA will be disabled in all cases when JVMTI agent is used.
It is too broad.
Am I missing something?
Thanks,
Vladimir
On 9/13/19 7:12 AM, Reingruber, Richard wrote:
Hi,
could I please get reviews for
Webrev:
I read discussion and this change looks good to me.
May be add comment that it is onload capability and can't be changed during
execution.
Thanks,
Vladimir
On 9/6/19 7:24 AM, Reingruber, Richard wrote:
Hi,
could I please get reviews for
Webrev:
Yes, I looked on it and tested when Tom proposed changes.
Vladimir
On 5/30/19 10:58 AM, serguei.spit...@oracle.com wrote:
Hi Vladimir,
May I count you as a (R)eviewer?
Thanks,
Serguei
On 5/30/19 10:05, Vladimir Kozlov wrote:
Thank you, Serguei, for fixing this.
Vladimir K
On 5/29/19 7
1 - 100 of 148 matches
Mail list logo
