Re: 8234624: jstack mixed mode should refer DWARF

Just a wild guess, but maybe after your changes, the debug symbols are required and not found any more? This could be caused by the fact that Mach5 builds with different settings compared to you? See https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html#native-debug-sy

Re: serviceability agent : problems when using gcc LTO (link time optimization)

SA pretends to know the exact types of objects in the JVM and for polymorphic objects it wants to read their vtable from the shared library. If LTO de-virtulizes methods and thus changes polymorphic to non-polymorphic types, this won't work. But if LTO can de-virtulizes a type, maybe you can do tha

Re: serviceability agent : problems when using gcc LTO (link time optimization)

While we are speaking about all the drawbacks of LTO, it's still not clear what the benefits are? In the very first mail Matthias mentioned that there might be performance improvements but that performance is not the main driving factor behind this initiative. So is it the reduced code size (Matthi

Re: serviceability agent : problems when using gcc LTO (link time optimization)

cause it is C++ ? > > > > > > So for some libs you see 10% and more , but not for all . But most > large libs like libjvm.so, libfontmanager.so or liblcms.so > we see good results regarding reduced code size. > > > > I Cannot say much about p

Re: RFR (S): 8245129: Enhance jstat gc option output and tests

Hi Paul, thanks for fixing jstat for larger heaps. I like that you've added explicit tests for ParallelGC which hasn't been tested since G1 was made the default collector. I also agree that sizes should all be right justified. I only wonder if the header of a right justified column shouldn't be r

Re: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

On Wed, Aug 19, 2020 at 6:17 PM Hohensee, Paul wrote: > > Please review this backport to jdk8u. I especially need a CSR review, since > the CSR approval process can be a bottleneck. The patch significantly reduces > fleet profiling overhead, and a version of it has been in production at > Amazo

Re: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

Allow com.sun.management to be in a different module to java.lang.management" in jdk9. In jdk8 all the functionality is in "management/management.h" so there's no need to backport the changes from "management_ext.c" . [1] https://bugs.openjdk.java.net/browse/JDK-8042901 > Th

Re: RFR/RFA (M): 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument

: > > Hi Paul, > > Sorry, Volker, for using this "indirection". > I hope, Paul redirected my "Hi" to you. :) > > Thanks, > Serguei > > > > > Thank you for explanation. > > > > Thanks, >

Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

Looks good to me. Thanks, Volker On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz wrote: > Hi Gary, > > as promised, I'll do a follow up fixing all these. > But all the tests you mention are either not configured for aix (@requires > linux etc) > or are passing currently. So no need for acti

Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

03/ > > ... and I'll update the copyrights before pushing ... > > Sorry for the inconvenience! > Goetz > > > -Original Message- > > From: Volker Simonis > > Sent: Donnerstag, 3. Januar 2019 09:50 > > To: Lindenmaier, Goetz > > Cc: gary.ad

Re: RFC (csr): 8221528: Introduce compatibility mode with VM option -XX:AllowRedefinitionToAddOrDeleteMethods

Hi Serguei, can you please detail a little bit on the reasons why you finally decided to change the implementation to conform to the spec instead of just updating the spec to endorse a behavior which is there since quite some time? I read trough the comment thread of "JDK-8192936" and it seems to

Re: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64

Hi Jc, from the perspective of the ppc64 and s390 port it is OK to exclude the two platforms from the test. When we will fix AGCT on the two platforms we will update the tests. Thanks, Volker On Thu, May 16, 2019 at 4:57 AM Jean Christophe Beyler wrote: > > Hi both, > > For the linux question,

Re: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd

Hi Alan, you may be right that the initial submitter and reviewers have missed the need of a CSR, but after all, the change itself has been correctly reviewed on serviceability-dev by your colleague Chris Plummer and my colleague Christoph Langer. I think it is a little exaggerated to claim the ba

Re: Slow class loading when running JVM in debug mode

Hi Egor, yes, I‘d say this is something well known. The reason for this is that a debugging agent will request some JVMTI capabilities like "can_access_local_variables" which can only be requested at JVM startup. However, once these capabilities have been taken, certain kinds of optimizations like

Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

Looks good, but don't we also need this for getIntValue() as well? I.e. can't an integer be "1.234.678" (German style) as well as "1,234,678" (American style) for example ? Thanks, Volker On Mon, Jul 24, 2017 at 9:07 AM, Lindenmaier, Goetz wrote: > Hi, > > > > Some tests use Float.valueOf for St

Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

