Hi Serguei,
Thank you for the comment.
I fixed / added the comment in new webrev. Could you check again?
http://cr.openjdk.java.net/~ysuenaga/JDK-8226204/webrev.02/
Yasumasa
On 2019/08/16 8:03, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
Thank you for the update!
A couple of
Hi Yasumasa,
Thank you for the update!
A couple of suggestions:
213 * This method converts jhsdb-style options (oldArgs) to oldfashioned
Replace: "oldfashioned " => "old fashioned".
There are several occurrences of it.
214 * style. SALauncher delegates the work to the entry point of each
> On Aug 15, 2019, at 7:46 AM, Stefan Karlsson
> wrote:
>
> Thanks Kim, Roman, Dan and Coleen for reviews and feedback.
>
> I rebased the patch, fixed more alignments, renamed the bug, and rerun the
> test through tier1-3.
>
>
Hi Roman,
On 2019-08-15 19:06, Roman Kennke wrote:
Hi Stefan,
I looked over the changes again. I like this much better, a huge
improvement over current state, and also better than your first
proposal. I also prefer the explicit value() calls.
Great!
I also built+tested Shenandoah GC
Hi Stefan,
I looked over the changes again. I like this much better, a huge
improvement over current state, and also better than your first
proposal. I also prefer the explicit value() calls.
I also built+tested Shenandoah GC again, seems all fine.
Didn't know that C++ has an 'explicit'
Hi Serguei,
I added the explanation as a comment in parseOptions what is longOptsMap,
and how parseOptions() work in new webrev.
http://cr.openjdk.java.net/~ysuenaga/JDK-8226204/webrev.01/
I'm not good at English, so comments are welcome :)
Thanks,
Yasumasa
On 2019/08/15 17:12,
Thanks Kim, Roman, Dan and Coleen for reviews and feedback.
I rebased the patch, fixed more alignments, renamed the bug, and rerun
the test through tier1-3.
https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/
Hi Serguei, Daniel,
Good to hear you like the fix.
My intention with the testing was to make sure my change didn't break
anything else. I didn't do a code paths check before I ran it though;
saturation run.
As for writing a new test, I'm finding it tricky.
Here's the current flow:
Step 1)
Hi Adam,
The fix itself looks Okay to me.
I'm not sure there is any test case in these test suites which
provide a coverage for it.
It looks like you need to develop a unit jtreg unit test for this.
Thanks,
Serguei
On
Hi Yasumasa,
In fact, I have a problem to understand what the parseOptions() method is doing.
Could you add necessary comments explaining what is done in the
loop?
I'm sure I'll be not alone in having trouble to read this code.
Also, it is
Thanks Andrew and Chris. Pushed here:
https://hg.openjdk.java.net/jdk/jdk/rev/902cef494e66
Nick
On 14/08/2019 16:10, Andrew Dinn wrote:
On 14/08/2019 03:28, Chris Plummer wrote:
On 8/13/19 6:26 PM, Nick Gasson wrote:
Hi Chris,
The changes look good, although I think the new file should
Bug: https://bugs.openjdk.java.net/browse/JDK-8229160
Preliminary webrev (still has rough edges):
http://cr.openjdk.java.net/~dholmes/8229160/webrev.prelim/
Background:
We've had this comment for a long time:
// The raw monitor subsystem is entirely distinct from normal
//
12 matches
Mail list logo
