ords, is the disabled cost so vanishingly small that we need
> not think twice when using them, or should one be
> careful because the cost is non-negligible and can affect (bytecode)
> footprint or rutime performace even when switched off?
>
> thanks for any advice.
> -- ramki
am not very familiar with the APIs
in Mac OS X.
I have verified that the changes build on all platforms through
JPRT. The correctness has been verified manually by looking in
JConsole and running the tests in
test/java/lang/management/OperatingSystemMXBean
test/com/sun/management/OperatingSyste
Looks good for me.
-Dmitry
On 2012-04-11 20:24, Staffan Larsen wrote:
Apparently something went wrong with the webrev. Here is new one:
http://cr.openjdk.java.net/~sla/7147848/webrev.02/
Thanks Dmitry,
/Staffan
On 11 apr 2012, at 12:33, Dmitry Samersoff wrote:
Staffan
test currently loops
forever when running with the JDK with your patch. This test should be
able to run in samevm mode (other tests may run in the same VM with this
test) and the threads this test starts should be cleaned up before the
test exits.
Mandy
[1] http://openjdk.java.net/jtreg
--
Dmitry
way to fix this. No matter what you do
another thread can modify the system properties while you are iterating
them. Instead you need to anticipate the CME and try to recover from it
(also non-trivial).
Cheers,
David Holmes
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
Deven,
CR number is 7164191 .
Could you re-send me your original e-mail with problem description and
webrev link.
I'll put it to CR comment field.
-Dmitry
On 2012-04-24 16:15, Dmitry Samersoff wrote:
> Deven,
>
> After close look and off-line discussion with David Holmes,
t/~littlee/OJDK-256/webrev.00
> <http://cr.openjdk.java.net/%7Elittlee/OJDK-256/webrev.00>
>
> ------
>
>
> Thanks a lot!
>
>
>
> On 04/25/2012 08:32 PM, Dmitry Samersoff wrote:
>> Deven,
>>
>&
t/~littlee/OJDK-256/webrev.00
> <http://cr.openjdk.java.net/%7Elittlee/OJDK-256/webrev.00>
>
> ------
>
>
> Thanks a lo
Changeset: bf85c3ab2637
Author:dsamersoff
Date: 2012-08-09 14:52 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf85c3ab2637
7183753: [TEST] Some colon in the diff for this test
Summary: Reference output file contains extra colon
Reviewed-by: sspitsyn, mgronlun
! test/sun/to
gt;> use just use needsClassLoaderPermissionCheck(from,to).
>>
>
> Done. This is a good cleanup I considered to do too but missed in the
> previous webrev.
>
> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/
>
> Thanks for the review.
> Mandy
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
is it a known issue.
-Dmitry
On 2012-09-03 22:05, Alan Bateman wrote:
> On 03/09/2012 18:42, Dmitry Samersoff wrote:
>> Hi Everybody
>>
>> Q. Is it (below) known problem?
>>
>> Q. Does it make sense to turn deprecation warning off by default or at
>>
Changeset: 2598dad9
Author:dsamersoff
Date: 2012-09-11 19:58 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2598dad9
7194597: Typeo in com.sun.management.VMOption.toString()
Summary: VMOption.toString() returns "...(read-only)" if writable
"...(read-write)" otherwise
Changeset: 0c1c4b185451
Author:dsamersoff
Date: 2012-09-29 15:44 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c1c4b185451
7186723: TEST_BUG: Race condition in
sun/management/jmxremote/startstop/JMXStartStopTest.sh
Summary: Make test self-terminating and independent to cyg
Changeset: b2d8a99a049e
Author:dsamersoff
Date: 2012-10-17 18:34 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2d8a99a049e
6809322: javax.management.timer.Timer does not fire all notifications
Summary: Some notifications get dropped due to ConcurrentModificationException
t
Changeset: 887e525597f8
Author:dsamersoff
Date: 2010-06-23 17:25 +0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/887e525597f8
6931566: NetworkInterface is not working when interface name is more than 15
characters long
Summary: Separate Linux and Solaris code, use lifreq unde
Changeset: 25050030a320
Author:dsamersoff
Date: 2010-07-13 15:32 +0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25050030a320
6964714: NetworkInterface getInetAddresses enumerates IPv6 addresses if
java.net.preferIPvStack property set
Summary: User can disable ipv6 explicitly
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.
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,
>>
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.
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
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
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.
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
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
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
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
> 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.
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.
-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
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
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
>>
>> + (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,
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
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
(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 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
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.
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
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
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
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
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
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.
>&
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
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
>
> 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
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 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
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:
>>
>
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.
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.
>>
>
> 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
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
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:
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
>> 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
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
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
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
*/
> -#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.
#
> @@ -391,9 +385,3 @@
> com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370
> linux-i586,macosx-all
>
>
> -
> -# cor
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,
>>
>>
.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.
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.
> 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
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
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
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
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.
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
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.
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.
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
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.
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
p; nic.supportsMulticast()) {
> +try {
> +
> channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
> +} catch (IOException ex) {
> +System.err.println("WARNING: JDP broadcaster cannot
> use " +
p;& nic.supportsMulticast()) {
> +try {
> +
> channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
> +} catch (IOException ex) {
> +System.err.println("WARNING: JDP broadcaster cannot
>
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
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
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.
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
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.
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
>>>
>>> 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
>>>
>>
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
/~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.
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
/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.
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
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
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?
>>
Changeset: b600d490dc57
Author:dsamersoff
Date: 2012-12-20 16:02 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d490dc57
6783290: MBeanInfo/MBeanFeatureInfo has inconsistent readObject/writeObject
Summary: call readObject in all cases
Reviewed-by: emcmanus
Contributed-by:
Changeset: e43f90d5af11
Author:dsamersoff
Date: 2012-12-20 16:56 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e43f90d5af11
6937053: RMI unmarshalling errors in ClientNotifForwarder cause silent failure
Summary: the catch block in the fetchNotifs() method is extended to expe
Changeset: 3f014bc09297
Author:dsamersoff
Date: 2012-12-20 17:24 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f014bc09297
7009998: JMX synchronization during connection restart is faulty
Summary: add a return statement after the re-connecting has finished and the
state is
Changeset: c1a55ee9618e
Author:dsamersoff
Date: 2012-12-20 20:12 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1a55ee9618e
8005309: Missed tests for 6783290,6937053,7009998
Summary: Missed tests for 6783290,6937053,7009998
Reviewed-by: sjiang, emcmanus
Contributed-by: jaros
Changeset: 962d6612cace
Author:dsamersoff
Date: 2013-02-03 21:39 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/962d6612cace
8002048: Protocol to discovery of manageable Java processes on a network
Summary: Introduce a protocol to discover manageble Java instances across a
n
Changeset: 0e7d5dd84fdf
Author:dsamersoff
Date: 2013-02-06 16:53 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e7d5dd84fdf
8007277: JDK-8002048 testcase fails to compile
Summary: sun.* classes is not included to ct.sym file and symbol file have to
be ignored
Reviewed-by: a
Changeset: 1df991184045
Author:dsamersoff
Date: 2013-02-11 18:44 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1df991184045
8007536: Incorrect copyright header in JDP files
Summary: Copyright header in JDP files missed the "classpath exception" rule.
Reviewed-by: mikael
! s
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
!
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
>>>
&
1 - 100 of 123 matches
Mail list logo