ell. Regards, Volker > Best regards, > Goetz. > >> -Original Message- >> From: Volker Simonis [mailto:volker.simo...@gmail.com] >> Sent: Thursday, July 27, 2017 11:49 AM >> To: Lindenmaier, Goetz >> Cc: serviceability-dev (serviceability-dev@openjdk.java.

Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

ile because the tests didn't run > nightly): > http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.02/ > > Best regards, > Goetz. > >> -Original Message- >> From: Volker Simonis [mailto:volker.simo...@gmail.com] >> Sent: Freitag,

Re: 8u: RFR(S): 8197943: Unable to use JDWP API in JDK 8 to debug JDK 9 VM

Hi Christoph, I think the new code is wrong for "jdwpMajor == 0", which was correctly handled before. But I'm not sure if that is relevant at all nowadays and taking into account that this is a verbatim downport from 9 I don't think we have to do better in 8u. Otherwise looks good from my side.

Re: RFR: JDK-8200178 Remove mapfiles for JDK native libraries

Hi Magnus, thanks for addressing this long standing issue! I haven't looked at the changes, but just want to share some general and historical notes: - Compiling with "-fvisibility=hidden" which hides all symbols expect the ones explicitly exported with "__attribute__((visibility("default")))" ha

Re: RFR(xxxs): 8203014: jcmd should output command list if no command is given

Hi Thomas, I think the request sounds reasonable and the change looks good. @David: why should this require a CSR request? I don’t see that the behavior for bad command line flags is specified somewhere. So we’re changing an undocumented behavior into o more meaningful undocumented behavior. Reg

Re: [URGENT] RFR: 8205096: Add missing files for 8203394

Can't comment on the content, but at least it fixes the build so thumbs up from me! Regards, Volker On Fri, Jun 15, 2018 at 11:16 AM, serguei.spit...@oracle.com wrote: > Please, review a fix for: > https://bugs.openjdk.java.net/browse/JDK-8205096 > > Webrev: > > http://cr.openjdk.java.net/~ss

Re: RFR (S) 8205608: Fix 'frames()' in ThreadReferenceImpl.c to prevent quadratic runtime behavior

Hi Sergey, thanks for your help, but I've just pushed the fix now. @Thomas: sorry, I really apologize, but I've just realized that I've forgot to add you as a Reviewer :( I'll promise to look more carefully next time. Regards, Volker On Tue, Jul 24, 2018 at 6:01 PM, serguei.spit...@oracle.com

Re: RFR (S) 8205608: Fix 'frames()' in ThreadReferenceImpl.c to prevent quadratic runtime behavior

Oh my good! And I've also forgot to add Ralf as a Contributer :(:(:( I really desperately need a vacation! Sorry Ralf, Volker On Thu, Jul 26, 2018 at 11:36 AM, Volker Simonis wrote: > Hi Sergey, > > thanks for your help, but I've just pushed the fix now. > >

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

DEBUG = ... > 43 } > > > 60, 61 extra space before = > > 147 missed {} after if (DEBUG) > Done. > * agent/src/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java > > 49 - 61, please fix extra and missed spaces > > 64,67 - extra spaces after sta

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

fan > >> On 17 dec 2014, at 19:06, Dmitry Samersoff >> wrote: >> >> Volker, >> >> The changes looks good for me and I'll sponsor the push. >> >> But please check, whether you need one more reviewer or not. >> >> -Dmitry >> >

Change "8057744: (process) Synchronize exiting of threads and process [win]" breaks HotSpot on Win Server 2003

Hi Ivan, I have just realized that the change 8057744 breaks HotSpot on Windows Server 2003 because the InitOnceExecuteOnce function isn't supported there. I suppose you're aware of this as the change contains the following comment in os_windows.cpp: // Must be at least Windows Vista or Server 20

Re: gdb and OpenJDK

Hi Jeremy, nice to see that somebody is working on this topic. Can you please detail a little bit on how this would work? As far as I understand you extend gdb to support "frame undwinder" plugins written in Python. One of these plugins, which you want to contribute to the OpenJDK, can be used t

Re: gdb and OpenJDK

Hi everybody, I really don't want to prevent the "Good Enough" solution and as far as I understand, this solution doesn't require any code changes to HotSpot, right? It will just add an additional Python artifact to the OpenJDK delivery which will be used by gdb. But in general I have to agree wi

