On Wed, 15 Feb 2023 20:53:23 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/prims/jvmtiEnv.cpp line 1045:
>>
>>> 1043: JvmtiEnvBase::is_vthread_alive(vt_oop) &&
>>> 1044: !JvmtiVTSuspender::is_vthread_suspended(vt_oop)) ||
>>> 1045: java_thread->is_b
On Tue, 14 Feb 2023 13:40:40 GMT, Thomas Stuefe wrote:
> VM.classloader_stats shows metaspace consumption in words, but should show
> bytes.
>
> Patch fixes that, and adjusts the associated jtreg test to catch regressions
> like this.
>
> I manually tested the test with the unpatched hotspot
On Wed, 15 Feb 2023 10:50:11 GMT, Thomas Stuefe wrote:
>> VM.classloader_stats shows metaspace consumption in words, but should show
>> bytes.
>>
>> Patch fixes that, and adjusts the associated jtreg test to catch regressions
>> like this.
>>
>> I manually tested the test with the unpatched
On Wed, 15 Feb 2023 10:50:11 GMT, Thomas Stuefe wrote:
>> VM.classloader_stats shows metaspace consumption in words, but should show
>> bytes.
>>
>> Patch fixes that, and adjusts the associated jtreg test to catch regressions
>> like this.
>>
>> I manually tested the test with the unpatched
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 inte
On Wed, 15 Feb 2023 21:39:52 GMT, Jorn Vernee wrote:
> The entry generated by generate_method_handle_interpreter_entry is
> essentially the from_interpreted_entry, AFAIU.
But it is also stored in `Method::_i2i_entry` which is [used by c2i
adapters](https://github.com/openjdk/jdk/blob/3ba156082
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 use
On Wed, 15 Feb 2023 21:12:19 GMT, Jorn Vernee wrote:
>>> I think your conclusion is correct wrt `unextended_sp < sp` in that case.
>>> For certain MH linker calls, an additional `MemberName` 'appendix' is
>>> passed as the last argument. The MH adapter/trampoline stub pops the
>>> appendix arg
> 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 Li
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 car
On Wed, 15 Feb 2023 20:38:04 GMT, Johannes Bechberger wrote:
>>> I think `unextended_sp < sp` is possible on x86 when interpreter entries
>>> generated by `MethodHandles::generate_method_handle_interpreter_entry()`
>>> are executed. They modify `sp` ([here for
>>> example](https://github.com/o
On Wed, 15 Feb 2023 05:04:21 GMT, Serguei Spitsyn wrote:
> Patricio, The fix looks pretty solid to me. I've already posted one comment
> and will post a couple of formatting nits. I agree with Alan, it'd be nice to
> get rid of `is_bound_vthread` if possible. I will make one more pass after
>
> Please review the following change. Some of the JVMTI functions had to be
> modified since they are not supported by the specs on virtual threads
> (StopThread, RunAgentThread, GetCurrentThreadCpuTime, GetThreadCpuTime) or
> shouldn't include virtual threads in the results (GetAllThreads,
> G
On Wed, 15 Feb 2023 20:24:16 GMT, Jorn Vernee wrote:
>> Yes.
>
>> I think `unextended_sp < sp` is possible on x86 when interpreter entries
>> generated by `MethodHandles::generate_method_handle_interpreter_entry()` are
>> executed. They modify `sp` ([here for
>> example](https://github.com/ope
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 `MethodHandles::generate_method_handle_i
On Thu, 2 Feb 2023 13:42:51 GMT, Alexey Bakhtin wrote:
>> Please find a patch to improve JMX Repository.query performance
>>
>> Using ObjectName.apply() allows significantly decrease memory usage and the
>> number of GC cycles:
>> Before:
>>
>> $ java test 100 100
>> Test PASSED in 894
> VM.classloader_stats shows metaspace consumption in words, but should show
> bytes.
>
> Patch fixes that, and adjusts the associated jtreg test to catch regressions
> like this.
>
> I manually tested the test with the unpatched hotspot to see if the
> regression shows up, it does.
>
> Test
> VM.classloader_stats shows metaspace consumption in words, but should show
> bytes.
>
> Patch fixes that, and adjusts the associated jtreg test to catch regressions
> like this.
>
> I manually tested the test with the unpatched hotspot to see if the
> regression shows up, it does.
>
> Test
On Wed, 15 Feb 2023 07:49:24 GMT, David Holmes wrote:
> Given the reason this bug likely arose is the fact the parameters to
> `calculate_jfr_stats` say they are "bytes" then fixing that is not a mere
> cleanup IMO. Can we at least fix that in this PR?
Hi David, I reformed the ill-named functi
On Wed, 15 Feb 2023 09:00:23 GMT, David Holmes wrote:
>>> What is the test case?
>>
>> The sanity test I amended with more checks.
>>
>>> Is it sending signals and then using AGCT?
>>
>> No. Just calling ASGCT directly in a native method which is called directly
>> in the main method of a JTR
On Wed, 15 Feb 2023 07:50:56 GMT, Johannes Bechberger wrote:
>> What is the test case? Is it sending signals and then using AGCT? If so then
>> maybe a signal hits when a call is made but before the code has a chance to
>> update unextended_sp?
>
>> What is the test case?
>
> The sanity test I
21 matches
Mail list logo