Thanks Serguei!
Yasumasa
On 2020/09/05 9:36, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
I'm okay with the fix.
Thanks,
Serguei
On 9/4/20 03:52, Yasumasa Suenaga wrote:
Hi Serguei,
Thank you for the explanation.
I agree with you it is hard to prove that it is safe to get rid of these
Hi Yasumasa,
I'm okay with the fix.
Thanks,
Serguei
On 9/4/20 03:52, Yasumasa Suenaga wrote:
Hi Serguei,
Thank you for the explanation.
I agree with you it is hard to prove that it is safe to get rid of
these handshake closures.
So are you ok with webrev.04 (latest webrev) for this enhanc
Hi Dan,
Thanks for your comment!
On 2020/09/05 5:27, Daniel D. Daugherty wrote:
On 8/31/20 5:10 AM, Yasumasa Suenaga wrote:
Hi David,
I uploaded new webrev. Could you review again?
http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/webrev.04/
src/hotspot/share/prims/jvmtiEnvBase.hpp
N
On 8/31/20 5:10 AM, Yasumasa Suenaga wrote:
Hi David,
I uploaded new webrev. Could you review again?
http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/webrev.04/
src/hotspot/share/prims/jvmtiEnvBase.hpp
No comments.
src/hotspot/share/prims/jvmtiEnv.cpp
L1636: JvmtiEnv::PopFrame(Java
+1 for webrev.02
Yes, this does remove the test from tier1 testing, but I think that is
fine for any resourcehogs test. Have you run this through the submit
repo? If so I can use your job to make sure it passes on all our platforms.
thanks,
Chris
On 9/4/20 11:17 AM, Leonid Mesnik wrote:
Hi
Hi
Thanks for fixing this. I prefer webrev.02. It doesn't needed to skip
OOME if we provide enough memory. Also, it complies with other
resourcehogs test. Please get 'R'eview and response from Chris.
Leonid
On 9/4/20 1:16 AM, Christoph Göttschkes wrote:
Hi,
thanks for your feedback.
So for
* Volker Simonis:
> Not sure this is related to overcommit settings. According to the
> man-page, fork() only fails with "ENOMEM" if fork() "failed to
> allocate the necessary kernel structures because memory is tight". But
> a failing fork is actually no problem at all. Currently, if fork()
> fai
* Volker Simonis:
>> The other issue is that formally, there are significant restrictions on
>> what kind of functionality is available after a fork call from a
>> multi-threaded process. Only async-signal-safe functions are supported,
>> and POSIX does not include malloc among them. glibc suppo
On Fri, Sep 4, 2020 at 2:20 PM Florian Weimer wrote:
>
> * Volker Simonis:
>
> > Please let me know what you think and if there's something I've
> > overlooked?
>
> ZGC uses shared mappings for the heap, which will remain shared after
> fork, so this trick does not work there.
>
That's a good poi
On Fri, Sep 4, 2020 at 12:01 PM Thomas Stüfe wrote:
>
>
>
> On Fri, Sep 4, 2020 at 11:23 AM Volker Simonis
> wrote:
>>
>> On Thu, Sep 3, 2020 at 8:26 PM Thomas Stüfe wrote:
>> >
>> > Hi Volker,
>> >
>> > On Thu, Sep 3, 2020 at 7:41 PM Volker Simonis
>> > wrote:
>> >>
>> >> Hi Thomas,
>> >>
>>
* Volker Simonis:
> Please let me know what you think and if there's something I've
> overlooked?
ZGC uses shared mappings for the heap, which will remain shared after
fork, so this trick does not work there.
The other issue is that formally, there are significant restrictions on
what kind of fu
Hi Serguei,
Thank you for the explanation.
I agree with you it is hard to prove that it is safe to get rid of these
handshake closures.
So are you ok with webrev.04 (latest webrev) for this enhancement?
I know you give +1 to this change, but I want to confirm in light of the
discussion again s
Hi Yasumasa,
On 9/4/20 02:49, Yasumasa Suenaga wrote:
Hi Serguei,
For example, JvmtiThreadState_lock would be grabbed at
ciEnv::cache_jvmti_state() which is called by
CompileBroker::invoke_compiler_on_method(). Compiler thread might be
touch the protected resource even if target thread is s
On Fri, Sep 4, 2020 at 11:23 AM Volker Simonis
wrote:
> On Thu, Sep 3, 2020 at 8:26 PM Thomas Stüfe
> wrote:
> >
> > Hi Volker,
> >
> > On Thu, Sep 3, 2020 at 7:41 PM Volker Simonis
> wrote:
> >>
> >> Hi Thomas,
> >>
> >> Thanks for sharing your concerns. Please find my anserwers inline:
> >>
>
Hi Serguei,
For example, JvmtiThreadState_lock would be grabbed at
ciEnv::cache_jvmti_state() which is called by
CompileBroker::invoke_compiler_on_method(). Compiler thread might be touch the
protected resource even if target thread is suspended with direct handshake.
So I think they are need
On Thu, Sep 3, 2020 at 8:26 PM Thomas Stüfe wrote:
>
> Hi Volker,
>
> On Thu, Sep 3, 2020 at 7:41 PM Volker Simonis
> wrote:
>>
>> Hi Thomas,
>>
>> Thanks for sharing your concerns. Please find my anserwers inline:
>>
>> On Thu, Sep 3, 2020 at 6:58 PM Thomas Stüfe wrote:
>> >
>> > Hi Volker,
>>
Hi Yasumasa,
Only PopFrame, ForceEarlyReturn, NotifyFramePop and ResumeThread require
the target thread to be suspended.
Other JVMTI functions do not require it.
I'm still thinking if it is a good idea to get rid of the
UpdateForPopTopFrameClosure and SetFramePopClosure hadnshakes.
It has to
Hi Serguei,
Thanks for your review!
On 2020/09/04 15:43, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
Thanks for the answer and sorry for the latency. It is not easy to double check
everything related to the JvmtiThreadState_lock use.
You are right, it is not safe to remove the MutexLockers
Hi,
thanks for your feedback.
So for me, all options work. The @requries tag makes the test to be not
selected. My solution also works (for me) since we don't run tests
concurrently on our smaller devices, since most devices have issues with
that. Probably because there are more tests which ca
19 matches
Mail list logo