RFR(XS): 8071687: AIX port of "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework"

Hi, can I please have a review for this AIX-only change. It is an exact copy of the changes done in "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework" into the corresponding AIX files. http://cr.openjdk.java.net/~simonis/webrevs/2015/8071687 https://bugs.o

Re: RFR(XS): 8071687: AIX port of "8039173: Propagate errors from Diagnostic Commands as exceptions in the attach framework"

No problem:) Thanks for the review, Volker On Tue, Mar 17, 2015 at 7:55 PM, Staffan Larsen wrote: > Looks good to me. Sorry I didn’t do those changes as well. > > /Staffan > >> On 17 mar 2015, at 18:40, Volker Simonis wrote: >> >> Hi, >> >> can I ple

RFR(XS): 8079510: AIX: fix build after '8042901: Allow com.sun.management to be in a different module...'

Hi, can somebody please review this trivial AIX-only change which fixes an AIX build error: http://cr.openjdk.java.net/~simonis/webrevs/2015/8079510/ https://bugs.openjdk.java.net/browse/JDK-8079510 Here are the details: Change '8042901: Allow com.sun.management to be in a different module to j

Re: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

Hi David, thanks for doing this change on all platforms. The fix looks good. Maybe you can just extend the following comment with something like: // Note that the SR_lock plays no role in this suspend/resume protocol. // It is only used in SR_handler as a thread termination indicator if NULL.

Re: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

Hi David, looks good now. Thanks, Volker On Fri, Aug 5, 2016 at 4:28 AM, David Holmes wrote: > Hi Volker, > > Thanks for looking at this. > > On 5/08/2016 1:48 AM, Volker Simonis wrote: >> >> Hi David, >> >> thanks for doing this change on all platform

Re: 8173941 Re: SA does not work if executable is DSO

On Fri, Feb 10, 2017 at 10:40 AM, Andrew Haley wrote: > On 10/02/17 03:13, Yasumasa Suenaga wrote: >> We can calculate start address of executable (java command) through entry >> point. >> I updated webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8173941/webrev.01/ >> >> This patch can ig

Re: 8173941 Re: SA does not work if executable is DSO

On Fri, Feb 10, 2017 at 2:44 PM, Andrew Haley wrote: > On 10/02/17 13:21, Volker Simonis wrote: >> @Andrew: as this bug is assigned to you, I'd suggest to change it's >> status to open, the priority to P3 and target it for 9 (i.e. Fix >> Version = 9). > &g

Why doesn't jdk.hotspot.agent export anything?

Hi, I understand that the SA API is an unofficial, unsupported API which is constantly evolving and changing. But at least its JavaDoc has been made available recently [1] (and I really welcome and appreciate that). Unfortunately, with Java 9 and the new module system it becomes very inconvenient

Re: Why doesn't jdk.hotspot.agent export anything?

On Thu, Mar 2, 2017 at 10:00 AM, Alan Bateman wrote: > On 01/03/2017 13:23, Volker Simonis wrote: > >> Hi, >> >> I understand that the SA API is an unofficial, unsupported API which >> is constantly evolving and changing. But at least its JavaDoc has been >>

Re: @HotSpotIntrinsicCandidate and native prefixes

On Thu, Mar 23, 2017 at 10:30 AM, Michael Rasmussen wrote: > On Mar 14, 2017 23:03, "Vladimir Ivanov" > wrote: > > Yes, you are right. Then the only option is: > -XX:+UnlockDiagnosticVMOptions -XX:-CheckIntrinsics > > Best regards, > Vladimir Ivanov > > > Thinking about this a bit further, are

Re: Project to improve hs_err files

Hi Mattis, just some quick comments: On Fri, Sep 6, 2013 at 1:32 PM, Mattis Castegren wrote: > > Hi (re-sending mail after joining the mailing lists, sorry if you get this > mail twice) > > > > My name is Mattis and I work with the JVM sustaining engineering team at > Oracle. I am starting up

RFR(L): 8024854: Basic changes and files to build the class library on AIX

://wiki.openjdk.java.net/display/PPCAIXPort http://openjdk.java.net/jeps/175 Please send reviews to all currently included recipients. Thank you and best regards, Volker -- Forwarded message -- From: *Volker Simonis* Date: Monday, September 16, 2013 Subject: RFR(L): 8024854: Basic changes

Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX

