Patch submission advice: use webrev, jtreg tests where, cmd line test?
Mandy.Chung at Sun.COM
Thu Feb 14 14:51:17 PST 2008
Thanks for getting a fix for 6523160. You can use
serviceability-dev at openjdk.java.net alias for submitting the patch and I
believe the change in the hotspot code is local to serviceability.
My comment is inlined....
Lars Westergren wrote:
> I have a fix ready for bug 6523160 - "RuntimeMXBean.getUptime() returns
> negative values". Mandy Chung long ago suggested I use this mailing list
> rather than the management mailinglist for this bug since the fix
> involves changes in Hotspot code.
> Before I submit, I wanted to clarify three things -
> 1. Should I include diff files as attachments as is recommended here:
> or do you now prefer that I use Webrev for OpenJDK as Jean-Christophe
> Collet describes, so I include a link to my webrev pages in the mail
It would be great if you can use webrev. It's a very useful code-review
generating tool and I'm sure you will like it.
You can either include a link to your webrev (public accessible) or
include the tarball of the webrev pages which is also fine with me.
> 2. My jtreg tests, would you prefer them included as standalone files
> attachments to the mail so you yourselves can decide where to put them,
> or should I place them in the correct package in jdk/test so they become
> a part of the webrev?
You can just include the jtreg tests in the
jdk/test/java/lang/management/RuntimeMXBean directory since the test
will be specific for testing that API. I'll be able to get a copy of
the test from the webrev generated.
FYI. The source and test location for the serviceability project are
> 3. Provoking the bug involves setting back the OS clock. Is it ok if I
> use the command line "date" command (making the test platform dependent)
> to set back the clock in the test? Or should I prefer user interaction
> as is done in some other tests I've seen - i.e. popping up a window that
> says "Set back the OS clock an hour now, click 'ok' when done to continue"?
The jtreg tests have to be fully automated and can be run on machines
that may be used by others for various purposes. In addition, changing
the clock on a shared machine might cause unexpected problems to other
applications/testing running on the same machine.
The Java SE Quality team has several functional tests that fail due to
this bug. I can help run those tests to verify your fix. We can work
P.S. I'll be on vacation next week and return on 1/25.
> Thanks in advance,
More information about the hotspot-dev