Looks good Yasumasa.
Thanks,
Sharath
-Original Message-
From: Yasumasa Suenaga [mailto:yasue...@gmail.com]
Sent: Tuesday, January 15, 2019 5:35 PM
To: serviceability-dev@openjdk.java.net
Subject: PING: RFR: 8181313: SA: Remove libthread_db dependency on Linux
PING: Could you review it
Please review the change that fixes JDB stepping issue for a specific case when
the single step request was initiated earlier in the stack, previous calls were
for methods in the filtered classes (single stepping was disabled),
handleMethodEnterEvent() re-enabled stepping and the first bytecode
Just a few small things.
In attachListener.cpp, line 278, is the static_cast needed? fileStream is a
subclass of outputStream, so it should be ok to pass to the
VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't
know about.
In attachListener.cpp, line 275, change "Fai
Hi Gary,
On 01/17/2019 10:53, Gary Adams wrote:
I like the fact that test.timeout.factor is applied as a multiplier.
It's not clear why an upper limit had to be added.
As you noted there 3 cases where Thread.join() is called, but the
expected behavior is different. objWaiterThr2 and popFrame
I like the fact that test.timeout.factor is applied as a multiplier.
It's not clear why an upper limit had to be added.
Is that 50 or 5 seconds?
148 objWaiterThr1.join(Math.min(WAIT_TIME, 5));
Why are the other wait times not limited?
136 objWaiterThr2.join(WAIT_T
Hi Alex,
Looks good to me.
Thanks!
Best regards,
Daniil
On 1/17/19, 9:47 AM, "Alex Menkov" wrote:
Hi Daniil,
On 01/16/2019 22:27, Daniil Titov wrote:
> Hi Alex,
>
> The change looks good to me but I think the copyright comment needs to be
updated for year 2019.
Hi Daniil,
On 01/16/2019 22:27, Daniil Titov wrote:
Hi Alex,
The change looks good to me but I think the copyright comment needs to be
updated for year 2019.
Updated the webrev in-place.
--alex
Thanks.
Best regards,
Daniil
On 1/16/19, 3:29 PM, "serviceability-dev on behalf of Alex M
On re-reading this thread, I realized that my concern about:
> rename A to A1
was not clear. I'm wasn't worried about the virus scanner having file
A1 open. I was worried about the virus scanner having file A open and
preventing the rename from happening. I have a vague memory of this
happening
PS: for the caller being incorrect, the following change in
VFrame.newVFrame fixes it:
// FIXME: should revisit the check of isDebugging(); should
not be necessary
//if (mayBeImprecise || VM.getVM().isDebugging()) {
if (mayBeImprecise) {
scope = nm.getScop
Here is example as promised. First the test program:
1 public class PcDescTest
2 {
3 public static void main(String[] args)
4 {
5 new PcDescTest();
6 }
7
8 PcDescTest()
9 {
10 for (int i = 0; ; i++) {
11 run(i);
12 }
13
Updated webrev:
Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.01/
On 1/17/19 12:44 AM, David Holmes wrote:
On 17/01/2019 1:48 am, Gary Adams wrote:
Looking through the test history for the vm/mlvm version of
InstallSDE.java there has never
been a reported problem with the rename
Hi Jc, ok thanks, I'll see if I can come up with a simple example.
Cheers,
David
On Wed, 16 Jan 2019 at 17:30, JC Beyler wrote:
> Hi David,
>
> The explanation you are providing is clear to me, though I'm not sure at
> all what the right fix would be in this case. I would agree that there
> mi
12 matches
Mail list logo