Re: Removal of SA javascript support

Hello Chris, I'm supporting you with this decision. PS: For people who want SA scripting - One thing I experimented with a long time ago - has been exporting of some SA capabilities to jython. This might be the way to go. -Dmitry On 11.12.19 05:52, Chris Plummer wrote: > Hi, > > I like to p

Re: Removal of SA javascript support

Sundar, Supporting hotspot data structure in SA is already a maintenance nightmare ;) So we can consider to provide high level API, like find_class_by_name to script writer. It allows anybody who are interesting with quick prototyping write his own program on top of SA with any language they w

Re: PING: RFR: 8234624: jstack mixed mode should refer DWARF

Hello Yasumasa, Please, 1. Consider to use mmap for reading elf sections. 2. Please move all platfrom-specific parts of native code to a separate file/directory. Current patch will brake AARCH64 build. 3. I didn't find any tests here. How did your test the changes? libproc_impl.c 131: If is

Re: jmx-dev RFR 8240604: Rewrite sun/management/jmxremote/bootstrap/CustomLauncherTest.java test to make binaries from source file

Hello Alexander, The fix looks good for me. -Dmitry On 05.03.2020 17:27, Daniel Fuchs wrote: Hi Alexander, Fixes to JMX & management agent are reviewed on the seviceability-dev (added in to:) these days. best regards, -- daniel On 05/03/2020 13:17, Alexander Scherbatiy wrote: Hello, Coul

RFR (S): JDK-8250630 JdwpListenTest.java fails on Alpine Linux

Hello Everybody, Please review the fix: https://cr.openjdk.java.net/~dsamersoff/JDK-8250630/webrev.01/ Binding to IN6ADDR_ANY allow us to serve both IPv4 and IPv6 connections, but binding to mapped INADDR_ANY (:::0.0.0.0) allow us to serve IPv4 connections only. So make sure, that IN6AD

Re: RFR (S): JDK-8250630 JdwpListenTest.java fails on Alpine Linux

at". A dot at the end of comment is missed. I don't know the network protocols well enough to comment on Thanks, Serguei On 8/17/20 00:21, Dmitry Samersoff wrote: Hello Everybody, Please review the fix: https://cr.openjdk.java.net/~dsamersoff/JDK-8250630/webrev.01/ Binding to IN6ADDR

Re: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash

se/nsk/jvmti/) > > A regression test may be possible if we call GetThreadGroupChildren in a > loop, whilst threads add and remove themselves from the group > concurrently. But it is awkward to write. > > Thanks, > David > > Thanks, > David -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... signature.asc Description: OpenPGP digital signature

Re: LingeredApp termination sequence

