Hi Bin,
On 24/04/2020 7:28 pm, buddyliao(廖彬) wrote:
Dear all,
As Lin mentioned, I found the copyright info is not updated, so I prepared a
patch to fix this. Lin helps me to build an issue in the jdk bug system. Would
you help me to review this patch? Thank you very much.
Patch link: https://
Dear all,
As Lin mentioned, I found the copyright info is not updated, so I prepared a
patch to fix this. Lin helps me to build an issue in the jdk bug system. Would
you help me to review this patch? Thank you very much.
Patch link: https://cr.openjdk.java.net/~lzang/BuddyLiao/launcher/webrev/
I
Hi Henry, Alan, David
My colleague Bin(Buddy) just remind me that the copyright info of the
touched files should be updated, sorry that I forgot to add it in my original
patch , do you think there should be a patch for fixing that?
BRs,
Lin
On 2020/4/7, 4:56 PM, "Alan Bateman" wrote
On 06/04/2020 18:36, Henry Jen wrote:
Here is the combined webrev[1] which I think is what we should have. By using
__solaris__, we make sure no extra define from build and assuming that all
solaris build will have gethrtime() and use that.
The current build only use that for static build laun
Sure, will change the before I push. I considered that but didn’t run with it.
Cheers,
Henry
> On Apr 6, 2020, at 7:43 PM, David Holmes wrote:
>
> Hi Henry,
>
> On 7/04/2020 3:36 am, Henry Jen wrote:
>> Here is the combined webrev[1] which I think is what we should have. By
>> using __solari
Hi Henry,
On 7/04/2020 3:36 am, Henry Jen wrote:
Here is the combined webrev[1] which I think is what we should have. By using
__solaris__, we make sure no extra define from build and assuming that all
solaris build will have gethrtime() and use that.
This looks good to me and means the Sola
Here is the combined webrev[1] which I think is what we should have. By using
__solaris__, we make sure no extra define from build and assuming that all
solaris build will have gethrtime() and use that.
The current build only use that for static build launcher, not custom launcher
use libjli.
On 6/04/2020 12:37 pm, David Holmes wrote:
On 6/04/2020 12:20 pm, Henry Jen wrote:
On Apr 5, 2020, at 7:15 PM, David Holmes wrote:
On 6/04/2020 11:50 am, David Holmes wrote:
There is something not right here ...
On 4/04/2020 3:13 pm, Henry Jen wrote:
Internal test shows that inline implement
On 6/04/2020 12:20 pm, Henry Jen wrote:
On Apr 5, 2020, at 7:15 PM, David Holmes wrote:
On 6/04/2020 11:50 am, David Holmes wrote:
There is something not right here ...
On 4/04/2020 3:13 pm, Henry Jen wrote:
Internal test shows that inline implementation is not working for some Solaris
arti
On Apr 5, 2020, at 7:15 PM, David Holmes wrote:
>
> On 6/04/2020 11:50 am, David Holmes wrote:
>> There is something not right here ...
>> On 4/04/2020 3:13 pm, Henry Jen wrote:
>>> Internal test shows that inline implementation is not working for some
>>> Solaris artifacts, because the -DHAVE_G
On 6/04/2020 11:50 am, David Holmes wrote:
There is something not right here ...
On 4/04/2020 3:13 pm, Henry Jen wrote:
Internal test shows that inline implementation is not working for some
Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently
defined, so it is actually broken.
There is something not right here ...
On 4/04/2020 3:13 pm, Henry Jen wrote:
Internal test shows that inline implementation is not working for some Solaris
artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is
actually broken. :)
[2020-04-03T15:59:26,981Z] Creating
s
Agree，I also think inline may not be a problem.
The reason I used inline is to avoid touching java_md_linux.c.
BRs，
Lin
> 在 2020年4月6日，上午9:31，David Holmes 写道：
>
> On 6/04/2020 10:53 am, linzang(臧琳) wrote:
>>> Certainly we can change to not inline by combining both fixes. I don’t
>>> think
On 6/04/2020 10:53 am, linzang(臧琳) wrote:
Certainly we can change to not inline by combining both fixes. I don’t
think inline is necessary causing problem but that means header and the binary
does need to match.
How about use macro instead of function?
No that's not appropriate use of
> Certainly we can change to not inline by combining both fixes. I don’t
> think inline is necessary causing problem but that means header and the
> binary does need to match.
How about use macro instead of function?
+#define getTimeMicros() ({ \
+uint64_t result = 0; \
+struct
> On Apr 5, 2020, at 6:52 AM, Alan Bateman wrote:
>
>
> On 05/04/2020 14:17, David Holmes wrote:
>> On 4/04/2020 3:13 pm, Henry Jen wrote:
>>> Internal test shows that inline implementation is not working for some
>>> Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently
>>> d
On 05/04/2020 14:17, David Holmes wrote:
On 4/04/2020 3:13 pm, Henry Jen wrote:
Internal test shows that inline implementation is not working for
some Solaris artifacts, because the -DHAVE_GETHRTIME is not
consistently defined, so it is actually broken. :)
The problem is in defining that fu
On 4/04/2020 3:13 pm, Henry Jen wrote:
Internal test shows that inline implementation is not working for some Solaris
artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is
actually broken. :)
The problem is in defining that function as inline rather than the
-DHAVE_GE
Thanks Henry！[2] looks good to me!
BRs,
Lin
> 在 2020年4月4日，下午1:14，Henry Jen 写道：
>
> Internal test shows that inline implementation is not working for some
> Solaris artifacts, because the -DHAVE_GETHRTIME is not consistently defined,
> so it is actually broken. :)
>
>> [2020-04-03T15:59:26
Internal test shows that inline implementation is not working for some Solaris
artifacts, because the -DHAVE_GETHRTIME is not consistently defined, so it is
actually broken. :)
> [2020-04-03T15:59:26,981Z] Creating
> support/test/hotspot/jtreg/native/bin/jvm-test-launcher from 1 file(s)
> [2020
On 02/04/2020 11:26, linzang(臧琳) wrote:
:
Here is the updated webrev :
http://cr.openjdk.java.net/~lzang/8241638/webrev04/
Thanks for your help!
webrev04 looks good. My preference was to was to replace #ifdef
HAVE_GETHRTIME with #ifdef __solaris__ but there doesn't seem
>> No need for updated webrev.
P.S. I mode the webrev update so it is easy for me to record the changes 😝
Thanks!
Lin
On 2020/4/2, 6:21 PM, "linzang(臧琳)" wrote:
Dear David,
Here is the updated webrev :
http://cr.openjdk.java.net/~lzang/8241638/webrev04/
Thanks for
Dear David,
Here is the updated webrev :
http://cr.openjdk.java.net/~lzang/8241638/webrev04/
Thanks for your help!
BRs,
Lin
On 2020/4/2, 6:06 PM, "David Holmes" wrote:
On 2/04/2020 6:48 pm, linzang(臧琳) wrote:
> Hi David,
> Thanks to point it out, I have upl
On 2/04/2020 6:48 pm, linzang(臧琳) wrote:
Hi David,
Thanks to point it out, I have uploaded a new patch at
http://cr.openjdk.java.net/~lzang/8241638/webrev03/
As Alan pointed out this definition is not just for Linux. I would
suggest this comment block:
! * Add CounterGet() implementat
Hi David,
Thanks to point it out, I have uploaded a new patch at
http://cr.openjdk.java.net/~lzang/8241638/webrev03/
BRs,
Lin
On 2020/4/2, 2:54 PM, "David Holmes" wrote:
Hi Lin,
On 31/03/2020 12:39 pm, linzang(臧琳) wrote:
> Hi David, Henry, Alan,
> Thanks a
Hi Lin,
On 31/03/2020 12:39 pm, linzang(臧琳) wrote:
Hi David, Henry, Alan,
Thanks a lot for your review.
I have considered use clock_gettime() first, but I seached the code and
found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which
makes me think it may not be av
Hi Henry and Alan,
Here is the updated webrev:
http://cr.openjdk.java.net/~lzang/8241638/webrev02/webrev/
Thanks a lot for your help!
BRs,
Lin
On 2020/4/2, 3:20 AM, "Alan Bateman" wrote:
On 01/04/2020 18:47, Henry Jen wrote:
> Yes, we need an official Reviewer t
On 01/04/2020 18:47, Henry Jen wrote:
Yes, we need an official Reviewer to approve. I can help to push the change
after that.
I looked at the webrev01 but I don't think Lin has published the updated
version yet. Happy to Review.
-Alan
Yes, we need an official Reviewer to approve. I can help to push the change
after that.
Cheers,
Henry
> On Mar 31, 2020, at 9:55 PM, linzang(臧琳) wrote:
>
> Thanks Henry,
>
> I agree to leave Solaris as it is, it seems to me there is no strong reason
> to remove it.
>
> So, Do I need more
Thanks Henry,
I agree to leave Solaris as it is, it seems to me there is no strong reason to
remove it.
So, Do I need more review before push this patch?
And may I ask your help to push it if a go decision is made.
Thanks.
BRs,
Lin
On 2020/3/31, 12:30 PM, "Henry Jen" wrote:
OK, I
OK, I agree with David gettimeofday is an improvement than 1, so we can go
ahead with the patch. Not sure if the caveat should be disclosed or not, I
don’t think it’s important enough, just a known fact probably worth to leave a
trace(perhaps a comment in code or the bug entry). As whether to ch
Hi David, Henry, Alan,
Thanks a lot for your review.
I have considered use clock_gettime() first, but I seached the code and
found there is a marco SUPPORTS_CLOCK_MONOTONIC guard the usage of it. Which
makes me think it may not be available under specific situation. So I choosed
gettime
32 matches
Mail list logo