ibjvm will always be loaded at the point in AWT where it is used. Another solution would be to re-implement the functionality in the class library and I don't like code duplication either. > -phil. > > > > > On 9/16/2013 12:30 PM, Volker Simonis wrote: > >> Resending thi

Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX

? If someone else (hotspot, core-libs) already assented > to this > then I guess I could too but I'd like to hear for sure that hotspot and > core-libs > teams both agree to this approach and whether there is an alternative. > > -phil. > > > On 9/19/13 4:29 AM,

Re: [OpenJDK 2D-Dev] RFR(L): 8024854: Basic changes and files to build the class library on AIX

> That's a good idea. Done. > >> extern int dladdr(void *addr, Dl_info *info); // use the HotSpot >> implementation from libjvm.so > > Did you ever get an opinion on this from the libraries or hotspot teams ? > No, I didn't got any opinions on that topic. I&#

RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

Hi, this is the second review round for "8024854: Basic changes and files to build the class library on AIX". The previous reviews can be found at the end of this mail in the references section. I've tried to address all the comments and suggestio

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

Hi Alan, thanks a lot for the fast review and your valuable comments. Please find my answers inline: On Thu, Nov 21, 2013 at 1:01 PM, Alan Bateman wrote: > On 20/11/2013 18:26, Volker Simonis wrote: > > Hi, > > this is the second review round for "8024854: Basic changes

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

/sun/management/OperatingSystemImpl.c. Fortunately, my changes to UnixOperatingSystem_md.c described in the webrev apply cleanly to the new file (I've tested this locally). I'll update the webrev accordingly once I've collected some more feedback. Thank you and best regards, Volker On Wed, Nov 20, 2

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

e AWT/2D guys. As far as I understood, you've now reviewed the 'core-lib'/'net' parts right? That would mean that I'll still need a review from the AWT/2D and the Security group - any volunteers:). Once again thanks a lot for your help, Volker On Fri, Nov 22, 2

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

again, Volker > > Thanks, > > Artem > > On 11/20/2013 10:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on AIX >> <https://bugs.openjdk.jav

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

6997010 > > Thanks, > Sean > > On 11/20/2013 01:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on >> AIX<https://bugs.openjdk.java.net/browse/

Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

tps://bugs.openjdk.java.net/browse/JDK-8024900) This change only contains the additional make changes which became necessary after I started to move AIX-specific files into their own jdk/src/aix/ directory. Everything else is already in place. I'll prepare and test a finaly webrev with all t

Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

will now call 'aix_close_init()' as suggested by Alan. The changes to src/solaris/native/com/sun/ management/UnixOperatingSystem_md.c are now in src/solaris/native/sun/management/OperatingSystemImpl.c because that file was moved by an upstream change. On Wed, Nov 20, 2013 at 7:26 PM, Volk

TEST: java/util/logging/LoggerWeakRefLeak.sh

Hi, the test 'java/util/logging/LoggerWeakRefLeak.sh' checks for the availability of the '-histo:live' option in jmap which is only available if the SA is available. However I don't think that it should be an error if the option isn't supported because of a missing SA implementation on a certain

Re: TEST: java/util/logging/LoggerWeakRefLeak.sh

Sorry, I forgot to mention that the same problem holds true for the test java/util/logging/AnonLoggerWeakRefLeak.sh as well. And it can be fixed in the same way as proposed for LoggerWeakRefLeak.sh. Volker On Wed, Dec 18, 2013 at 5:44 PM, Volker Simonis wrote: > Hi, > > the test &

Re: TEST: java/util/logging/LoggerWeakRefLeak.sh

On Wed, Dec 18, 2013 at 5:58 PM, Alan Bateman wrote: > On 18/12/2013 16:44, Volker Simonis wrote: >> >> Hi, >> >> the test 'java/util/logging/LoggerWeakRefLeak.sh' checks for the >> availability of the '-histo:live' option in jmap which is onl

RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Hi, could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): http://cr.openjdk.java.net/~simonis/webrevs/8031581/ I've build and smoke tested

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

Hi Alan, On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: > >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration in

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

think about assigning the concrete values depending on 'os.name' in the static initializers of the corresponding classes? I think that shouldn't introduce too much overhead and I could get rid of all the ugly conversion code. Regards, Volker > David > > > On 14/01/2014

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > On 15/01/2014 06:24, David Holmes wrote: > >> >> I'm not a fan of runtime checks of this kind though if it is only a very >> samll number of values it might be okay. >> >> Another option would be to make those classes into "templates" as done

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