Hello Gary, The LingeredApp was designed to provide precise control over the life cycle of a subordinate process. This means that if the app exits unexpectedly, we should have detailed information why it happens. IOException may occur when the app tries to touch lockfile (e.g. due to a network f

Re: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

we should handle this situation (warning or error) and change the code, but I can add a plain printf() here if you like. > > + /* Interface version 1.0 doesn't support versioning, so we have to > + * use global variable and set the version artifically. > + * Use (*t)->extra_data

Re: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

extra communication step. IMHO, not obvious one. So I would prefer to keep StartListening11 -Dmitry On 2017-05-10 12:37, serguei.spit...@oracle.com wrote: > Dmitry, > > Thank you a lot for the detailed reply! > > > On 5/10/17 01:10, Dmitry Samersoff wrote: >> Serg

Re: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

looked at it but will not provide my comments at this point. We >> will need another update according to the recent design review and >> items where we still have to reach an agreement. >> >> Thanks, Serguei >> >> >> On 5/10/17 08:27, Dmitry Samersoff wrote: &

Re: RFR(M): JDK-8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

mpiled client against JDK 8 headers works without > recompiling with a JDK 9 runtime. > To make really future proof; using a client compiled against JDK 9 with > JDK 1X you will need some way to know witch version of the struct was used. > > E.g. SetTransportConfiguration(&con

Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

/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.

Re: RFR: JDK-6760477 - Update SA to include stack traces in the heap dump

> > Bug:https://bugs.openjdk.java.net/browse/JDK-6760477 > > Webrev: http://cr.openjdk.java.net/~sballal/6760477/webrev.00/ > > > > > > Thanks & Regards, > > Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java develo

Re: RFR(M): 8061228 Allow JDWP socket connector to accept connections from certain ip addresses only

Serguei, The changes looks good to me. Thank you for doing it. -Dmitry On 23.08.2017 23:59, serguei.spit...@oracle.com wrote: > Added Dmitry's email address to the list as he is not subscribed on the > serviceability-dev. > > Thanks, > Serguei > > > On 8/22/17 16:22, serguei.spit...@oracle.c

Re: RFR: SA: MacOS X: 8184042: several serviceability/sa tests timed out on MacOS X

Jini, 1. As a quick fix we probably can disable deprecation warning, i.e. add something like #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wdeprecated-declarations" ... #pragma clang diagnostic pop around offending code. 2. As a long term your fix looks reasonable for me, but

Re: RFR(10)(M): 8179498: attach in linux should be relative to /proc/pid/root and namespace aware

Chris, > So now .attach_pid is always created in cwd as you can see in > createAttachFile(), although AttachListener::is_init_trigger() does > check tmp, but only after cwd. > ***getNamespacePid - ns_pid: 125 > ***findSocketFile - f: /proc/24445/root/tmp/.java_pid125 > ***createAttachFile - path:

Re: RFR(L): 8049716: PPC64: Implement SA on Linux/PPC64

;>>>>> read >>>>>>>> #if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>>> instead of just >>>>>>>> #if defined(ppc64) >>>>>>> Hi, Alexander, >>>>>>> I think this is actually fine everywhere except one place. The 'opd' >>>>>>> variable will be >>>>>>> set to something other than NULL at line 379 only if running on ppc64 >>>>>>> BE. So in >>>>>>> the rest of that function, opd is checked for non-null before using it. >>>>>>> The only >>>>>>> place where I think there may be a problem is at line 455: >>>>>>> >>>>>>> -- >>>>>>> #if defined(ppc64) >>>>>>> // On Linux/PPC64 the debuginfo files contain an empty file descriptor >>>>>>> // section (i.e. '.opd' section) which makes the resolution of symbols >>>>>>> // with the above algorithm impossible (we would need the have both, >>>>>>> the >>>>>>> // .opd section from the library and the symbol table from the >>>>>>> debuginfo >>>>>>> // file which doesn't match with the current workflow.) >>>>>>> if (false) { >>>>>>> #else >>>>>>> // Look for a separate debuginfo file. >>>>>>> if (try_debuginfo) { >>>>>>> #endif >>>>>>> -- >>>>>>> >>>>>>> Here I think we should do as you suggest: >>>>>>>#if defined(ppc64) && !defined(ABI_ELFv2) >>>>>>> >>>>>>> -Maynard >>>>>>>> >>>>>>>> Sorry for the late notice. >>>>>>>> Sasha >>>>>>>> >>>>>>>> On Thu, Dec 4, 2014 at 9:50 AM, Volker Simonis >>>>>>>> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'd like to submit this webrev which adds support for the SA agent on >>>>>>>>> Linux/PPC64 on behalf of Maynard Johnson who is the main author of the >>>>>>>>> change: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~simonis/webrevs/8049716 >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8049716 >>>>>>>>> >>>>>>>>> I have already reviewed and tested the change and from my side >>>>>>>>> everything looks fine. >>>>>>>>> >>>>>>>>> The change touches quite some shared code but all of these changes are >>>>>>>>> trivial and straight-forward (i.e. they just add Linux/PPC64 support >>>>>>>>> with the help of '#ifdef's in C or yet another 'elseif' clause in >>>>>>>>> Java). >>>>>>>>> >>>>>>>>> We need a second reviewer and a sponsor who can push this to the >>>>>>>>> hotspot repository once the review is completed. >>>>>>>>> >>>>>>>>> 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. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR 8066708: JMXStartStopTest fails to connect to port 38112

g the "right" delay time is very difficult. But > it does strengthen this conjecture in my mind. > > Naturally it would be better if there were a way to determine when a > port is available for reuse without actually opening it. I'm not aware > of any such way,

Re: RFR(S): backport 8039995 and 8061785 changes to SA testcase

ted from: > > 8039995 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/da92e4c42b24 > > 8061785 > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/raw-rev/3cdb9f480a8c > > > Thanks! > Kevin > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russ

Re: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved

Looks good for me (not a reviewer). --Dmitry -Original Message- From: Alexander Kulyakhtin To: serviceability-dev@openjdk.java.net Cc: "Dmitry Михайлович Samersoff" , Serguei Vladimirovich Spitsyn Sent: Wed, 24 Dec 2014 17:32 Subject: Review request JDK-8068242: quarantine the test

Re: Review request JDK-8068242: quarantine the test IsModifiableClassAgent.java until JDK-8068162 is resolved

K-8068242 > webrev: > http://cr.openjdk.java.net/~eistepan/~akulyakhtin/8068242/webrev.00/ > > @ignore JDK-8068162 added to the test to have it > ignored until JDK-8068162 is resolved > > Thanks, > Alexander > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR 8066708: JMXStartStopTest fails to connect to port 38112

Jaroslav, It might be better to just choose a random digit between 49152–65535 and attempt to use it. -Dmitry On 2014-12-18 17:29, Jaroslav Bachorik wrote: > On 12/11/2014 03:43 PM, Dmitry Samersoff wrote: >> Jaroslav, >> >> You can set SO_LINGER to zero, in this case

Re: RFR 8066708: JMXStartStopTest fails to connect to port 38112

the state that prevents the > port from being reused immediately is private to the kernel and cannot > be observed from a user process, at least not without attempting to > reopen the socket. > > Side note: one of the jcmd() overloads says that parameter 'c' (a > Consumer

RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData

Hi Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ The fix explicitly checks for UsePerfData and if it's false make Perf:detach a NOP. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to c

Re: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData

nks, > David > > On 12/01/2015 11:49 PM, Dmitry Samersoff wrote: >> Hi Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-7076820/webrev.01/ >> >> The fix explicitly checks for UsePerfData and if it's false

Re: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData

Any other reviewers? -Dmitry On 2015-01-13 08:10, David Holmes wrote: > Hi Dmitry, > > Short version: okay but I'm going to file a bug to have sun.misc.Perf > fixed properly. > > Long version ... read below :) > > Thanks, > David > > On 12/01/2015 1

Re: RFR(S): JDK-7076820 assert(addr != 0) failed: address sanity check in PerfMemory::detach with -XX:-UsePerfData

David, Thank you! -Dmitry On 2015-01-16 09:36, David Holmes wrote: > On 13/01/2015 7:00 PM, Dmitry Samersoff wrote: >> David, >> >> On 2015-01-13 08:10, David Holmes wrote: >>> >>> Short version: okay but I'm going to file a bug to have sun.misc.

Re: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root

cr.openjdk.java.net/~miauno/8044419/webrev.01 > > Tested as non-root on all platforms except embedded. > Tested as root on linux. > > Thanks, > Mattias > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root

ile. Then >> we will get the error message. >> >> I could add a log that says the error message is expected. >> And I can change the second "grep" to your suggestion. >> >> Mattias >> >> On 01/19/2015 04:13 PM, Dmitry Samersoff wrote: >>&

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

David, Please, take a look at updated webrev http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.03/ -Dmitry On 2014-10-16 16:07, David Holmes wrote: > Hi Dmitry, > > On 16/10/2014 8:08 PM, Dmitry Samersoff wrote: >> David, >> >> Changed. Thank you fo

Re: RFR(S): 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root

; > > On 01/21/2015 12:56 PM, Dmitry Samersoff wrote: >> Mattias, >> >> 1. mkFiles at ll. 215 above is reluctant >> >> 2. if you wish to store id output and grep the file it's better to do >> something like: >> >> id > $HOME/jdb.ini &g

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

execute the END_WITH_LOCAL_REFS before you can return? > > Otherwise seems okay. > > Thanks, > David > >> -Dmitry >> >> >> On 2014-10-16 16:07, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 16/10/2014 8:08 PM, Dmitry Samers

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

EFS(env);" >> before the line 50. >> >> src/jdk.jdwp.agent/share/native/libjdwp/commonRef.c >> 159 * It never throws OOM >> >> Minor: Could you, please, add a dot at the end of the comment statement? >> >> No need to re-review after the

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

David, Agree! Will change it. -Dmitry On 2015-01-29 10:26, David Holmes wrote: > On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >> David, >> >>> Don't you need to execute the END_WITH_LOCAL_REFS before you can return? >> >> done. >> >> http

Re: RFR(S): JDK-8030708: warnings from b119 for jdk/src/share/back: JNI exception pending

David, Fixed in place (press shift-reload) http://cr.openjdk.java.net/~dsamersoff/JDK-8030708/webrev.04/ -Dmitry On 2015-01-29 10:26, David Holmes wrote: > On 29/01/2015 12:00 AM, Dmitry Samersoff wrote: >> David, >> >>> Don't you need to execute the END_WITH_LOC

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

m.hotspot.tools.DumpJFR > > JPRT tests in progress. > > Thanks, > Jiangli > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR 8071962 The SA code needs to be updated to support Symbol lookup from the shared archive

;>>>> symbols in shared archive. The shared symbols are stored separately from >>>>>> the regular symbol table. The VM looks up both tables when searching for >>>>>> existing symbol at runtime. The SA code needs to do the same when >>>>

Re: RFR 8066708: JMXStartStopTest fails to connect to port 38112

;c' (a >> Consumer) may be null. It doesn't look like this is handled. If you >> really want to support this, I'd assign () -> { } to it if it's null so >> that it can be called unconditionally. (Or just disallow null.) > > I've changed the Por

RFR(S, testonly): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting

ls to have better diagnostic in case of a fail 3. The test kept disabled on Mac OS X until the problem with attach permissions for non-root users is solved. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won'

Re: RFR(S, testonly): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting

Staffan, Are you OK to push the changes? -Dmitry On 2015-02-03 16:01, Dmitry Samersoff wrote: > Everyone, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8072395/webrev.01/ > > 1. I was wrong in my assumption that the test can't run more

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

This change fixes it at least partially. It may not be the > cleanest way to support default methods but it already proved useful > when investigating a compiler crash so unless someone has a better fix > I would like to push it. > > http://cr.openjdk.java.net/~roland/8071999/webrev.

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

uick workaround it may be okay but it appears that SA is seriously > lagging in its language support. :( > > Cheers, > David > >> Roland. >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match

mitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match

> /Staffan > >> On 10 feb 2015, at 16:39, Dmitry Samersoff >> wrote: >> >> Hi Everyone, >> >> Please review the changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8072835/webrev.01/ >> >> if maximum heap size is not specif

Re: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match

Staffan, OK. Will do. -Dmitry On 2015-02-10 22:59, Staffan Larsen wrote: > >> On 10 feb 2015, at 20:52, Dmitry Samersoff >> wrote: >> >> Staffan, >> >>> I don’t think you need to respect -Xmx if it set from outside. >> >> Embedded syste

Re: RFR(S, testonly): JDK-8072835 sun/tools/jmap/heapconfig/JMapHeapConfigTest.java Key MaxHeapSize doesn't match

Staffan, Changed in-place (press shift-reload) -Dmitry On 2015-02-10 22:59, Staffan Larsen wrote: > >> On 10 feb 2015, at 20:52, Dmitry Samersoff >> wrote: >> >> Staffan, >> >>> I don’t think you need to respect -Xmx if it set from outsid

RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting

. Testlibrary method canPtraceAttachLinux refactored, fixed yama ptrace_scope check. 4. Sync Platfrom.java in hotspot and jdk testlibraries -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR(M): JDK-8072395: LingeredAppTest.java and JMapHeapConfigTest.java fail due to LingeredApp ERROR: java.io.IOException: Lock is too old. Aborting

other tests I think that know they aren't going to work, just print >> a message and return from main, they don't count this as a failure. >> I'll leave that for you to decide!... >> >> Thanks Kevin >> >> >> On 11/02/2015 10:41, Dmitry Sam

Re: Review request: Backport of JDK-8046282 to 8u

t/~poonam/8046282/webrev.00/ > > Thanks, > Poonam > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: gdb and OpenJDK

ong term. I've been discussing this with Red Hat's GDB > group and I'm hoping to come up with a proposal and hopefully some > working code. > > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR(S): 8073042: jcmd hangs until another jcmd is executed (which, in turn, also hangs) (on Windows)

perations manage to get enqueued, but not processed until > another thread eventually signals the semaphore by posting another op. > > We must allow the semaphore to stay signaled when multiple ops are enqueued - > and since we only allow preallocate_count number of operations to b

Re: RFR: 8073688: Infinite loop reading types during jmap attach.

reate that > symlink, but the tools need to protect themselves from this kind of > problem. > > Testing was manual. > > bug > https://bugs.openjdk.java.net/browse/JDK-8073688 > > webrev > http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/ > > Thanks > Kevi

Re: RFR: Resolve disabled warnings for the JVMTI demos

074842 > webrev: http://cr.openjdk.java.net/~sla/8074841/webrev.00/ > > 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.

RFR(S, TEST) JDK-8075569: jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906081d-06bc-4738-a7e8-f37b8bf13658.lck

Hi Everyone, Please review small, test only fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8075569/webrev.01/ Lock deleted while we are setting last modified time. Ignore error and lets the app exits -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I

Re: RFR(S, TEST) JDK-8075569: jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906081d-06bc-4738-a7e8-f37b8bf13658.lck

Alan, Thank you for the review. I agree that File.exists is no longer required, but I would prefer to keep it for better readability. -Dmitry On 2015-03-21 13:57, Alan Bateman wrote: > On 21/03/2015 10:50, Dmitry Samersoff wrote: >> Hi Everyone, >> >> Please review

RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect

Everybody, Please review a small fix. The fix goes to 9 and 8u at the same time. http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give m

Re: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect

David, On 2015-04-02 14:45, David Holmes wrote: > Hi Dmitry, > > On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review a small fix. >> >> The fix goes to 9 and 8u at the same time. >> >> http://cr.openjdk.java.net

Re: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect

Fix updated. On 2015-04-02 15:05, Dmitry Samersoff wrote: > David, > > > On 2015-04-02 14:45, David Holmes wrote: >> Hi Dmitry, >> >> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review a small fix. >&g

Re: RFR(S): JDK-8068007 [Findbugs] SA com.sun.java.swing.action.ActionManager.manager should be package protect

Jaroslav, Thank you! -Dmitry On 2015-04-02 15:45, Jaroslav Bachorik wrote: > On 2.4.2015 14:35, Dmitry Samersoff wrote: >> Fix updated. > > I like this better. Still rather convoluted but it seems to be as good > as we can get without a bigger rewrite. > > I'm ok

RFR(XS): JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect

Everybody, Please review a small fix: The fix goes to 9 and 8u at the same time. http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give m

Re: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect

Everybody, Please, review updated webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/ Fixed a compilation error that wasn't caught during incremental build. -Dmitry On 2015-04-02 15:54, Dmitry Samersoff wrote: > Everybody, > > Please review a small fix: >

Re: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect

n the > agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java > > +public static Dimension getButtonPrefSize() > +{ > +return buttonPrefSize; > +} > > => > > +public static Dimension getButtconPrefSize() > +{ > +return buttconPr

Re: RFR(XS)v2: JDK-8067991 [Findbugs] SA com.sun.java.swing.ui.CommonUI some methods need final protect

Serguei, Thanks! -Dmitry On 2015-04-04 11:58, serguei.spit...@oracle.com wrote: > Dmitry, > > I think, no re-review is necessary after fixing this typo. > You had addressed the review comments. > > Thanks, > Serguei > > On 4/4/15 12:06 AM, Dmitry Samersoff wrote:

Re: Unable to create hprof heap dump from core file with jmap on Oracle Solaris

cle Solaris 10 8/11 s10s_u10wos_17b SPARC > Oracle Solaris 11.1 X86 > Oracle Solaris 11.2 X86 > > I found a similar issue in the JDK bug system (JDK-8044416), but the > last update there stated that JDK-8044416 "is about the -F > functionality" and to "pl

RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda

mitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR(S): JDK-8044416 serviceability/sa/jmap-hashcode/Test8028623.java fails with AssertionFailure: can not get class data for java/lang/UNIXProcess$Platform$$Lambda

Jaroslav, Thank you! Nits fixed in-place (press shift-reload) -Dmitry On 2015-04-09 19:12, Jaroslav Bachorik wrote: > Hi Dmitry, > > Indentation should be 4 spaces. > Copyright year will need update. > > Otherwise looks good! > > -JB- > > On 9.4.2015

Re: RFR(S): 8077832: SA's dumpreplaydata, dumpcfg and buildreplayjars are broken

Roland, Looks good to me. -Dmitry On 2015-04-15 12:48, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8077832/webrev.00/ > > I found 3 locations where the SA code is out of sync with the hotspot code. > > Roland. > -- Dmitry Samersoff Oracle Java devel

RFR(S): JDK-8074146 jdb has succeded to read an unreadable file

verify the read fails" So I decide to go with the surgery rather than a therapy and cut out this test case entirely. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR: 8078519 Can't run SA tools from a non-images build

("sa.properties"); >> + if (VM.class.getClassLoader() == null) { >> + url = ClassLoader.getSystemResource("sa.properties"); >> + } >> + else { >> + url = VM.class.getClassLoader().getResource("sa.properties");

Re: sun/jvm/hotspot/oops/Symbol.java

._symbol_mask)); >} > > I'm not at all sure this is the right place to fix it, but it works. > > I'm just really surprised no-one noticed this before. > > Andrew. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

RFR(M): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Everyone, Please review the fix: http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.01/ heap dcmd outputs the same information as SIGBREAK finalizerinfo dcmd outputs a list of all classes in finalization queue with count -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint

Re: PING Re: RFR: 8078521: AARCH64: Add AArch64 SA support

uldn't be controversial at this point. > > Thanks, > Andrew. > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR: 8079360 AttachProviderImpl could not be instantiated

t; exception if something like this happens again. > > webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8079360 > > Thanks, > /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I woul

Re: 8079200: Fix heapdump tests to validate heapdump after jhat is removed

; The fix makes sure the HprofParser is available for all types of test > frameworks, not only JTreg. It will be a part of test-lib.jar. > > Thanks, > Katja > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: PING Re: RFR: 8078521: AARCH64: Add AArch64 SA support

public -Dmitry On 2015-05-06 17:36, Andrew Haley wrote: > On 04/29/2015 08:42 AM, Andrew Haley wrote: >> >> http://cr.openjdk.java.net/~aph/8078521-2/ > > Any news on this? It shouldn't be controversial at this point. > > Thanks, > Andrew. > >

Re: RFR(S): 6755586: Test com/sun/jdi/NoLaunchOptionTest.java may erroneously fail

bug is actually already solved. But I'll use it as an opportunity > to re-write the test using test library. There is no need to retrieve a > free port since the error occurs before binding to the address. > > Thanks, > Katja -- Dmitry Samersoff Oracle Java development team

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR[ 9u-dev] JDK-8075773 - jps running as root fails with 7u75, works fine with 7u72

njdk.java.net/browse/JDK-8075773. I have built and > tested JDK9 with fix successfully. As I do not have an account for OpenJDK, > David Buck will push the fix into jdk9/hs-rt/. > > Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.01/ > > Regards, > Cheleswe

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M,v6): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: PING Re: RFR: 8078521: AARCH64: Add AArch64 SA support

SS_SIZE 69,73 - please, remove space after bracket. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.

Re: RFR[ 9u-dev] JDK-8075773 - jps running as root fails with 7u75, works fine with 7u72

): >>> >>> - to process directory entries in a directory that is writable >>> which makes this use subject to a symlink or hard link attack. >>> - to process directory entries in a directory that the calling >>> user does not own; the intent of the

Re: RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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. >&

Re: PING Re: RFR: 8078521: AARCH64: Add AArch64 SA support

Andrew, Looks good for me. (not a Reviewer) > This will now enable the code for PPC; I guess that's OK. I think so too. -Dmitry On 2015-05-19 18:20, Andrew Haley wrote: > On 05/16/2015 06:03 PM, Dmitry Samersoff wrote: >> Andrew, >> >> On 2015-05-12 20:05,

Re: RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

> > 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

Re: RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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,

Re: RFR(M,v7): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M,v9): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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: >> >

Re: RFR(S): 8081037: serviceability/sa/ tests time out on Windows

dlock." > > The solutions is to start a separate target process. Dmitry Samersoff > has already created a test application for such cases so I've decided to > move it on the top level library instead of duplicating it. The test > application will reside under test/lib/sha

Re: RFR(M, v10): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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.

Re: RFR(M, v11): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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. >> >

Re: RFR(M, v11): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

> 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

Re: RFR(M, v12): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

Re: RFR(M, v13): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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:

Re: RFR(M, v14): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

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

  1   2   3   4   5   6   7   8   9   >