David,
> Thanks, this looks okay.
Thank you for review!
> Only minor concern is whether we have to
> apply casts to the results of geteuid() and st.st_uid when used with
> %d format specifier?
I didn't see any complains neither from jprt nor building locally.
uid_t is 4 byte type for both 32b
On 2016-08-12 12:04, Dmitry Samersoff wrote:
> David,
>
> Updated webrev is:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/
>
> Windows is absolutely different story that requires significant efforts
> to reproduce error conditions and test changes. Also it has nothing to
> do
All,
Please review this fix for a test that starting failing after recent changes to
java.lang.invoke.
The test instructs jdb to break on all exceptions matching "java.lang.I*"
(that's a capital 'i'). The semantics of that operation actually means "break
on all exceptions which have a class n
Staffan,
Looks good for me!
-Dmitry
On 2016-08-15 21:15, Staffan Larsen wrote:
> All,
>
> Please review this fix for a test that starting failing after recent changes
> to java.lang.invoke.
>
> The test instructs jdb to break on all exceptions matching "java.lang.I*"
> (that's a capital 'i
Thank you!
> On 15 aug. 2016, at 20:27, Dmitry Samersoff
> wrote:
>
> Staffan,
>
> Looks good for me!
>
> -Dmitry
>
>
> On 2016-08-15 21:15, Staffan Larsen wrote:
>> All,
>>
>> Please review this fix for a test that starting failing after recent changes
>> to java.lang.invoke.
>>
>> The
Hi Staffan,
Looks good.
Though I do wonder how the matching logic works such that the superclass
is considered. I suppose it is a "feature" to match on X and all
subclasses of X, but probably should be a way to match on exactly X not
subclasses. Anyway just idle thoughts. :)
Thanks,
David
Hello,
Please review and provide comments for fix for issue,
https://bugs.openjdk.java.net/browse/JDK-8152589
having webrev located at
http://cr.openjdk.java.net/~hb/8152589/webrev.00/
Fix details:
1. From nightly failures we see that LockThreadB was blocked on wrong
object. We now do a rep
Yes. assertEQorGTE can be used. But using assertEQorLTE is better suited
as it increase code readability. So I would like to leave that in place.
On Saturday 13 August 2016 12:59 AM, Staffan Larsen wrote:
If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use
assertEQo
Hi,
Reminder, please help me with this review.
Regards,
Mallikarjuna Avaluri
On 8/9/2016 11:11 AM, Mallikarjuna Avaluri wrote:
Hi all,
Could you please review fix for following issue.
Bug id: https://bugs.openjdk.java.net/browse/JDK-8160913
Summary: [TEST_BUG] javax/management/security/