Paul,
Thank you!
-Dmitry
On 31.10.2017 20:32, Paul Sandoz wrote:
>
>> On 31 Oct 2017, at 05:58, Dmitry Samersoff
>> wrote:
>>
>> Paul and Frederic,
>>
>> Thank you.
>>
>> One more question. Do we need to call verify_oop below?
>>
Paul,
templateTable_x86.cpp:
564 const Register flags = rcx;
565 const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
Should we use another register for rarg under NOT_LP64 ?
-Dmitry
On 10/26/2017 08:03 PM, Paul Sandoz wrote:
> Hi,
>
> Please review the following patch for minimal d
Parain wrote:
> I’m seeing no issue with rcx being aliased in this code.
>
> Fred
>
>> On Oct 30, 2017, at 15:44, Paul Sandoz wrote:
>>
>> Hi,
>>
>> Thanks for reviewing.
>>
>>> On 30 Oct 2017, at 11:05, Dmitry Samersoff
>>&g
/bugs.openjdk.java.net/browse/JDK-8180413
>>
>>
> Can you bring this to serviceability-dev as that is the mailing list
> where the JDWP agent is maintained?
>
> -Alan
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
is one OS
>>>> page. So that subtracts another 192k, leaving us with 0k. The assert is
>>>> a by product of this.
>>>>
>>>> It turns out this pthread guard page problem is already fixed for all
>>>> java threads except the main thread. We do the f
/~xiaofeya/8169115/webrev.02/
>
> Thanks,
> Felix
> On 2016/12/6 19:16, Dmitry Samersoff wrote:
>> Felix,
>>
>> 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for
>> this test. Could we use different one (e.g. icann.org)
>>
>> 2.
t/~goetz/wr16/8170663-corlib_s11y/webrev.03/
>
> Best regards,
> Goetz.
>
>> -----Original Message-
>> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
>> Sent: Wednesday, December 07, 2016 2:43 PM
>> To: Lindenmaier, Goetz ; Jav
>>>
>>> Wrong destructor is used. Reported also by David CARLIER
>>>
>>>
>>> java.c
>>>
>>> in line 1865 'name' was used, it should be 'alias'.
>>>
>>>
>>> java_md_solinux.c
>>>
>>
e file is a horror.
-Dmitry
>
> Thanks,
> Goetz.
>
>> -Original Message-
>> From: David Holmes [mailto:david.hol...@oracle.com]
>> Sent: Wednesday, December 07, 2016 10:32 AM
>> To: Lindenmaier, Goetz ; 'Dmitry Samersoff'
>> ; Java Core L
t; == null.
>
>
> socket_md.c
>
> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in
> the macros.
>
>
> unpack.cpp
>
> n.slice should not get negative argument for end, which is passed from
> dollar1.
> But dollar1 can get negative where it is set to the result of
> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1).
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
following patch. It generally coverts codes from
> shell to plain java.
>
> Bug:
>
> https://bugs.openjdk.java.net/browse/JDK-8169115
>
> Webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/
>
> Thanks,
>
> Felix
>
--
Dmitry Sa
tchFirstBatch(stream, stackStream, mode, skip_frames,
> frame_count, start_index, frames_array, CHECK_NULL);
> +return fetchFirstBatch(stream, stackStream, mode, skip_frames,
> frame_count,
> + start_index, frames_array, THREAD);
>}
> }
>
> Thanks!
&g
> internal API from failurehandler lib?
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8166262
> webrev: http://cr.openjdk.java.net/~iignatyev/8166262/webrev.00/
>
> Thanks,
> — Igor
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would lov
Hello,
>>
>> I am sponsoring this changeset for Chris Bensen of the java packager
>> team, please review fix for the launcher to better locate java.home.
>>
>> http://cr.openjdk.java.net/~ksrini/8165524/
>>
>> Thanks
>> Kumar
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
.net/browse/JDK-8161360
> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8161360
>
> Thanks,
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
er
>> warnings. When compiled with warnings-as-errors, this results in
>> compilation failures.
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8161360
>> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8161360
>>
>> Thanks,
>>
>>
#
> @@ -391,9 +385,3 @@
> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370
> linux-i586,macosx-all
>
>
> -
> -# cor
*/
> -#define JVM_CLASSFILE_MAJOR_VERSION 52
> +#define JVM_CLASSFILE_MAJOR_VERSION 53
> #define JVM_CLASSFILE_MINOR_VERSION 0
>
> /* Flags */
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
ex] + slabindex;
>
> The rest looks fine.
>
> Thanks, Roger
>
>
>
>
> On 3/10/2016 7:59 AM, Thomas Stüfe wrote:
>
> Thank you Dmitry!
>
> I will fix the typo before comitting.
>
> Kind
entations subtly differ between
>> the three platforms, and solaris implementation is completely different. It
>> may be a worthwhile cleanup, but that would be a separate issue.
>>
>> I did some artificial tests to check how the code does with many and large
>> file descriptor values, all seemed to work well. I also ran java/net jtreg
>> tests on Linux and AIX.
>>
>> Kind Regards, Thomas
>>
>>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
> locking calls (in startOp and endOp). I doubt that a third mutex call
> will be the one making the costs suddenly unacceptable. Especially
> since they can be avoided altogether for low value mutex numbers (the
> optimization Roger suggested).
>
> I will do some performance tests and check whether the added locking
> calls are even measurable.
>
> Thomas
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
values less than 65535 and skip other machinery if
nbr_files.rlim_max less than 65536.
But it's just a cosmetic, so feel free to leave the code as is.
-Dmitry
On 2016-03-01 16:33, Thomas Stüfe wrote:
> Hi Dmitry,
>
> On Tue, Mar 1, 2016 at 1:44 PM, Dmitry Samersoff
> mailt
t think this would be optimized by
> inlining...
>
> Best regards
> Christoph
>
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net
> <mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Dmi
s
> called and I don't think this would be optimized by inlining...
>
> Best regards Christoph
>
> -Original Message----- From: core-libs-dev
> [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Dmitry
> Samersoff Sent: Dienstag, 1. März 2016 11:20 To: Thomas
as this is all in
> preparation for an IO system call, which are usually way more expensive
> than a pthread mutex. But again, this could be optimized.
>
> This is an implementation proposal for Linux; the same code found its way
> to BSD and AIX. Should you approve of this fix, I will m
mplementation and the JEP.
> The JEP will need to be updated. The most notable is the name of the package
> ("jdk" vs. the original "jdk.util"). The rename was recommended by Mark.
>
> Thanks,
> iris
>
> [0] http://openjdk.java.net/jeps/223
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
xplain little bit more about the problem that
> you mention it will be help full for me to debug further.
>
> Thanks,
> Vyom
>
>
> On Friday 18 December 2015 05:35 PM, Dmitry Samersoff wrote:
>> Vyom,
>>
>> If I read the changes correctly, current code returns
yom wrote:
>>> Hi All,
>>>
>>> Please review my changes for below bug.
>>>
>>> Bug: JDK-4823133 : RandomAccessFile.length() is not thread-safe
>>>
>>> Webrev:http://cr.openjdk.java.net/~vtewari/4823133/webrev0.0/
>>> <http://cr.openjdk.java
X:-MemberNameInStackFrame for the time being for the
> performance work to continue for JDK-8141239.
>
> Thanks
> Mandy
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
opy is available and you
can't request more than 256 bytes of entropy at once.
it might require changes in uplevel logic.
-Dmitry
On 2015-11-08 03:37, Wang Weijun wrote:
>
>> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff
>> wrote:
>>
>> Wang Weijun,
>>
re
> else? How do I detect it and what shall I do to avoid it?
>
> Thanks
> Max
>
> [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Staffan,
Could you review a CCC request.
http://ccc.us.oracle.com/8059036
-Dmitry
On 2015-06-05 15:24, Staffan Larsen wrote:
> Thanks - this version looks good to me.
>
> /Staffan
>
>> On 5 jun 2015, at 13:00, Dmitry Samersoff
>> wrote:
>>
>> Staffan,
&g
10d %s", count, name);
>}
> }
>
>
> A couple of nits:
>
> diagnosticCommand.cpp:359 - extra space after =
> diagnosticCommand.cpp:361 - spelling: finlalization -> finalization
> FinalizerInfoTest.java:69: - spelling: intialized -> initialized
> Finali
>> e.g. "dump"?
>>
>> The line in vmSymbols looks like:
>>
>> template(
>> get_finalizer_histogram_name, "getFinalizerHistogram")
>>
>> I would prefer to keep method name specific enough to be able to
>> find it by grep in
vmSymbols looks like:
template(
get_finalizer_histogram_name, "getFinalizerHistogram")
I would prefer to keep method name specific enough to be able to
find it by grep in jdk code.
(other comments are addressed)
-Dmitry
On 2015-06-03 21:36, Mandy Chung wrote:
>
>
> On 06/0
Everyone,
Updated webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.13
Changes to oop.inline.hpp is reverted and find_field used directly is
diagnostic command.
-Dmitry
On 2015-06-03 11:48, Dmitry Samersoff wrote:
> Everyone,
>
> Updated webrev:
09:06, Peter Levart wrote:
> Hi Dmitry,
>
> On 06/02/2015 01:12 PM, Dmitry Samersoff wrote:
>> Staffan,
>>
>>> Instead of hardcoding the field offsets, you can use
>>> InstanceKlass::find_field and fieldDescriptor::offset to find the
>>&g
> Hi Dmitry,
>
> On 2015-06-02 13:12, Dmitry Samersoff wrote:
>> Staffan,
>>
>>> Instead of hardcoding the field offsets, you can use
>>> InstanceKlass::find_field and fieldDescriptor::offset to find the
>>> offset at runtime.
>>
>> D
Klass::find_field and fieldDescriptor::offset to find the offset at
> runtime.
>
> Thanks,
> /Staffan
>
>> On 31 maj 2015, at 13:43, Dmitry Samersoff
>> wrote:
>>
>> Everyone,
>>
>> Please take a look at new version of the fix.
>>
>
ram?). Can you move
> this method to the end of this class and add the comment saying that
> this is invoked by VM for jcmd -finalizerinfo support and @return to
> describe the returned content. I also think you can remove
> @SuppressWarnings for this method.
>
> Mandy
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Hi Everybody,
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.09/
Please review updated webrev -
printFinalizationQueue now returns and array of Map.Entry
>> On May 19, 2015, at 11:51 PM, Dmitry Samersoff
>> mailto:dmitry.samers...@oracle.com>> wrote:
>>
>
On 2015-05-21 02:07, Mandy Chung wrote:
>
>> On May 19, 2015, at 11:51 PM, Dmitry Samersoff
>> mailto:dmitry.samers...@oracle.com>> wrote:
>>
>> Other alternatives could be to do all hashing/sorting/printing on native
>> layer i.e. implement printFinaliza
tput of this command
should be covered by GC tests, more complicated than this one, because
actual output depends to GC and heap parameters.
I can just check for presence of "Metaspace" world in the DCMD output.
-Dmitry
>
>
> /Staffan
>
>
>> On 18 maj 2015,
>
> On 05/20/2015 10:42 AM, Dmitry Samersoff wrote:
>> Peter,
>>
>>> What about creating a special package-private
>>> java.lang.ref.DiagnosticCommands class
>> I'm not quite happy with current printFinalizationQueue method - love to
>> have a way to
On 2015-05-20 11:22, Peter Levart wrote:
>
>
> On 05/20/2015 08:51 AM, Dmitry Samersoff wrote:
>> Mandy,
>>
>>> However I have trouble for
>>> Finalizer.printFinalizationQueue method that doesn’t belong there.
>>> What are the other alternatives you ha
implementation. Just to
> give you a quick comment. I’m okay to add ReferenceQueue.forEach method
> at the first glance. However I have trouble for
> Finalizer.printFinalizationQueue method that doesn’t belong there. What
> are the other alternatives you have explored?
>
> Mand
PM, Peter Levart wrote:
>>
>>
>> On 05/16/2015 09:35 AM, Dmitry Samersoff wrote:
>>> Derek,
>>>
>>> Personally, I'm for volatile over explicit fence too.
>>>
>>> So I'll change the code if Peter don't have objections.
>&
nQueue)... You could just expose
>>>>> a package-private forEach static method from Finalizer and code the
>>>>> rest in DiagnosticCommands.
>>>> That's good for encapsulation. But I'm concerned that if "forEach"
>>>> got ex
we know threads are "jumpy" so it will happen quite frequently that a
> poller jumps before scanner. So just giving-up when overtaken might
> return 0 or just a few elements when there are millions there in the
> queue. When scanner finally gets a head start, it will usually lead t
aken might
> return 0 or just a few elements when there are millions there in the
> queue. When scanner finally gets a head start, it will usually lead the
> race to the end.
>
> Peter
>
>>
>> Does this make more sense now?
>>
>> Regards, Peter
>&g
thological scenarios where this gets severe. This is
>> unfortunate but not uncommon. There is enough complication here that
>> you should be sure that the fix for diagnostics performance doesn't
>> introduce subtle bugs to the system in general. A change in this area
>&g
list may be interesting if one wants to know how many live +
>> finalization pending instances are there on the heap that override
>> finalize() method.
>>
>> Regards, Peter
>>
>>>
>>> For the output, it would be a nice touch to sort it on the numb
webrev will be closed as a duplicate
> of this bug (JDK-8074839).
>
> Cheers,
> Mikael
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8074096
> [2] http://cr.openjdk.java.net/~dsamersoff/JDK-8073175/webrev.01/
> [3] https://bugs.openjdk.java.net/browse/JDK-8073175
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
David at all,
May I consider the fix as reviewed and continue with integration?
-Dmitry
On 2015-02-24 05:23, David Holmes wrote:
> On 24/02/2015 12:02 AM, Dmitry Samersoff wrote:
>> Hi Everyone,
>>
>> Webrev updated in-place (press shift-reload)
>>
>> http://cr
(fstat(fd, &st) == -1)
> err(1, "fstat %s", argv[1]);
> size = st.st_size;
> if (size == 0)
> errx(1, "0 sized file");
>
> v = mmap(0, size, PROT_READ, MAP_FILE | MAP_PRIVATE, fd, 0);
> if (v
David,
On 2015-02-24 05:23, David Holmes wrote:
> On 24/02/2015 12:02 AM, Dmitry Samersoff wrote:
>> Hi Everyone,
>>
>> Webrev updated in-place (press shift-reload)
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
>
> share/native/libunpa
Hi Everyone,
Webrev updated in-place (press shift-reload)
http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
Updated formatting.
Hack in main.cpp replaced with true error check.
-Dmitry
On 2015-02-23 05:07, David Holmes wrote:
> On 21/02/2015 4:27 AM, Dmitry Samersoff wr
>>
>> + (void) (fread(&filecrc, sizeof(filecrc), 1, u.infileptr) + 1);
>>
>> UGH. What about other compilers are they ok with this ? This may very well
>> get suppressed for gcc, but might emit warnings on MSVC or SunStudio.
It works for all JDK compilers.
&
Hi Everyone,
It's my $0.02 to the warning cleanup work. Please review:
http://cr.openjdk.java.net/~dsamersoff/JDK-8073584/webrev.01/
Notes:
I use an ugly trick: (void) (read() + 1) to get rid of ignored value
warning because since gcc 4.6 just (void) is not enough.
-Dmitry
--
D
re-or-less portable) and size_t (perfectly portable,
more-or-less safe)
Use intptr_t everywhere but it costs explicit #ifdef __WINDOWS__ in
splashscreen_stubs.c
2.
I didn't fix "format not a string literal" warnings. It requires to set
per-compiler pragmas.
-Dmitry
--
Dmitry S
-less portable) and size_t (perfectly portable,
more-or-less safe)
So I use size_t in shared code, intptr_t in UNIX specific code.
2.
I didn't fix "format not a string literal" warnings. It requires to set
per-compiler pragmas.
-Dmitry
--
Dmitry Samersoff
Oracle Java development te
gt; I would like to contribute this patch.
> Please review and sponsoring.
>
>
> Thanks,
>
> Yasumasa
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
Please, file a separate issue.
--Dmitry
-Original Message-
From: Yasumasa Suenaga
To: Peter Allwin
Cc: Dmitry Samersoff ,
"core-libs-dev@openjdk.java.net" ,
"serviceability-...@openjdk.java.net"
Sent: Sat, 06 Sep 2014 19:37
Subject: Re: RFR: JDK-8057556: JDP
Looks good for me!
On 2014-09-04 19:59, Yasumasa Suenaga wrote:
> Hi all,
>
> Thank you so much, Dmitry!
>
> I've created webrev for it.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
>
> Please review.
>
>
> Thanks,
>
> Yasumasa
p;& nic.supportsMulticast()) {
> +try {
> +
> channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
> +} catch (IOException ex) {
> +System.err.println("WARNING: JDP broadcaster cannot
>
p; nic.supportsMulticast()) {
> +try {
> +
> channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
> +} catch (IOException ex) {
> +System.err.println("WARNING: JDP broadcaster cannot
> use " +
Magnus,
Not, we are not doing it now.
But we should consider doing it in a future and therefore keep it in
mind when designing option to choose debug symbol mode.
-Dmitry
On 2014-03-24 15:18, Magnus Ihse Bursie wrote:
> On 2014-03-21 10:36, Dmitry Samersoff wrote:
>>
>> (c) C
orting tu 8u.
>
> Thank you and best regards,
> Volker
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
hould be: full strip + copy-none + zip
-Dmitry
On 2014-03-21 15:13, David Holmes wrote:
> On 21/03/2014 7:36 PM, Dmitry Samersoff wrote:
>> David,
>>
>> In practice, we don't have to much to keep internally.
>>
>> There are no reason to copy out some of .d
ure?
>
> I think I already have. There aren't tree simple choices here, there are
> three aspects, each of which could have different variants.
>
> If I could draw a flow chart easily I would but basically if you
> generate debug symbols you can then select what symbols are kept
> internally (the strip policy) and what are put externally (objcopy
> options), then for the external symbol file you can choose zipped or
> unzipped.
>
> Multiple inter-connected choices, not just three (or four if you add
> zipped)
>
> David
>
>> /Magnus
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
Staffan,
OK!
-Dmitry
On 2014-02-07 19:49, Staffan Larsen wrote:
>
> On 7 feb 2014, at 16:24, Dmitry Samersoff wrote:
>
>> Staffan,
>>
>> FileInputStream.java
>>
>> 55: It's better to initialize path with null.
>
> I agree with Chris here.
On 2014-02-07 19:32, Chris Hegarty wrote:
> On 07/02/14 15:24, Dmitry Samersoff wrote:
>> Staffan,
>>
>> FileInputStream.java
>>
>> 55: It's better to initialize path with null.
>
> I'm afraid I disagree with this. The default value is already nul
ttp://cr.openjdk.java.net/~sla/8033917/webrev.00/ bug:
> https://bugs.openjdk.java.net/browse/JDK-8033917
>
> Thanks, /Staffan
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Staffan,
OK! Looks good for me.
-Dmitry
On 2014-02-07 15:28, Staffan Larsen wrote:
> I would prefer that to be a different change.
>
> Thanks,
> /Staffan
>
> On 7 feb 2014, at 12:07, Dmitry Samersoff wrote:
>
>> Staffan,
>>
>> As far as you touching t
e methods simplifies
> instrumentation.
>
> webrev: http://cr.openjdk.java.net/~sla/8033911/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8033911
>
> Thanks,
> /Staffan
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love
Changeset: 392acefef659
Author:dsamersoff
Date: 2013-10-19 20:59 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/392acefef659
8024071: In ManagementAgent.start it should be possible to set the jdp.name
parameter.
Summary: Pass one more property from Agent to JdpController
Rev
Changeset: 88436832cfd0
Author:dsamersoff
Date: 2013-10-19 00:05 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88436832cfd0
8004213: JDP packet needs pid, broadcast interval and rmi server hostname fields
Summary: Add some extra fileds to jdp packet
Reviewed-by: allwin, sla,
ava.net/~bpb/8010371/webrev.4-amendment/
>>>>
>>> I've restored the bug fields and I assume you'll create a new bug for the
>>> follow-up. Sorry this was missed in the original review (probably because
>>> it went through so many iterations).
>
is that winsock_errors dates from early
>> versions of Windows whether there wasn't a means to translate Windows
>> Sockets errors. We should look at eliminating it (not for JDK 8 of
>> course, it's too late) so that all errors are handle translated
>> consistently.
ror is only returned by WSAGetLastError?
>
> However I think we have a problem with using gai_strerror here as the
> MSDN documentation says that it is not thread safe. This means we may
> have to look for a WSA equivalent or maybe drop the Windows part of the
> fix (using a mutex
Changeset: 5d6dc0cba08f
Author:dsamersoff
Date: 2013-10-03 16:54 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d6dc0cba08f
8009213: sun/management/jdp/JdpTest.sh fails with exit code 1
Summary: There's no guarantee that the java process has executed far enough to
be found
> -Chris.
>
> On 10/03/2013 10:44 AM, Dmitry Samersoff wrote:
>> Chris,
>>
>> On my opinion, it's better to just return meaningful exception to
>> customer and let them deal with network issue (as current webrev does).
>>
>> Typical network failure
level until we get result
or timeout, but it requires much more work and probably out of scope of
this CR.
-Dmitry
On 2013-10-03 13:11, Chris Hegarty wrote:
> On 10/02/2013 11:18 PM, Dmitry Samersoff wrote:
>> Chris,
>>
>> I'm not sure immediate native retry ma
t;> javadoc?
>
> I don't think it is necessary for this to be documented. It is more
> informational.
>
> -Chris.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
>> https://bugs.openjdk.java.net/browse/JDK-8010371
>>
>> Webrev
>> http://cr.openjdk.java.net/~bpb/8010371
>>
>>
> So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and
> errno set to EAGAIN? I also wonder if the EAGAIN means the underlying
> syscall ha
wse/JDK-7200277
>
> Thanks,
> /Staffan
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.
Changeset: fce446b29577
Author:dsamersoff
Date: 2013-08-06 14:04 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fce446b29577
8011038: sourceObj validation during desereliazation of RelationNotification
should be relaxed
Summary: sourceObj could be set to null by setSource()
Changeset: df1b35c7901d
Author:dsamersoff
Date: 2013-06-05 18:20 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/df1b35c7901d
8015604: JDP packets containing ideographic characters are broken
Summary: Code uses string length rather than byte array length and non ascii
entry b
Changeset: 7d7bfce34a79
Author:dsamersoff
Date: 2013-05-28 18:46 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7bfce34a79
8014420: Default JDP address does not match the one assigned by IANA
Summary: JDP protocol defaults changed to IANA assigned values
Reviewed-by: dholme
omething else.
>>
>>
>>
>> To use this project (once pushed):
>>
>> 1. Clone your favorite repository
>> hg clone http://hg.openjdk.java.net/hsx/hotspot-gc
>>
>> 2. Get the whole forest
>> cd hotspot-gc
>> sh get_sourc
Jesper,
On 2013-03-25 22:35, Jesper Wilhelmsson wrote:
> Dmitry Samersoff skrev 25/3/13 6:11 PM:
>> Jesper,
>>
>> Tryed to apply your patch as I'm quite inetresting to have really
>> working NB project for jdk and hotspot.
>>
>> 1. Directory struct
sh configure
>
> 4. Open Solaris studio / NetBeans and load the project.
>The project in located in the common directory.
>
>
> Thanks,
> /Jesper
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
sh configure
>
> 4. Open Solaris studio / NetBeans and load the project.
>The project in located in the common directory.
>
>
> Thanks,
> /Jesper
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
Changeset: 8181be9a3538
Author:dsamersoff
Date: 2013-02-13 21:06 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8181be9a3538
8008095: TEST_BUG: JDK-8002048 one more testcase failure on Solaris
Summary: fixed couple of more Solaris shell incompatibilities
Reviewed-by: chegar
}
> fi
> @@ -319,7 +319,7 @@ rm -f ${_logname}
> rm -f ${_logname}
> rm -f ${_policyname}
>
> -if [ -e ${_testsrc}/policy.tpl ]
> +if [ -f ${_testsrc}/policy.tpl ]
> then
>
> cat ${_testsrc}/policy.tpl | \
>
> -Chris.
>
> On 12/02/2013 22:19, Dmitry
lasses}
> fi
> @@ -319,7 +319,7 @@ rm -f ${_logname}
> rm -f ${_logname}
> rm -f ${_policyname}
>
> -if [ -e ${_testsrc}/policy.tpl ]
> +if [ -f ${_testsrc}/policy.tpl ]
> then
>
> cat ${_testsrc}/policy.tpl | \
>
> -Chris.
>
> On 12/02/2013 22:19,
tcase doesn't work on Solaris
>> Summary: test built in into Solaris shell doesn't have -e operator
>> Reviewed-by: sla, sspitsyn
>>
>> ! test/sun/management/jdp/JdpTest.sh
>>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
jdk/rev/f7fb173ac833
>>>
>>> 8007786: JDK-8002048 testcase doesn't work on Solaris
>>> Summary: test built in into Solaris shell doesn't have -e operator
>>> Reviewed-by: sla, sspitsyn
>>>
>>> ! test/sun/management/jdp/JdpTest.sh
>>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
s.
>>
>>
>> On 02/12/2013 12:04 PM, dmitry.samers...@oracle.com wrote:
>>> Changeset: f7fb173ac833
>>> Author:dsamersoff
>>> Date: 2013-02-12 16:02 +0400
>>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833
>>>
&
Changeset: f7fb173ac833
Author:dsamersoff
Date: 2013-02-12 16:02 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7fb173ac833
8007786: JDK-8002048 testcase doesn't work on Solaris
Summary: test built in into Solaris shell doesn't have -e operator
Reviewed-by: sla, sspitsyn
!
1 - 100 of 123 matches
Mail list logo
