On Fri, 26 Jan 2024 09:12:53 GMT, Alan Bateman wrote:
> The target class is transformed in such a way to call the auxiliary class,
> which necessitates the the aux-class to be in the same classloader as the
> target class. But because the aux-class is defined while the target class is
> still
On Sat, 15 Apr 2023 10:15:20 GMT, Kevin Walls wrote:
>> This test is failing often since 8304725 added a call to
>> Thread::current_in_asgct(). This can end up being called e.g. when
>> resolving calls, and then the OS last error value is lost.
>>
>> The test is reliable with a single
On Thu, 6 Apr 2023 08:11:45 GMT, Glavo wrote:
> os.arch is always the target architecture for JVM, even using 32-bit JVM on
> 64-bit system, its value remains x86.
Okay, I could have sworn we had to add the `ADDRESS_SIZE` check because of this
issue where a 32-bit VM running on x64 would
On Wed, 5 Apr 2023 21:18:43 GMT, Glavo wrote:
>> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check
>> without knowing more about the foreign api dependencies. ADDRESS_SIZE is
>> computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`.
>> But I can't think of how it can be
On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64,
On Tue, 21 Feb 2023 08:58:50 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update full name
Testing looks
On Mon, 20 Feb 2023 09:18:46 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Improve condition again
The new
On Fri, 17 Feb 2023 14:13:04 GMT, Johannes Bechberger wrote:
> Could you be so kind to synthesize a comment for me? I'm slightly overwhelmed
> by the discussion.
Something like:
// Note: sp can be greater than unextended_sp in the case of
// interpreted -> interpreted calls that go through a
On Thu, 16 Feb 2023 14:25:15 GMT, Johannes Bechberger wrote:
>> Extends the existing AsyncGetCallTrace test case and fixes the issue by
>> modifying `MethodHandles` code.
>
> Johannes Bechberger has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Wed, 15 Feb 2023 23:20:00 GMT, Richard Reingruber wrote:
> (Maybe too) long version:
Not at all :) I don't know much about the interpreter, so this is pretty
helpful.
Ok. I think the main point is that a MH linker method doesn't have a c2i
adapter, it instead has separate versions for
On Wed, 15 Feb 2023 21:22:48 GMT, Richard Reingruber wrote:
> If an ordinary interpreter entry is used for a call this means the callee
> will be interpreted
Maybe we're not talking about the same thing?
`Method` has a `from_interpreted_entry` and a `from_compiled_entry`, but which
one is
On Wed, 15 Feb 2023 21:05:07 GMT, Richard Reingruber wrote:
> I don't think you can do that. Modifying the unextended_sp would break
> accesses to compiled frames (gc, locals).
This is for interpreter entries, so the caller is definitely interpreted. If
the callee is compiled, it shouldn't
On Wed, 15 Feb 2023 09:01:29 GMT, Johannes Bechberger wrote:
>> Are you referring to the test in
>> test/hotspot/jtreg/serviceability/AsyncGetCallTrace/ ?
>
> Yes.
> I think `unextended_sp < sp` is possible on x86 when interpreter entries
> generated by
On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-434 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Tue, 8 Nov 2022 18:14:21 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-434 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Tue, 8 Nov 2022 16:30:14 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-434 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-434 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Tue, 8 Nov 2022 13:28:58 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-434 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On Mon, 7 Nov 2022 14:59:27 GMT, Maurizio Cimadamore
wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Bring windows CallArranger in sync with panama repo
>
> I have incorporated additional API changes,
On Mon, 7 Nov 2022 09:40:03 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java
>> line 165:
>>
>>> 163: assert forArguments : "no stack returns";
>>> 164: // stack
>>> 165: long
On Fri, 4 Nov 2022 18:23:17 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-434 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
21 matches
Mail list logo