re/transport/socket/socketTransport.c > No comments. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: >

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I’ve look at the following fi

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen &

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis wrote: > > > > On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > >> On 15/01/2014 06:24, David Holmes wrote: >> >>> >>> I'm not a fan of runtime checks of this kind though if it is only

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman wrote: > On 16/01/2014 09:38, Volker Simonis wrote: > > > > Hi Alan, > > I think sun.nio.ch.IOUtil seems even more appropriate to me for these > constants. What do you think? > > Would it be OK for you if I initi

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > On 14/01/2014 08:40, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following changes for the ppc-aix-port >> stage/stage-9 repositories (the changes are planned for integration into >&

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman > wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > On 20/01/2014 09:59, Volker Simonis wrote: >> >> : >> Hi Alan, >> >> yes, that's interesting. Sounds like a very similar problem on Mac. >> >> I would suggest the following: >> >&

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > On 20/01/2014 13:45, Volker Simonis wrote: >> >> : >> Hi everybody, >> >> so here's the second version of this webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ > &g

Re: Why do we need both - export maps AND -fvisibility=hidden/__attribute__((visibility("default")))

bility group to comment on this issue. I'll plan do write down all my findings in a more readable way within the next days. If there are any more/other comments on this topic I'll be highly interested. Regards, Volker > David > >> Jeremy >> >> >> On T

Re: Project to improve hs_err files

On Wed, Feb 12, 2014 at 2:14 PM, Nils Eliasson wrote: > On 2013-09-06 13:32, Mattis Castegren wrote: > > ... > > > > * Bigger changes > > - Re-structure hs_err file ... > > Yes, please move the compiler related info together. Having the current > compiler task separated from the compilation events

Re: Project to improve hs_err files

On Wed, Feb 12, 2014 at 6:30 PM, Nils Eliasson wrote: > > > On 2014-02-12 15:28, Volker Simonis wrote: >> >> On Wed, Feb 12, 2014 at 2:14 PM, Nils Eliasson >> wrote: >>> >>> On 2013-09-06 13:32, Mattis Castegren wrote: >>> >>> ...

Re: RFR(XS): JDK-8034867 - Object references from expression stack are not visible as roots via jvmti FollowReferences and HeapDump

Axel is covered by the SAP OCA. Thanks, Volker On Thu, Feb 20, 2014 at 6:30 AM, serguei.spit...@oracle.com wrote: > It looks good to me too. > But does Axel need to sign an OCA ? > > This is a link to follow: > http://openjdk.java.net/contribute/ > > > Thanks, > Serguei > > > > On 2/19/14 11:

Re: RFR(XS): JDK-8034867 - Object references from expression stack are not visible as roots via jvmti FollowReferences and HeapDump

1:05 AM, Siebenborn, Axel wrote: >>> >>> Yes, I need a sponsor for this change. >>> Thanks for the reviews, >>> Axel >>> >>> >>>> -Original Message- >>>> From: Volker Simonis [mailto:volker.simo...@gmail.com] >

Re: RFR(XS): JDK-8034867 - Object references from expression stack are not visible as roots via jvmti FollowReferences and HeapDump

On Mon, Feb 24, 2014 at 10:16 AM, Staffan Larsen wrote: > > On 24 feb 2014, at 09:39, Volker Simonis wrote: > >> Hi Serguei, >> >> thanks a lot for sponsoring this change. >> >> It seems that https://bugs.openjdk.java.net/browse/INTJDK-7609362 is >

RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect()

Hi, a security audit for the PPC64/AIX port revealed an unsecure useage of 'strcpy' in Java_sun_tools_attach_AixVirtualMachine_connect(). Because the same coding is also used in the Linux and BSD implementations, the following change fixes them all together: http://cr.openjdk.java.net/~simonis/we

Re: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect()

herwise we can end up opening wrong file with possibly not expected > permissions. > > -Dmitry > > On 2014-03-27 22:08, Volker Simonis wrote: >> Hi, >> >> a security audit for the PPC64/AIX port revealed an unsecure useage of >> 'strcpy' in Java

Re: RFR(S): 8038233 : Fix unsafe strcpy in Java_sun_tools_attach_{Aix, Bsd, Linux}VirtualMachine_connect()

Hi Alan, thanks for the review. On Thu, Mar 27, 2014 at 7:31 PM, Alan Bateman wrote: > On 27/03/2014 18:08, Volker Simonis wrote: >> >> Hi, >> >> a security audit for the PPC64/AIX port revealed an unsecure useage of >> 'strcpy' in Java_sun_tools_

Re: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero

Hi Maynard, I really apologize that I've somehow missed your first message. ppc-aix-port-dev was the right list to post to. I'll analyze this problem instantly and let you know why we post this zero-code size events. Regards, Volker PS: really great to see that somebody is working on oprofile/O

Re: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero

night about it:) Regards, Volker On Wed, Jul 2, 2014 at 7:38 PM, Volker Simonis wrote: > Hi Maynard, > > I really apologize that I've somehow missed your first message. > ppc-aix-port-dev was the right list to post to. > > I'll analyze this problem instantly and

