Hi Thomas,
Thank you very much for the detailed explanation. For your
information, the relevant NetBeans bug is
https://issues.apache.org/jira/browse/NETBEANS-1428
On Sat, Nov 24, 2018 at 3:41 PM Thomas Stüfe wrote:
> A jmethodid is a pointer to malloc'ed memory.
OK. Just in case I haven't unders
Hi Kim,
- taskqueue.hpp has some small adjustments to enable subclassing
Why this change instead of JDK-8204947? As the description from that RFE says:
"The ShenandoahTaskTerminator from the Shenandoah project is a much better
implementation of a task terminator.”
We were busy on pre
How does this solve the problem of
HotSpotJVMCIRuntime.adjustCompilationLevel being called?
I don't think this fix is the right approach. Doesn't
is_interp_only_mode() only apply to the current thread? I don't think
it's safe to assume no compiles will happen in other threads, or that a
met
A few quick comments (not a real review).
> On Nov 26, 2018, at 4:39 PM, Roman Kennke wrote:
>
> Sections to review (at this point) are the following:
>
> *) shared-gc
> - This is mostly boilerplate that is common to any GC
> - referenceProcessor.cpp has a little change to make one ass
Hi Roman,
You need to check if shenandoahgc is disabled first - check
DISABLED_JVM_FEATURES list (see code for jvmci).
Do you support 32-bit x86? You have OPENJDK_TARGET_CPU == xx86 check.
Do you support all x86 OSs?
Why you set VM CFLAGS when shenandoahgc is not enabled? It is in
JvmFeature
+1 more
Thanks,
David
On 27/11/2018 3:57 am, serguei.spit...@oracle.com wrote:
Hi Thomas,
+1
Thanks,
Serguei
On 11/26/18 06:53, Daniel D. Daugherty wrote:
On 11/26/18 8:07 AM, Thomas Stüfe wrote:
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexh
Build changes look ok to me.
/Erik
On 2018-11-26 13:39, Roman Kennke wrote:
Hi,
This is the first round of changes for including Shenandoah GC into
mainline.
I divided the review into parts that roughly correspond to the mailing lists
that would normally review it, and I divided it into 'share
Hi Dean,
On Mon, Nov 26, 2018 at 10:44 PM wrote:
>
> Doesn't the spec say it's the caller's responsibility to keep the class from
> being unloaded?
>
> "
> A field or method ID does not prevent the VM from unloading the class from
> which the ID has been derived. After the class is unloaded, th
Hi JC,
On Mon, Nov 26, 2018 at 10:39 PM JC Beyler wrote:
>
> Hi Thomas,
>
> Not sure I agree either (but this first part of the email might be you and I
> rat-holing and we could/should perhaps just let it go :-)):
> - The specs do not say at all what happens to the internals of the
> jmethod
Doesn't the spec say it's the caller's responsibility to keep the class
from being unloaded?
"
A field or method ID does not prevent the VM from unloading the class
from which the ID has been derived. After the class is unloaded, the
method or field ID becomes invalid. The native code, therefo
Hi Thomas,
Not sure I agree either (but this first part of the email might be you and
I rat-holing and we could/should perhaps just let it go :-)):
- The specs do not say at all what happens to the internals of the
jmethodIDs and not even that de-referencing them is safe. You are right
that the
Hi,
This is the first round of changes for including Shenandoah GC into
mainline.
I divided the review into parts that roughly correspond to the mailing lists
that would normally review it, and I divided it into 'shared' code
changes and
'shenandoah' code changes (actually, mostly additions). The
Please all, don't cc the discuss list once a topic has been directed to
the correct mailing list!
Thanks,
David
On 27/11/2018 5:33 am, Thomas Stüfe wrote:
Hey JC,
On Mon, Nov 26, 2018 at 8:15 PM JC Beyler wrote:
Hi all,
Just added my two cents on one comment:
On Mon, Nov 26, 2018 at 5:00
Hi Jini,
The tool changes look fine for disabling zgc support, but with the test
changes you are no longer testing what happens if you use jmap with zgc.
What would the tests do if you made no test changes? If they still fail
ungracefully, could they be fixed by catching the RuntimeException y
Hey JC,
On Mon, Nov 26, 2018 at 8:15 PM JC Beyler wrote:
>
> Hi all,
>
> Just added my two cents on one comment:
>
> On Mon, Nov 26, 2018 at 5:00 AM Thomas Stüfe wrote:
>>
>> Hi Peter,
>>
>> On Mon, Nov 26, 2018 at 1:02 PM Peter Hull wrote:
>> >
>> > Hi Thomas,
>> > Thank you very much for the
Hi all,
Please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8195639
webrev:
http://cr.openjdk.java.net/~amenkov/popframe009/webrev.01/
Description:
The test suspends a thread, turns on single stepping and then calls
PopFrame. SingleStep event is expected as soon as the thread is
Hi Thomas,
+1
Thanks,
Serguei
On 11/26/18 06:53, Daniel D. Daugherty wrote:
On 11/26/18 8:07 AM, Thomas Stüfe wrote:
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
src/hotspot/sh
Thanks Dan!
On Mon, Nov 26, 2018 at 3:54 PM Daniel D. Daugherty
wrote:
>
> On 11/26/18 8:07 AM, Thomas Stüfe wrote:
> > Hi guys,
> >
> > latest webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
>
> src/
On 11/26/18 8:07 AM, Thomas Stüfe wrote:
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
src/hotspot/share/prims/jvmtiExport.cpp
No comments.
Thumbs up.
Dan
Back to can_call_j
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
Back to can_call_java(), since this seems to be the consensus, with a
comment added.
As for the Thread::can_send_jvmti_events() property i
Hi Peter,
On Mon, Nov 26, 2018 at 1:02 PM Peter Hull wrote:
>
> Hi Thomas,
> Thank you very much for the detailed explanation. For your
> information, the relevant NetBeans bug is
> https://issues.apache.org/jira/browse/NETBEANS-1428
>
> On Sat, Nov 24, 2018 at 3:41 PM Thomas Stüfe wrote:
> > A
Okay, I created an RFE for this:
https://bugs.openjdk.java.net/browse/JDK-8214294
And for now I will prepare a new minimal patch based on our
discussions and post it shortly.
..Thomas
On Mon, Nov 26, 2018 at 12:28 PM David Holmes wrote:
>
> On 26/11/2018 6:58 pm, Thomas Stüfe wrote:
> > Hi all
On 26/11/2018 6:58 pm, Thomas Stüfe wrote:
Hi all,
just a general question, would a
virtual bool Thread::can_post_JVMTI_events();
(similar to can_call_java()) not be a clearer solution? It clearly
expresses what we want, and we can, in every Thread child class,
explicitly specify the behavior.
Hi Thomas,
I like this idea.
It will help to control it better and avoid confusions next time.
Thanks,
Serguei
On 11/26/18 00:58, Thomas Stüfe wrote:
Hi all,
just a general question, would a
virtual bool Thread::can_post_JVMTI_events();
(similar to can_call_java()) not be a clearer solutio
Hi all,
just a general question, would a
virtual bool Thread::can_post_JVMTI_events();
(similar to can_call_java()) not be a clearer solution? It clearly
expresses what we want, and we can, in every Thread child class,
explicitly specify the behavior.
..Thomas
On Mon, Nov 26, 2018 at 9:51 A
On Mon, Nov 26, 2018 at 4:58 AM serguei.spit...@oracle.com
wrote:
>
> Hi guys,
>
> On 11/25/18 06:17, Daniel D. Daugherty wrote:
> > On 11/25/18 6:57 AM, David Holmes wrote:
> >>
> >>
> >> On 25/11/2018 12:41 am, Daniel D. Daugherty wrote:
> >>> On 11/22/18 5:24 PM, David Holmes wrote:
> Hi T
26 matches
Mail list logo
