Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8227815
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8227815/webrev.00/
After JDK-8225690, minimal VM could not be built.
Minimal VM does not include Attach Listener implementation. So I exclude it in
os.c
Looks good.
Chris
On 7/17/19 7:37 AM, Yasumasa Suenaga wrote:
Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8227815
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8227815/webrev.00/
After JDK-8225690, minimal VM could not be built.
Minimal VM does not
Thank you, Chris and Serguei, for reviewing this change!
Best regards,
Daniil
On 7/16/19, 4:58 PM, "Chris Plummer" wrote:
Looks good.
Chris
On 7/16/19 4:12 PM, Daniil Titov wrote:
> Please review the change that fixes the failure of the test.
>
> The test assu
Hi all,
Please review this change that addresses JDK-8226575 according to a
previous discussion on this list [0][1]. The webrev has been kindly
uploaded on my behalf by Severin Gehwolf, since I am not an author.
The initial problem was that the
com.sun.management.OperatingSystemMXBean was inconsi
Hi Daniil,
It's a little unclear to me why you moved from ProcessThread to
TestProcessThread + Process. An explanation of that would make it easier
to understand many of the changes.
thanks,
Chris
On 7/11/19 10:16 AM, Daniil Titov wrote:
Please review the change that fixes an intermittent
Hi Chris,
>It's a little unclear to me why you moved from ProcessThread to
> TestProcessThread + Process. An explanation of that would make it easier
> to understand many of the changes.
There are two reasons for that:
1) For every network interface the test starts a separate thread th
Hi Daniil,
The fix looks good in general.
Couple cosmetic notes (no new webrev required):
162 needRetry = runTest();
163 }
164 while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS));
Please move "while" to the prev line:
163 } while (needRet
Hi Daniil,
I think you can remove "Ok" from the following message:
237 System.out.println("DEBUG: OK. Spawned java process terminated
with expected exit code of "
238 + STOP_PROCESS_EXIT_VAL);
It's somewhat misleading since the test can still fail. I think the
follo
Hi Chris and Alex,
Please review a new version of the fix that moves the diagnostic output for the
test failure to run()
method after the number of retry attempts is exceeded. It also includes other
corrections that
you suggested.
Thanks!
Webrev: http://cr.openjdk.java.net/~dtitov/8221303/web
What does output.reportDiagnosticSummary() print out then the port is
already in use, and have you made this happen with your fixes in place?
Chris
On 7/17/19 3:20 PM, Daniil Titov wrote:
Hi Chris and Alex,
Please review a new version of the fix that moves the diagnostic output for the
test
Hi Chris,
output.reportDiagnosticSummary() prints the output from the process (both
stdout and stderr) and the exit value to the test's stderr.
In case if the port is already in use it prints the following:
stdout: [];
stderr: [Error: JMX connector server communication error:
service:jmx:rmi:/
Hi Daniil,
I'm confused now. I mentioned output.reportDiagnosticSummary() because I
thought I saw it in your webrev-02. Now I don't. Maybe I had glanced
back at webrev-01 and saw it there. One issue with exceptions in the
output that are not considered errors is that if later there is an
erro
Hi Chris,
Yes, I added output.reportDiagnosticSummary() in webrev-01, but removed it
In webrev-02, and later restored it in webrev-03.
When the test runs of retries output.getExitValue() is set to 1
(COMMUNICATION_ERROR_EXIT_VAL)
(the "exitValue =1 " in the previous email).
Please review a n
Hi Martin,
I need to think about this some more. A critical property of the fast
field accessors are that they are trivial and completely safe. They are
complicated by the need to check if a GC may have happened while we
directly read the field.
If you try to use fast field accessors when yo
On 16/07/2019 9:42 pm, Langer, Christoph wrote:
Hi Ralf,
looks good. Prior to pushing you’ll have to take care of the copyright years in
the files you touched 😊
cc-ing hotspot-runtime, because I think it affects this area, too.
tl;dr - looks fine. :)
I was in two minds about this. To me thi
Hi Martin,
Since the JNI calls go through function pointers in the JNI env that go either
to the fast or slow version, could one option be to go through the JNI envs and
change the function pointers to the slow one when this JVMTI feature is enabled?
Advantages:
1) No need to change the platfor
16 matches
Mail list logo
