On 11/14/14 5:35 AM, Ivan Gerasimov wrote:
Hello!
The recent fix for JDK-8059533 ((process) Make exiting process wait
for exiting threads [win]) caused the warning message to be printed in
some test environments:
---
os_windows.cpp:3844 is in the newly updated
os::win32::exit_process
On Friday, November 14, 2014, Vladimir Kozlov
wrote:
> Volker or Goetz, can you help Maynard to create bugs and prepare webrevs
> on cr.openjdk for these 3 changes?
>
>
I will create the bugs and have look at the changes on monday.
Regards,
Volker
> Thanks,
> Vladimir
>
> On 11/14/14 10:09 AM,
> I presume I don't need to sent out another webrev...
I have to change my mind on this because this fix needs to be
backported to JDK8u-hs-dev.
Here's the updated JDK9 webrev:
http://cr.openjdk.java.net/~dcubed/8033602-webrev/1-jdk9-hs-rt/
And here's the JDK8u-hs-dev backport:
http://cr.open
Maynard,
Thank you for this contribution.
Could I ask you to prepare a webrev?
http://openjdk.java.net/guide/webrevHelp.html
-Dmitry
On 2014-11-14 21:09, Maynard Johnson wrote:
> When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core
> file, they fail with the following run
Volker or Goetz, can you help Maynard to create bugs and prepare webrevs
on cr.openjdk for these 3 changes?
Thanks,
Vladimir
On 11/14/14 10:09 AM, Maynard Johnson wrote:
When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file,
they fail with the following runtime excepti
On Fri, Nov 14, 2014 at 6:00 PM, Maynard Johnson wrote:
> On 10/07/2014 08:35 AM, Maynard Johnson wrote:
>> On 10/07/2014 03:58 AM, Volker Simonis wrote:
>>> Hi Maynard,
>>>
>>> I'm now back from JavaOne and can look at this issue. Could you please
>>> share your current implementation so I can re
This patch adds PPC64 implementations of various class files needed to support
the Hotspot serviceability agent, most of which involves mirroring the VM's
stack
for the jstack tool. The patch also makes some minor updates to several
architecture-independent class files to enable ppc64 support.
G
When Hotspot SA tools jmap, jstack, and jsadebugd are run against a core file,
they fail with the following runtime exception:
OS/CPU combination linux/ppc64 not yet supported
I will post a patch set that adds this support. The patch set consists of the
following patches:
PATCH 1/2: Upda
This patch updates some build files and C/C++ files to enable the PPC64
Serviceability
agent code in patch 2/2.
Signed-off-by: Maynard Johnson
Index: jdk9-dev/hotspot/agent/make/Makefile
===
--- jdk9-dev.orig/hotspot/agent/make/Mak
On 10/07/2014 08:35 AM, Maynard Johnson wrote:
> On 10/07/2014 03:58 AM, Volker Simonis wrote:
>> Hi Maynard,
>>
>> I'm now back from JavaOne and can look at this issue. Could you please
>> share your current implementation so I can reproduce your problem more
>> easily.
> See attachment. The two
Hi Daniel,
Our documentation does not specify the exact exception that should be thrown in
this scenario. But it should be reasonable.
That makes testcase very difficult to implement. Because "reasonable" is not
clear for test.
E.g. "divided by zero" is not reasonable, but "illegal argument" is.
Hi everyone,
we have a problem in our instrument.dll - on windows - which is caused by
the fact that it links against the static CRT instead of the dynamic CRT.
The problem is probably uninteresting and has to do with the fact that we
run then with two C-Runtimes;
there are a number of ways to fi
Hi Sergey,
The fix looks fine.
I wonder whether there should be a testcase for that?
best regards,
-- daniel
On 14/11/14 14:10, Jaroslav Bachorik wrote:
Good to go.
-JB-
On 11/14/2014 02:07 PM, Sergey Gabdurakhmanov wrote:
Hi,
Could I please have a review of this small fix.
webrev: http
Good to go.
-JB-
On 11/14/2014 02:07 PM, Sergey Gabdurakhmanov wrote:
Hi,
Could I please have a review of this small fix.
webrev: http://cr.openjdk.java.net/~sgabdura/8048050/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8048050
Problem description:
If the com.sun.management.jmxr
Hello!
The recent fix for JDK-8059533 ((process) Make exiting process wait for
exiting threads [win]) caused the warning message to be printed in some
test environments:
---
os_windows.cpp:3844 is in the newly updated
os::win32::exit_process_or_thread(Ept what, int exit_code)
---
On 2014-11-14 10:55, Alan Bateman wrote:
> On 14/11/2014 09:32, Mikael Auno wrote:
>> :
>> Here's an updated webrev with your proposed changes.
>>
>> http://cr.openjdk.java.net/~miauno/8064799/webrev.01/
>>
> This looks to okay, thanks for taking the concern on board.
>
> -Alan
Perfect. Thanks fo
On 14/11/2014 09:32, Mikael Auno wrote:
:
Here's an updated webrev with your proposed changes.
http://cr.openjdk.java.net/~miauno/8064799/webrev.01/
This looks to okay, thanks for taking the concern on board.
-Alan
Or maybe the PIT was just started before the fix for JDK-8062735 was in?
Pit started on november 7, and bug was closed on november 6. It should be in,
but mayvbe it was not?
Mattias
- Original Message -
From: mattias.tobias...@oracle.com
To: serviceability-dev@openjdk.java.net
Cc: dmitry
Hi,
Many tmtools/jmap and tmtools/jstack tests fails in PIT.
Below is a typical stack trace.
My guess is that this is the same thing as last week about serviceability not
recognizing a new compiler thread.
https://bugs.openjdk.java.net/browse/JDK-8062735
Tests only fails on Mac.
Does anyone know
On 2014-11-14 09:53, Alan Bateman wrote:
> On 14/11/2014 08:40, Staffan Larsen wrote:
>> :
>>
>> So the goal here has been to increase the test coverage of hotspot
>> jprt push jobs, but with a limited impact on execution time. This is
>> all to make sure hotspot changes do no break serviceability
On 14/11/2014 08:40, Staffan Larsen wrote:
:
So the goal here has been to increase the test coverage of hotspot
jprt push jobs, but with a limited impact on execution time. This is
all to make sure hotspot changes do no break serviceability features.
While it would be great to run all tests a
On 2014-11-14 03:28, David Holmes wrote:
> So to be clear this adds the JDK JDI tests (select subset thereof) to
> "-testset hotspot" for full forest submissions to JPRT.
Yes, that is precisely the idea; adding SVC tests to hotspot JPRT pushes
so that development in other teams does not break SVC
> On 14 nov 2014, at 09:03, Alan Bateman wrote:
>
> On 13/11/2014 13:56, Mikael Auno wrote:
>> Hi,
>>
>> Could I please get a review of this addition of SVC tests to JPRT submit
>> jobs. So far, I'm only adding JDI tests as those are the only ones I
>> have completed code coverage analysis on t
On 13/11/2014 13:56, Mikael Auno wrote:
Hi,
Could I please get a review of this addition of SVC tests to JPRT submit
jobs. So far, I'm only adding JDI tests as those are the only ones I
have completed code coverage analysis on to determine the best subset to
add. The other areas will be added to
24 matches
Mail list logo
