On Sun, 9 Feb 2025 19:36:28 GMT, Vladimir Kozlov wrote:
> @dougxc and @tkrodriguez, please look if it affects Graal.
I'm pretty sure JVMCI does not care about the virtual-ness of these C++
classes. Running tier9 in mach5 is a good way to be sure.
-
PR Comment: https://git.openjdk.
On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Wed, 17 Jan 2024 19:52:32 GMT, Tom Rodriguez wrote:
>> The changes for JDK-8287061 didn't update the SA decoding logic and there
>> are other places where the decoding has gotten out of sync with HotSpot.
>> Some of them can't be tested because they are part of JVMCI but I've added a
>> di
On Sun, 28 Apr 2024 23:37:22 GMT, Vladimir Kozlov wrote:
>> Move immutable nmethod's data from CodeCache to C heap. It includes
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
>> speculations`. It amounts for about 30% (optimized VM) of space in CodeCache.
>>
>> Use Ho
On Sun, 28 Apr 2024 07:02:40 GMT, Dean Long wrote:
>> Move immutable nmethod's data from CodeCache to C heap. It includes
>> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
>> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
>> in CodeCache.
>>
On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov wrote:
> Move immutable nmethod's data from CodeCache to C heap. It includes
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
> in CodeCache.
>
On Fri, 26 Apr 2024 21:16:03 GMT, Vladimir Kozlov wrote:
> Move immutable nmethod's data from CodeCache to C heap. It includes
> `dependencies, nul_chk_table, handler_table, scopes_pcs, scopes_data,
> speculations, jvmci_data`. It amounts for about 30% (optimized VM) of space
> in CodeCache.
>
On Wed, 17 Apr 2024 22:58:21 GMT, Dean Long wrote:
> @dougxc should check JVMCI changes.
Thanks for the heads up. I've asked @matias9927 to double check these changes
against libgraal which should address any concerns about how this change
impacts Graal.
-
PR Comment: https://git
On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon wrote:
> This PR increases a timeout in `MissingClassTest.java` to handle slight
> slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the
> timeouts.
This
On Thu, 14 Mar 2024 10:46:10 GMT, Doug Simon wrote:
> This PR increases a timeout in `MissingClassTest.java` to handle slight
> slower compilation on a fastdebug build when using `-Xcomp`.
> Testing on mach5 shows that the increase from 60 s to 90 s resolves the
> timeouts.
Th
This PR increases a timeout in `MissingClassTest.java` to handle slight slower
compilation on a fastdebug build when using `-Xcomp`.
Testing on mach5 shows that the increase from 60 s to 90 s resolves the
timeouts.
-
Commit messages:
- increase timeout in loop waiting for listeners
On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon wrote:
> To account for slightly slower compile times on libgraal + fastdebug +
> `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java`
> from 2000 ms to 3000 ms.
> With this change, the test now reliably passes
On Fri, 1 Mar 2024 17:24:02 GMT, Doug Simon wrote:
> To account for slightly slower compile times on libgraal + fastdebug +
> `-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java`
> from 2000 ms to 3000 ms.
> With this change, the test now reliably passes.
Th
To account for slightly slower compile times on libgraal + fastdebug +
`-Xcomp`, this PR increases a timeout in `NotifReconnectDeadlockTest.java` from
2000 ms to 3000 ms.
With this change, the test now reliably passes.
-
Commit messages:
- adjust timeout in NotifReconnectDeadlockTe
On Fri, 2 Feb 2024 10:48:26 GMT, Kevin Walls wrote:
> Or maybe they are not done the initial -Xcomp compile and
> waitUntilThreadBlocked() is mistakenly thinking they are now idle...
Yes, I believe this is the case.
It's not really clear to me what the test is testing. As far as I can see, if
On Thu, 1 Feb 2024 18:25:33 GMT, Doug Simon wrote:
> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently
> fail when run with `-Xcomp`. This happens when the compilation of methods on
> the worker threads interleaves with the 2 calls on the main
On Fri, 2 Feb 2024 07:38:24 GMT, Doug Simon wrote:
>> The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can
>> transiently fail when run with `-Xcomp`. This happens when the compilation
>> of methods on the worker threads interleaves with the 2 calls on the
at the "wrong" time or take sufficiently long, the
> expected delta of 100 nanoseconds is easily exceeded.
>
> It does not make sense to run a timing test with such a small expected delta
> with `-Xcomp` so this PR simply ignores the test when `-Xcomp` is present.
Doug Simon ha
The `com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java` can transiently
fail when run with `-Xcomp`. This happens when the compilation of methods on
the worker threads interleaves with the 2 calls on the main thread to
`mbean.getThreadCpuTime` to get the CPU time for all worker threads.
T
On Sun, 25 Jun 2023 06:58:14 GMT, Doug Simon wrote:
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSu
On Fri, 30 Jun 2023 15:15:16 GMT, Doug Simon wrote:
>> The VMSupport class is required for translating an exception between the
>> HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception
>> being translated.
>&g
On Fri, 30 Jun 2023 17:30:33 GMT, Vladimir Kozlov wrote:
> > > But, please, activate GHA testing for this branch.
> >
> >
> > Isn't GHA a strict subset of or equal to tier1 mach5 testing? If so, what's
> > the point of doing redundant testing?
>
> It builds and tests configurations (32-bit) w
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Thu, 29 Jun 2023 20:06:19 GMT, Doug Simon wrote:
>> The VMSupport class is required for translating an exception between the
>> HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception
>> being translated.
>&g
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Thu, 29 Jun 2023 02:13:32 GMT, David Holmes wrote:
> Someone from the compiler team should review this now.
@vnkozlov could you please review this or nominate someone else from the
compiler team to look at it. Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/14641#issueco
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Wed, 28 Jun 2023 18:28:37 GMT, Tom Rodriguez wrote:
> Why can't the pending exception handling be in the respective virtual?
Done: 9236128ad1b7297c8c4e9d3022b88c3ab3278022
-
PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1612113760
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Tue, 27 Jun 2023 23:06:49 GMT, Tom Rodriguez wrote:
> I don't think pushing it down that far improves things. encode always
> precedes decode so why not resolve it before the encode call.
Because the `VMSupport` klass is only needed if calling into HotSpot so it's
better to push it down int
On Tue, 27 Jun 2023 23:08:22 GMT, Tom Rodriguez wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> revert to lazy loading of VMSupport
>
> src/hotspot/share/jvmci/jvmciEnv.cpp line
On Mon, 26 Jun 2023 13:17:25 GMT, Doug Simon wrote:
>> The VMSupport class is required for translating an exception between the
>> HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception
>> being translated.
>&g
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Mon, 26 Jun 2023 21:56:21 GMT, David Holmes wrote:
> I would think it is likely to fail with OOME under the same GC stress test
> conditions.
>
> But if this is just a stress test issue then bailing out when the loading
> fails would be far simpler than pre-loading the class. You've added t
On Mon, 26 Jun 2023 21:41:25 GMT, David Holmes wrote:
> Then why did you not simply handle the exception from the loading of
> VMSupport the same way?
The only actual case seen of the original way failing is due to OOME in GC
stress tests. If loading of VMSupport is done during VM startup, the
On Mon, 26 Jun 2023 13:17:25 GMT, Doug Simon wrote:
>> The VMSupport class is required for translating an exception between the
>> HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception
>> being translated.
>&g
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Mon, 26 Jun 2023 07:59:17 GMT, David Holmes wrote:
> if the first decode encounters a class initialization error then it will just
> return with the exception pending and no decoding will actually have occurred
That's fine - if VMSupport fails class initialization, then no "rich" decoding
c
> The VMSupport class is required for translating an exception between the
> HotSpot and libgraal heaps.
> Loading it lazily can result in a loading exception, obscuring the exception
> being translated.
> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
On Mon, 26 Jun 2023 07:42:48 GMT, David Holmes wrote:
> The eager loading seems reasonable, but I do not understand the details here.
> In what way was loading failing? You still have to initialize `VMSupport`
> before you can call methods on it, so that could also fail - though the code
> doe
The VMSupport class is required for translating an exception between the
HotSpot and libgraal heaps.
Loading it lazily can result in a loading exception, obscuring the exception
being translated.
To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
-
Commit mes
On Fri, 9 Jun 2023 12:14:46 GMT, Doug Simon wrote:
> > Is JVMCI used by the Graal compiler only?
>
> So far this is true and will probably remain true for the foreseeable future.
> However, the Right Thing to do long t
On Fri, 9 Jun 2023 05:26:59 GMT, Serguei Spitsyn wrote:
> Is JVMCI used by the Graal compiler only?
So far this is true and will probably remain true for the foreseeable future.
However, the Right Thing to do long term is to add a
`jdk.test.whitebox.code.Compiler.uncommonTrapsHavePreciseBCIs()
On Thu, 8 Jun 2023 18:29:50 GMT, Yudi Zheng wrote:
>> test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java
>> line 257:
>>
>>> 255:
>>> 256: checkLines = !(enableJVMCI.getValue().equals("true")
>>> 257: && useJVMCICompiler.getValue().equals("true"));
>
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote:
> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
> not enforce checking line number derived from uncommon trap debug info.
> However, Graal does not set this property explicitly.
Marked as reviewed by dnsimon (Com
On Tue, 2 May 2023 02:01:44 GMT, Serguei Spitsyn wrote:
>> This refactoring to separate ThreadStart/ThreadEnd events posting code in
>> the JVMTI VTMS transitions is needed for future work on JVMTI scalability
>> and performance improvements. It is to easier put this code on slow path.
>>
>> T
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote:
> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
> not enforce checking line number derived from uncommon trap debug info.
> However, Graal does not set this property explicitly.
test/hotspot/jtreg/serviceability/
On Tue, 30 May 2023 19:15:38 GMT, Johan Sjölen wrote:
>> A final sweep of Hotspot to remove all re-added NULLs. With only 110 changes
>> I'd appreciate if this was considered trivial.
>
> Johan Sjölen has updated the pull request incrementally with two additional
> commits since the last revisi
On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote:
>> This change moves the flags from AccessFlags to either ConstMethodFlags or
>> MethodFlags, depending on whether they are set at class file parse time,
>> which makes them essentially const, or at runtime, which makes them needing
>>
On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Wed, 15 Mar 2023 15:41:17 GMT, Frederic Parain wrote:
>> Please review this change re-implementing the FieldInfo data structure.
>>
>> The FieldInfo array is an old data structure storing fields metadata. It has
>> poor extension capabilities, a complex management code because of lack of
>>
On Tue, 14 Mar 2023 13:37:23 GMT, Frederic Parain wrote:
>> src/hotspot/share/jvmci/jvmciEnv.hpp line 149:
>>
>>> 147: };
>>> 148:
>>> 149: extern JNIEXPORT jobjectArray c2v_getDeclaredFieldsInfo(JNIEnv* env,
>>> jobject, jobject, jlong);
>>
>> What's the purpose of this declaration? I don't
On Tue, 14 Mar 2023 13:12:31 GMT, Frederic Parain wrote:
>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaField.java
>> line 48:
>>
>>> 46: * Returns VM internal flags associated with this field
>>> 47: */
>>> 48: int getInternalModifiers();
>>
>> We've never ex
On Thu, 9 Mar 2023 21:18:19 GMT, Matias Saavedra Silva
wrote:
>> The current structure used to store the resolution information for
>> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its
>> ambigious fields f1 and f2. This structure can hold information for fields,
>>
On Mon, 13 Mar 2023 18:51:17 GMT, Frederic Parain wrote:
>> Please review this change re-implementing the FieldInfo data structure.
>>
>> The FieldInfo array is an old data structure storing fields metadata. It has
>> poor extension capabilities, a complex management code because of lack of
>>
On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes wrote:
>> This is a simple cleanup RFE to get rid of old-style C casts in relation to
>> JavaThread.
>>
>> In many cases involving NULL/nullptr the cast could just be dropped.
>> Sometimes a static cast is needed to disambiguate overloads.
>>
>>
On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes wrote:
>> This is a simple cleanup RFE to get rid of old-style C casts in relation to
>> JavaThread.
>>
>> In many cases involving NULL/nullptr the cast could just be dropped.
>> Sometimes a static cast is needed to disambiguate overloads.
>>
>>
57 matches
Mail list logo