Re: PowerPC: core file option not available with serviceability tools

Hi Maynard, we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and AIX (we have other proprietary servicibility tools). Because of that (and because SA isn't specified by the SE specification) porting the SA agent was no top priority until now. But there are no technical reasons wh

Re: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero

on, Jul 7, 2014 at 4:18 PM, Maynard Johnson wrote: > On 07/02/2014 01:21 PM, Volker Simonis wrote: >> After a quick look I can say that at least for the "flush_icache_stub" >> and "verify_oop" cases we indeed generate no code. Other platforms >> like x86

RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64

Hi, could someone please review and sponsor the following change which does some preliminary work for enabling the SA agent on Linux/PPC64: http://cr.openjdk.java.net/~simonis/webrevs/8049715/ https://bugs.openjdk.java.net/browse/JDK-8049715 Details: Currently, we don't support the SA agent on

Re: PowerPC: core file option not available with serviceability tools

On Wed, Jul 9, 2014 at 3:45 PM, Maynard Johnson wrote: > On 07/04/2014 10:59 AM, Volker Simonis wrote: >> Hi Maynard, >> >> we (i.e. SAP) do not currently support the SA agent on Linux/PPC64 and >> AIX (we have other proprietary servicibility tools). Because of th

Re: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64

Comments below where you might expect them :) > > > On 10/07/2014 3:36 AM, Volker Simonis wrote: >> >> Hi, >> >> could someone please review and sponsor the following change which >> does some preliminary work for enabling the SA agent on Linux/PPC64: >

"8046282: SA update" seems to break the SA/jstack in OpenJDK

Hi, the change "8046282: SA update" introduced the following new code in agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java +traceIDField = type.getField("_trace_id"); But I can not find the corresponding field in src/share/vm/oops/klass.hpp. The Klass class only contains the macro TRA

Re: "8046282: SA update" seems to break the SA/jstack in OpenJDK

e it fixed. See. > https://bugs.openjdk.java.net/browse/JDK-8049881 > > Thanks for reporting > Erik > > Volker Simonis skrev 2014-07-10 12:30: > >> Hi, >> >> the change "8046282: SA update" introduced the following new code in >> agent/src

Re: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64

On Fri, Jul 11, 2014 at 6:36 AM, David Holmes wrote: > Hi Volker, > > > On 10/07/2014 8:12 PM, Volker Simonis wrote: >> >> Hi David, >> >> thanks for looking at this. Here's my new version of the change with >> some of your suggestions applied: &g

Re: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64

or zero >>> ADD_SA_BINARIES/ia64 = >>> ADD_SA_BINARIES/zero = > OK, but then I also remove IA64 as it isn't an open platform either: http://cr.openjdk.java.net/~simonis/webrevs/8049715.v4/ I've also added Vladimir as reviewer. Thank you and best regards, Volker > Thanks, >

Re: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs

Hi everybody, can somebody PLEASE review and sponsor this tiny, ppc64-only change. Thanks, Volker On Tue, Jul 8, 2014 at 5:45 PM, Daniel D. Daugherty wrote: > Adding the Serviceability Team since JVM/TI belongs to them. > > Dan > > > > On 7/8/14 9:41 AM, Volker Si

Re: RFR(S): 8049715: PPC64: First steps to enable SA on Linux/PPC64

