Looks good!
/R
On Aug 29, 2013, at 10:26 AM, Staffan Larsen wrote:
Can I have a second review for the Hotspot part of this change?
Thanks,
/Staffan
On 27 aug 2013, at 10:48, Staffan Larsen staffan.lar...@oracle.com wrote:
I have also made a fix for hotspot. I messed up the link in
Staffan,
the change looks good. (Not a Reviewer).
One thing to point out though, if we would leak ports the following line would
get stuck in an infinite loop
(pthread_mach_thread_np calls _pthread_lookup_thread which calls
_pthread_find_thread which will spin forever if the ports part of the
/~rbackman/8020701.1/
Thanks
/R
On Jul 17, 2013, at 8:12 PM, Rickard Bäckman wrote:
On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote:
On 7/17/13 5:58 AM, Rickard Bäckman wrote:
Hi all,
can I please have reviews for the following change?
We are adding a mechanism for avoiding some
and we don't have a thread yet.
Please change loaded - first loaded
src/share/vm/runtime/os.hpp
No comments.
src/share/vm/runtime/thread.cpp
No comments.
src/share/vm/runtime/thread.hpp
No comments.
Dan
On 7/18/13 4:37 AM, Rickard Bäckman wrote:
Hi,
here
Looks good to me.
/R
On Jul 17, 2013, at 12:25 PM, Markus Grönlund wrote:
Hi again,
Trying again, could I please have a couple of reviews for this?
Many thanks
Markus
From: Markus Grönlund
Sent: den 16 juli 2013 17:48
To: serviceability-dev@openjdk.java.net;
Hi all,
can I please have reviews for the following change?
We are adding a mechanism for avoiding some crashes in the WatcherThread using
different OS-specific methods.
Webrev: http://cr.openjdk.java.net/~rbackman/8020701/webrev/
Thanks
/R
Sorry everyone, wrong bugnr in the topic.
It should be 8020701.
/R
On Jul 17, 2013, at 1:58 PM, Rickard Bäckman wrote:
Hi all,
can I please have reviews for the following change?
We are adding a mechanism for avoiding some crashes in the WatcherThread
using different OS-specific
Thank you David.
/R
On Jul 17, 2013, at 2:56 PM, David Simms wrote:
Looks good to me.
On 17/07/2013 1:58 p.m., Rickard Bäckman wrote:
Hi all,
can I please have reviews for the following change?
We are adding a mechanism for avoiding some crashes in the WatcherThread
using
Thank you for the review Karen!
/R
On Jul 17, 2013, at 5:00 PM, Karen Kinnear wrote:
Code looks good. Thank you for the assertions and comments.
Cleanly done, as usual for your changes Rickard.
thanks,
Karen
On Jul 17, 2013, at 8:22 AM, Rickard Bäckman wrote:
Sorry everyone, wrong
On Jul 17, 2013, at 7:03 PM, Daniel D. Daugherty wrote:
On 7/17/13 5:58 AM, Rickard Bäckman wrote:
Hi all,
can I please have reviews for the following change?
We are adding a mechanism for avoiding some crashes in the WatcherThread
using different OS-specific methods.
Webrev: http
Thank you!
/R
On Jul 16, 2013, at 8:24 AM, John Rose wrote:
Good. — John
On Jul 15, 2013, at 10:11 PM, Rickard Bäckman rickard.back...@oracle.com
wrote:
thanks for the suggestion. It makes sense.
Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/
stack_base() method which has the assert.
Thanks,
Vladimir
On 7/15/13 10:11 PM, Rickard Bäckman wrote:
Vladimir John,
thanks for the suggestion. It makes sense.
Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/
Thanks
/R
On Jul 16, 2013, at 4:26 AM, John Rose wrote
. function entry_frame_is_first(_)
belongs somewhere else. Since it doesn't really use frame::this, it is
confusing as an overload beside a function that does use frame::this.
Suggest placing it in JavaCallWrapper not frame.
— John
On Jul 10, 2013, at 4:59 AM, Rickard Bäckman
Vladimir John,
thanks for the suggestion. It makes sense.
Updated webrev: http://cr.openjdk.java.net/~rbackman/8016131.u2/
Thanks
/R
On Jul 16, 2013, at 4:26 AM, John Rose wrote:
On Jul 15, 2013, at 9:59 AM, Vladimir Kozlov vladimir.koz...@oracle.com
wrote:
There are several methods
Still looking for a Reviewer.
Thanks
/R
On Jul 8, 2013, at 5:49 PM, Rickard Bäckman wrote:
Thanks Markus!
/R
On Jul 8, 2013, at 5:45 PM, Markus Grönlund wrote:
Rickard,
I think it looks good (not a Reviewer).
Cheers
Markus
-Original Message-
From: Rickard Bäckman
Trying again, can I please get reviews on this change?
Thanks
/R
On Jul 4, 2013, at 11:30 AM, Rickard Bäckman wrote:
Hi,
can I please have a couple of reviews for this change?
The problem in this crash was that we were given an incorrect fp (in this
case 0x0) and had a pc that matched
Thanks Markus!
/R
On Jul 8, 2013, at 5:45 PM, Markus Grönlund wrote:
Rickard,
I think it looks good (not a Reviewer).
Cheers
Markus
-Original Message-
From: Rickard Bäckman
Sent: den 4 juli 2013 11:30
To: serviceability-dev@openjdk.java.net serviceability-dev
Hi,
can I please have a couple of reviews for this change?
The problem in this crash was that we were given an incorrect fp (in this case
0x0) and had a pc that matched the C - Java entry frame. The code then
dereferenced fp +- offset.
This change verifies that the fp +- offset is actually on
Hi,
can I please have a couple of reviews for this small change.
Basically we managed to get a merge error in the code and have two identical
checks after each other.
I also got a heads up saying that we missed to update the copyright year in
referenceProcessorStats.hpp so I fixed that in
Hi all,
can I please have this change reviewed?
My interpretation is that this isn't really a bug, since the parameter sig_type
is never set to [.
The suggested change is to remove the check for [ in the if and add an assert.
I also created a boolean
to track handle creation to simplify
,
Serguei
On 5/15/13 2:37 AM, Rickard Bäckman wrote:
Hi all,
can I please have this change reviewed?
My interpretation is that this isn't really a bug, since the parameter
sig_type is never set to [.
The suggested change is to remove the check for [ in the if and add an
assert. I also
-
From: Rickard Bäckman [mailto:rickard.back...@oracle.com]
Sent: Thursday, May 09, 2013 4:53 PM
To: 云达(Yunda)
Cc: David Holmes; serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: Re: [PATCH] EnableTracing: output from multiple threads may be mixed
together
;
+ writeEventContent();
+} else {
+ writeEventContent();
+}
+ }
+
+ void writeEventContent() {
TraceStream ts(*tty);
ts.print(xsl:value-of select=@label/: [);
xsl:apply-templates select=value|structvalue mode=write-data/
Regards,
Yunda
-Original Message-
From: Rickard
One option could be to move the content of writeEvent() to its own method
(maybe writeEventContent()) and just do
if (UseLockedTracing) {
ttyLocker lock;
writeEventContent();
} else {
writeEventContent();
}
I think it makes it easier to read.
/R
On May 8, 2013, at 2:41 AM, David Holmes
Hi,
please review this small change.
The change adds a check to see the result of a malloc() and aborts the VM with
an out of memory error.
Webrev: http://cr.openjdk.java.net/~rbackman/8008255/
Bug: http://bugs.sun.com/view_bug.do?bug_id=8008255
Thanks
/R
Thank you, Staffan
/R
On May 8, 2013, at 2:17 PM, Staffan Larsen wrote:
Looks good.
/Staffan
On 8 maj 2013, at 13:08, Rickard Bäckman rickard.back...@oracle.com wrote:
Hi,
please review this small change.
The change adds a check to see the result of a malloc() and aborts the VM
create a unit test that triggers the failure ?
Thx Ron
-Original Message-
From: Staffan Larsen
Sent: Wednesday, May 08, 2013 6:17 AM
To: Rickard Bäckman
Cc: serviceability-dev@openjdk.java.net serviceability-dev@openjdk.java.net;
hotspot-runtime-
d...@openjdk.java.net
Subject: Re
Thank you David
/R
On May 8, 2013, at 2:44 PM, David Holmes wrote:
Looks fine to me. As we discussed in the bug report there's no reasonable way
to report the error so an abort is the only way out.
David
On 8/05/2013 9:08 PM, Rickard Bäckman wrote:
Hi,
please review this small
Staffan,
this looks good to me (not a Reviewer).
/R
On May 7, 2013, at 10:02 AM, Staffan Larsen wrote:
Please review this little fix to remove the _g support from the SA files.
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005038
webrev:
Yunda,
the change looks good (not a Reviewer).
/R
On May 2, 2013, at 5:07 AM, 云达(Yunda) wrote:
Could anyone review this for me, please?
Regards,
Yunda
From: 云达(Yunda)
Sent: Friday, April 19, 2013 4:26 PM
To: hotspot-runtime-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Staffan,
much better!
Ship it.
/R
On Apr 29, 2013, at 4:09 PM, Staffan Larsen wrote:
You are right. I was just being lazy.
Update webrev: http://cr.openjdk.java.net/~sla/8003671/webrev.01/
Thanks,
/Staffan
On 29 apr 2013, at 15:43, Rickard Bäckman rickard.back...@oracle.com wrote
Staffan,
this change looks good. (Not a Reviewer).
/R
On Apr 29, 2013, at 4:40 PM, Staffan Larsen wrote:
Hi,
This is an improvement to the error message the user receives when SA attach
fails on OS X. The current message is:
attach: task_for_pid(13581) failed (5)
Error attaching to
Looks good (Not a Reviewer).
/R
On Apr 29, 2013, at 4:34 PM, Staffan Larsen wrote:
Please review this small fix of additional NULL-checks in SA on OS X.
webrev: http://cr.openjdk.java.net/~sla/8013466/webrev.00/
Thanks,
/Staffan
Actually, even better alternatives are Arrays.copyOf or array.clone();
/R
On Apr 29, 2013, at 3:15 PM, Rickard Bäckman wrote:
Staffan,
the change looks good, however I would be happy if we actually used the
arraycopy instead :)
/R
On Apr 29, 2013, at 2:43 PM, Staffan Larsen wrote
Staffan and David, thanks for your reviews.
/R
On Apr 26, 2013, at 2:57 PM, Staffan Larsen wrote:
Looks good.
/Staffan
On 26 apr 2013, at 07:31, Rickard Bäckman rickard.back...@oracle.com wrote:
I've updated the webrev (empty struct option).
http://cr.openjdk.java.net/~rbackman
I've updated the webrev (empty struct option).
http://cr.openjdk.java.net/~rbackman/8013117.u1/
Thanks
/R
On Apr 24, 2013, at 2:40 PM, Rickard Bäckman wrote:
David,
On Apr 24, 2013, at 2:25 PM, David Holmes wrote:
On 24/04/2013 9:05 PM, Rickard Bäckman wrote:
David,
On Apr 24, 2013
Hi all,
can I have a couple of reviews for this small change. The short story is that
the current way the thread-local _trace_buffer is somewhat inflexible.
By changing the type of the getter this structure gets more flexible for
different implementations. I also think that the name is misused.
wrote:
Does it matter that the pointer gets initialized to NULL before, but not now?
There isn't any null checks anywhere that depends on that?
Regards,
Nils
On 04/24/2013 09:51 AM, Rickard Bäckman wrote:
Hi all,
can I have a couple of reviews for this small change. The short story
Peter,
the change looks good to me (not a Reviewer).
I know it is against the local style of the file, but I would prefer if we
declared and initialized the variables at first use, and in that way reduced
chances of this kind of mistakes.
/R
On Apr 24, 2013, at 11:31 AM, Peter Allwin wrote:
David,
On Apr 24, 2013, at 12:11 PM, David Holmes wrote:
On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
Nils,
no it doesn't matter. Rather intended. By initializing it to NULL we forced
implementors to use a pointer that would have to be initialized at some
point. Now it can be a class
David,
On Apr 24, 2013, at 2:25 PM, David Holmes wrote:
On 24/04/2013 9:05 PM, Rickard Bäckman wrote:
David,
On Apr 24, 2013, at 12:11 PM, David Holmes wrote:
On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
Nils,
no it doesn't matter. Rather intended. By initializing it to NULL we
David,
thanks for the review.
/R
On Apr 22, 2013, at 8:23 AM, David Holmes wrote:
Okay - seems ready to ship. :)
Thanks,
David
On 22/04/2013 3:20 PM, Rickard Bäckman wrote:
David,
you are right, the only users of this mechanism are the old flatprofiler
(which from what I could
consumed any post that the
suspended thread
may have issued.
Thanks
/R
On Apr 22, 2013, at 1:53 AM, David Holmes wrote:
Hi Rickard,
On 20/04/2013 12:19 AM, Rickard Bäckman wrote:
David,
here is an updated webrev with the changes incorporated.
http://cr.openjdk.java.net/~rbackman
Peter,
it looks good to me.
/R
On Apr 19, 2013, at 4:19 AM, David Holmes wrote:
Hi Peter,
On 19/04/2013 12:10 AM, Peter Allwin wrote:
Hi all, I'm still looking for reviews for this change...
Sounds like a perfectly reasonable change.
Reviewed.
Thanks,
David
Thanks!
/peter
javaTimeMillis()
David
On 15/04/2013 10:50 PM, David Holmes wrote:
On 15/04/2013 10:07 PM, Rickard Bäckman wrote:
David,
this is what the suggested semaphore.cpp/semaphore.hpp. Is that what
you are looking for?
sigh I thought so till I saw it - far uglier and complicated than I
had hoped
David,
the reason I introduced a new file was that we need the same changes from our
closed code. Better to have them in one place.
/R
On Apr 16, 2013, at 11:34 AM, David Holmes wrote:
Hi Rickard,
On 15/04/2013 8:56 PM, Rickard Bäckman wrote:
Hi all,
can I have a couple of small fixes
David,
thanks for the review!
/R
On Apr 16, 2013, at 11:42 AM, David Holmes wrote:
On 16/04/2013 7:38 PM, Rickard Bäckman wrote:
David,
the reason I introduced a new file was that we need the same changes from
our closed code. Better to have them in one place.
Got it! Hard to join
David,
any new thoughts?
Thanks
/R
On Apr 12, 2013, at 8:06 AM, Rickard Bäckman wrote:
On Apr 12, 2013, at 7:34 AM, David Holmes wrote:
On 12/04/2013 3:01 PM, Rickard Bäckman wrote:
On Apr 12, 2013, at 1:04 AM, David Holmes wrote:
On 11/04/2013 11:02 PM, Rickard Bäckman wrote
Hi all,
can I have a couple of small fixes for this change?
The purpose of the change is to make it easier to write events without having
to put them inside a #ifdef INCLUDE_TRACE.
The idea is that when INCLUDE_TRACE is false the code should be no-ops.
The webrev:
David,
this is what the suggested semaphore.cpp/semaphore.hpp. Is that what you are
looking for?
Webrev: http://cr.openjdk.java.net/~rbackman/webrev/
Thanks
/R
On Apr 15, 2013, at 8:59 AM, David Holmes wrote:
On 15/04/2013 4:55 PM, Rickard Bäckman wrote:
David,
any new thoughts
On Apr 12, 2013, at 7:34 AM, David Holmes wrote:
On 12/04/2013 3:01 PM, Rickard Bäckman wrote:
On Apr 12, 2013, at 1:04 AM, David Holmes wrote:
On 11/04/2013 11:02 PM, Rickard Bäckman wrote:
On Apr 11, 2013, at 2:39 PM, David Holmes wrote:
So what did you mean about pthread_semaphore
Hi all,
can I please have reviews for this change.
In the current implementation do_suspend uses spin loops to wait until a thread
has been suspended. I would like to change that to use semaphores to reduce CPU
usage and also make it easier to have a deterministic timeout. Since we are
David,
On Apr 11, 2013, at 2:15 PM, David Holmes wrote:
Rickard,
On 11/04/2013 9:51 PM, Rickard Bäckman wrote:
Hi all,
can I please have reviews for this change.
In the current implementation do_suspend uses spin loops to wait until a
thread has been suspended. I would like to change
On Apr 11, 2013, at 2:39 PM, David Holmes wrote:
On 11/04/2013 10:30 PM, Rickard Bäckman wrote:
David,
On Apr 11, 2013, at 2:15 PM, David Holmes wrote:
Rickard,
On 11/04/2013 9:51 PM, Rickard Bäckman wrote:
Hi all,
can I please have reviews for this change.
In the current
On Apr 12, 2013, at 1:04 AM, David Holmes wrote:
On 11/04/2013 11:02 PM, Rickard Bäckman wrote:
On Apr 11, 2013, at 2:39 PM, David Holmes wrote:
So what did you mean about pthread_semaphore (what is that anyway?) ??
Never mind, pthread condition variables.
Ah I see.
I really
Still need a Reviewer…
Thanks
/R
On Mar 25, 2013, at 12:43 PM, Staffan Larsen wrote:
Looks good to me - not a Reviewer.
/Staffan
On 25 mar 2013, at 12:13, Rickard Bäckman rickard.back...@oracle.com wrote:
Hi,
trying again, can I please have two reviews on this change?
Some small
Hi,
trying again, can I please have two reviews on this change?
Some small changes after offline discussion.
The webrev is available here:
http://cr.openjdk.java.net/~rbackman/8008357.u1/
Thanks
/R
On Mar 5, 2013, at 8:07 AM, Rickard Bäckman wrote:
Anyone have time to look
Anyone have time to look at this?
Thanks
/R
On Mar 1, 2013, at 10:27 AM, Rickard Bäckman wrote:
Hi all,
here comes another update to frame.safe_for_sender.
If the PC at a place where the stack doesn't match the _frame_size we
sometimes read an invalid return PC.
In this case we read
Hi all,
here comes another update to frame.safe_for_sender.
If the PC at a place where the stack doesn't match the _frame_size we sometimes
read an invalid return PC.
In this case we read one that pointed into the Safepoint blob.
We now pretty much guarded for all kind of blobs in
Kevin,
looks good to me. (Not a Reviewer).
/R
On Feb 25, 2013, at 7:21 PM, Kevin Walls wrote:
Hi,
This is a crash I stumbled upon: jstack -m will crash when it doesn't match
the bitness of its target. On Solaris we check and give an exception
message, Linux should do similarly.
Hi all,
I just got a small patch this time that makes sure that a pc given to a frame
is actually in the code part of the codeBlob.
The case that assert here was pointing into the data part of the codeBlob.
This webrev is only for hs24 so far. Waiting for pending changes in hs25.
webrev:
a null reference access could cause a stop.
David
On 13/02/2013 10:28 PM, Rickard Bäckman wrote:
Hi all,
can I please have a couple of reviews of this change.
The problem discovered was the on Linux and BSD SA uses the ptrace() method
to stop the threads before inspecting the memory
Staffan,
nice work. Looks good to me. (Not a Reviewer).
/R
13 feb 2013 kl. 16:05 skrev Staffan Larsen staffan.lar...@oracle.com:
Please review the following change.
When SA attaches to a JVM on OS X, it does not stop the process. If the JVM
keeps running while SA inspects it can lead to
Staffan,
the change looks good to me! Thanks for fixing this problem.
/R
On Jan 17, 2013, at 8:48 PM, Staffan Larsen wrote:
This is a request for review of a fix for SA on OS X.
webrev: http://cr.openjdk.java.net/~sla/8006423/webrev.00/
bug:
Thanks for the review, David.
/R
On Feb 1, 2013, at 7:59 AM, David Holmes wrote:
On 1/02/2013 4:54 PM, Rickard Bäckman wrote:
That was the idea.
However, can I have Ok for checking this into hs24 while waiting?
Sorry - ignore the hs25 comment - been looking at too many JDK review
That was the idea.
However, can I have Ok for checking this into hs24 while waiting?
Thanks
/R
On Jan 21, 2013, at 11:33 PM, David Holmes wrote:
On 22/01/2013 12:09 AM, Rickard Bäckman wrote:
Yes, that code has changed. Checked in to hs24.
Okay but this is a review for hs25 ;-) So I assume
Katja,
I think the change looks good.
However we need to find an official reviewer before we can push this.
Can we get an official reviewer to look on this change please?
Thanks
/R
On Jan 30, 2013, at 3:11 PM, Yekaterina Kantserova wrote:
Hi everyone,
In the previous mail I've referred
Hi all,
would some please review the following change?
With recent changes in hs24 the ProfileVM_lock is no longer in use. This small
change set removes the lock.
The changes that lead to this is also on their way into hsx, but are not yet
there. If that change would go into hsx without this
://cr.openjdk.java.net/~rbackman/8006563.2/ (or at least
currently copying…)
/R
On Jan 18, 2013, at 2:12 PM, Aleksey Shipilev wrote:
On 01/18/2013 04:58 PM, Rickard Bäckman wrote:
http://cr.openjdk.java.net/~rbackman/8006563/
Looks good to me (not a Reviewer), modulo:
a) Are we sure this thing
Jaroslav,
the change looks good!
/R
On Jan 7, 2013, at 2:44 PM, Jaroslav Bachorik wrote:
Looking for reviewers and a sponsor.
This is a simple patch to remove unused java.beans.* imports from
com.sun.jmx.mbeanserver.Introspector. The actual usage of java.beans.*
classes was removed from
Looks good!
/R
On Oct 15, 2012, at 2:14 PM, Jaroslav Bachorik wrote:
On 10/15/2012 01:45 PM, David Holmes wrote:
On 15/10/2012 8:08 PM, Jaroslav Bachorik wrote:
On 10/15/2012 04:19 AM, David Holmes wrote:
I think your changes now go further than needed. The original code uses
a dual
Thank you Markus.
/R
On Oct 12, 2012, at 7:29 AM, Markus Grönlund wrote:
I am ok with this change Rickard.
Thanks also to David Holmes for his great feedback and help on this one.
/Markus
Sent from my iPhone
On 12 okt 2012, at 07:06, Rickard Bäckman rickard.back...@oracle.com wrote
People,
I need at least one more reviewer, thanks!
/R
On Oct 9, 2012, at 3:00 PM, Rickard Bäckman wrote:
David,
thanks for your review!
/R
On Oct 9, 2012, at 2:01 PM, David Holmes wrote:
On 9/10/2012 9:42 PM, Rickard Bäckman wrote:
David,
see inline.
On Oct 9, 2012, at 1:18
Looks good, ship it.
/R
On Oct 9, 2012, at 1:27 AM, Yumin Qi wrote:
Hi, All
Can I have your codereview for
8000412
: Clean SA code on ia64
Summary: Clean up IA64 code in SA since SA does no t support this cpu
architecture.
Reviewed-by:
Contributed-by:
Trying again,
can I have a couple of reviews, please?
/R
On Oct 4, 2012, at 3:01 PM, Rickard Bäckman wrote:
Hi all,
can I please have a couple of reviews on the following change:
http://cr.openjdk.java.net/~rbackman/7127792/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127792
-notify_all();
There is only one thread that waits so notify() will suffice.
Thanks,
David
On 9/10/2012 4:34 PM, Rickard Bäckman wrote:
Trying again,
can I have a couple of reviews, please?
/R
On Oct 4, 2012, at 3:01 PM, Rickard Bäckman wrote:
Hi all,
can I please have a couple
David,
see inline.
On Oct 9, 2012, at 1:18 PM, David Holmes wrote:
On 9/10/2012 7:36 PM, Rickard Bäckman wrote:
David,
thanks for your reply!
I've changed the code according to the suggestions, I've also changed the
types in PeriodicTask from being a size_t to being a
jint (see updated
David,
thanks for your review!
/R
On Oct 9, 2012, at 2:01 PM, David Holmes wrote:
On 9/10/2012 9:42 PM, Rickard Bäckman wrote:
David,
see inline.
On Oct 9, 2012, at 1:18 PM, David Holmes wrote:
On 9/10/2012 7:36 PM, Rickard Bäckman wrote:
David,
thanks for your reply!
I've
Hi all,
can I please have a couple of reviews on the following change:
http://cr.openjdk.java.net/~rbackman/7127792/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127792
In short the purpose is to enable tasks to change the interval they are
executed in. We
would also like to be able to
Looks good.
/R
On Sep 10, 2012, at 6:39 PM, Stefan Karlsson wrote:
http://cr.openjdk.java.net/~stefank/7197350/webrev/
7197350: NPG: jvmtiHeapReferenceCallback receives incorrect reference_kind
for system class roots
Summary: Fix the iteration over the system classes and report the
Looks good.
/R
On Sep 5, 2012, at 1:51 PM, Staffan Larsen wrote:
Please review the patch below to make the jstatd tests a little bit more
resilient to different outputs of the jps command.
The jps command can output a couple of different error messages when
information is missing about
fix so IMHO you could get away with
a context diff in the suggested fix of the bug report.
Sorry, I pasted the wrong url, the public one is available here:
http://cr.openjdk.java.net/~rbackman/7093328/
Thanks for the review Dan!
/R
On 8/29/12 1:24 AM, Rickard Bäckman wrote:
Hi all,
can I
Thanks Serguei.
/R
On Aug 29, 2012, at 6:46 PM, serguei.spit...@oracle.com wrote:
Hi Richard,
I see you've already got enough reviewers.
The fix looks good.
Nice finding!
Thanks,
Serguei
On 8/29/12 12:24 AM, Rickard Bäckman wrote:
Hi all,
can I get a couple of reviews
Hi all,
can I get a couple of reviews for the following bug fix:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093328
webrev: http://rbackman.se.oracle.com/~rbackman/7093328/
Thanks
/R
.
Makes sense to me…
/R
On Aug 29, 2012, at 10:46 AM, Rickard Bäckman wrote:
David,
I'll try to find the sources and see if I can find any obvious difference.
I've considered adding a regression test, however I couldn't come up with an
idea that wouldn't
involve native libraries. I've
Serguei,
looks good!
/R
On Aug 22, 2012, at 8:34 PM, serguei.spit...@oracle.com wrote:
Dmitry,
Thank you for the review!
Please, find new webrev version here:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2012/7191786-JVMTI-LVTT.1/
I also changed the line:
196 if
Looks good.
/R
On 06/25/2012 03:49 PM, Staffan Larsen wrote:
Here is an updated webrev. The last one didn't compile on Solaris.
http://cr.openjdk.java.net/~sla/7178703/webrev.02/
Thanks,
/Staffan
On 21 jun 2012, at 13:30, Staffan Larsen wrote:
Please review the following fix to the
Staffan,
the change looks good.
/R
On 06/25/2012 10:05 AM, Staffan Larsen wrote:
Please review the following fix.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7178846
Webrev: http://cr.openjdk.java.net/~sla/7178846/webrev.01/
Class CallbackWrapper in jvmtiTagMap.cpp has a missing
On 06/20/2012 02:07 PM, Kirk Pepperdine wrote:
Hi Staffan,
Thanks for the feedback!
It is going to be hard to find the right balance between a system that provides
great power and one that is simple to use and to implement. In general, I will
lean more towards making it simple, but I want
Looks good.
/R
On 05/24/2012 09:46 AM, Nils Loodin wrote:
when the 'demo' java_crw_demo (which is used by hprof) tries to mirror the
constant pool of a class, a few of the constants introduced by invokedynamic
ins't recognized.
Fairly simple fix. For my simple repro, it seems to work with
Hi,
my refactoring broke the SA on Windows, the only platform that didn't
have a declaration of the thread_id type in vmStructs.
This change adds the declares the field as an unsigned integer.
Tested by building in JPRT and connecting with jsadebugd.exe on Win64.
Bug:
Thank you for the quick review David.
/R
On 05/24/2012 02:28 PM, David Holmes wrote:
OK.
David
On 24/05/2012 10:16 PM, Rickard Bäckman wrote:
Hi,
my refactoring broke the SA on Windows, the only platform that didn't
have a declaration of the thread_id type in vmStructs.
This change adds
Hi,
this has been out on review for a while, without any OK or objections.
So I'll ask again, can I have a review or two on this small change?
Thanks
/R
On 05/03/2012 11:39 AM, Rickard Bäckman wrote:
Hi all,
I've made a refactoring of thread_id in OSThread, which reduces the
amount
Thank you, David!
/R
On 05/14/2012 01:29 PM, David Holmes wrote:
On 14/05/2012 6:55 PM, Rickard Bäckman wrote:
this has been out on review for a while, without any OK or objections.
So I'll ask again, can I have a review or two on this small change?
Sorry Rickard I got distracted from my
On 05/07/2012 10:55 AM, David Holmes wrote:
On 7/05/2012 5:21 PM, Rickard Bäckman wrote:
David,
I can't find that code in any of the modified files (only as blue text
in osThread_bsd.hpp, but that is removed code).
Sorry the frames view of the webrev confused me. It is blue
Hi all,
I've made a refactoring of thread_id in OSThread, which reduces the
amount of duplicated code.
Please review this change at:
http://cr.openjdk.java.net/~rbackman/7161732/webrev/
Thanks
/R
Hi all,
can I have some reviews for my attempt at making OSThread a bit more
generic, reducing the code duplication.
Webrev: http://cr.openjdk.java.net/~rbackman/7161732/webrev/
Thanks
/R
Hi,
after some internal discussions it is clear that there are a couple of problems
with this change.
Please ignore it for now.
Thanks
/R
On Apr 18, 2012, at 8:16 AM, Rickard Bäckman wrote:
Hi all,
can I have some reviews for my attempt at making OSThread a bit more generic,
reducing
{ return _thread_id; }
Otherwise it looks good.
Thanks for catching that one, I'll change it and submit.
/R
tom
On Apr 13, 2012, at 6:49 AM, Rickard Bäckman wrote:
Thank you Staffan,
still need one Reviewer, any takers?
Thanks
/R
On 04/13/2012 11:21 AM, Staffan Larsen wrote:
Looks good
Thank you Staffan,
still need one Reviewer, any takers?
Thanks
/R
On 04/13/2012 11:21 AM, Staffan Larsen wrote:
Looks good.
/Staffan
On 11 apr 2012, at 14:55, Rickard Bäckman wrote:
Hi all,
can I get reviews for the following change where we add support for intrinsics
for a couple
1 - 100 of 114 matches
Mail list logo