Great! Thanks a lot, Volker On Tue, Jul 15, 2014 at 12:56 AM, David Holmes wrote: > All changes (hotspot and top-level) are now in the jdk9/hs-rt forest. > > David > > > On 14/07/2014 9:09 PM, David Holmes wrote: >> >> On 14/07/2014 7:44 PM, Volker Simonis wrote

Re: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs

safe_access() correctly contains a StubCodeMark because it dynamically generates stub code - even if it is just the output of a "not yet implemented" message. Regards, Volker > We also need someone from the compiler team to look at this. > I also included into the cc-list Oleg,

Re: RFR(XS): 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs

Hi Serguei, thanks for sponsoring! So just waiting for another reviewer. Anybody volunteers:) Regards, Volker On Tue, Jul 15, 2014 at 11:09 AM, serguei.spit...@oracle.com wrote: > On 7/15/14 1:48 AM, Volker Simonis wrote: > > On Mon, Jul 14, 2014 at 10:35 PM, serguei.spit...@o

Re: Fwd: PowerPC issue: Some JVMTI dynamic code generated events have code size of zero

: unfortunately it is not possible to add people without OpenJDK "Author" status to the watch list of bugs. So the only chance you have is to manually look at the bug reports you're interested in :( On Wed, Jul 30, 2014 at 7:05 PM, Maynard Johnson wrote: > On 07/07/2014 10:51 AM, Vo

Re: Problem generating C header file for Hotspot debugger PPC64ThreadContext class

Hy Maynard, sorry, but I think you edited the wrong Make file (that's why you saw no effect - neither positive nor negative:) The right Makefile is "hotspot/make/linux/makefiles/sa.make". If you add your new Thread context class to the 'javah' rules at the end of the file it should work. I actua

Re: RFR: 8057776 Misc cleanups of the attach code

hi Staffen, the change looks good, but could you please also change src/jdk.attach/aix/classes/sun/tools/attach/AttachProviderImpl.java Thanks, Volker On Mon, Sep 8, 2014 at 2:45 PM, Staffan Larsen wrote: > Thank you, all. > > On 8 sep 2014, at 14:39, Daniel Fuchs wrote: > > > Hi Staffan, >

Re: RFR: 8057776 Misc cleanups of the attach code

xception; > import com.sun.tools.attach.spi.AttachProvider; > import java.io.InputStream; > import java.io.IOException; > import java.io.File; > -import java.util.Properties; > > // Based on linux/classes/sun/tools/attach/VirtualMachineImpl.java. > > > On 8 sep 2014, at

Re: PowerPC: core file option not available with serviceability tools

the frame pointer (i.e. the ebp register points to the last frame pointer while (frame pointer - 1) points to the return pc. Regards, Volker On Tue, Sep 30, 2014 at 12:42 AM, Maynard Johnson wrote: > On 07/09/2014 12:38 PM, Volker Simonis wrote: >> On Wed, Jul 9, 2014 at 3:45 PM, May

Re: RFR(XS): 8059868: JVM crashes on attach on Windows when compiled with /RTC1

Hi, the change looks good to me. I can also sponsor this change. Nevertheless I'd like to get one more opinion from the serviceability group. Thanks, Volker On Tue, Oct 7, 2014 at 4:27 PM, Thomas Stüfe wrote: > (the corresponding bug report is > https://bugs.openjdk.java.net/browse/JDK-8059868

Re: RFR(XS): 8059868: JVM crashes on attach on Windows when compiled with /RTC1

Thanks Alan, Staffan, I'll push the change with the spacing adjusted as suggested by Alan. Regards, Volker On Wed, Oct 8, 2014 at 9:33 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > > On 7 okt 2014, at 16:26, Thomas Stüfe wrote: > > Hi all, > > We saw crashes when connecting

Re: system profilers and incomplete stacks

Hi, I think the main problem here is not only that compiled code uses the frame pointer as a general purpose register, but the fact that even the VM itself currently can not reliably take a stack trace of a thread at any arbitrary PC. An external sampling profiler like perf can interrupt the VM at

Re: PowerPC: core file option not available with serviceability tools

On Fri, Nov 14, 2014 at 6:00 PM, Maynard Johnson wrote: > On 10/07/2014 08:35 AM, Maynard Johnson wrote: >> On 10/07/2014 03:58 AM, Volker Simonis wrote: >>> Hi Maynard, >>> >>> I'm now back from JavaOne and can look at this issue. Could you please >&

  1   2   >