Re: RFR 8205113: Update JVMTI doc references to object allocation tracking

including those* > *++ caused by bytecode method execution, JNI method execution, and > directly by VM methods.* > > > Maybe, just adding the last statement would be good enough. > > Thanks, > Serguei > > > On 6/18/18 21:36, David Holmes wrote: > > On 19/06/2018 4:5

Re: RFR 8205113: Update JVMTI doc references to object allocation tracking

David Holmes wrote: > On 18/06/2018 5:01 PM, Jeremy Manson wrote: > > We haven't changed when a VM issues "VM object allocation" events. > > > > There were references in the docs to a requirement to use bytecode > > rewriting and JNI interception to track

Re: RFR 8205113: Update JVMTI doc references to object allocation tracking

o make it clear that, while you can still use it for this, you can also just use SampledObjectAlloc for everything. Jeremy On Sun, Jun 17, 2018 at 9:11 PM David Holmes wrote: > Hi Jeremy, > > On 16/06/2018 2:33 AM, Jeremy Manson wrote: > > Hi all, > > > > There are a nu

Re: RFR JDK-8198253: ThreadInfo.from(CompositeData) assigning fields incorrectly in JDK 9

nfo} of version N > * which implies that its {@code "lockedStackFrame"} attribute also > * represents {@code StackTraceElement} of the same version, N. > * Otherwise, this method will throw {@code IllegalArgumentException}. > > > Mandy > > On 2/27/18 9:56 AM, Jere

Re: Thread Native ID Access

be supported by all implementations, which is a higher bar > than for c.s.m changes. > > > > Paul > > > > *From: *Jeremy Manson > *Date: *Friday, February 23, 2018 at 3:12 PM > *To: *"Hohensee, Paul" > *Cc: *David Holmes , "serviceability-dev@op

Re: Thread Native ID Access

I think we're all pretty much agreed that fibers imply native tids can change. I think that, as long as we document that, we're fine. An API where there is probably a worse implementation problem is ThreadMXBean#getThreadCpuTime

Re: Thread Native ID Access

x27;s pretty dangerous, so I'm not sure that it's a great idea as-is. We have a bunch of extra entries in perfdata, but we should probably review them to make sure we still care about all of them. We also have some bug fixes and performance improvements, and we should probably just send

Thread Native ID Access

Hey folks, I mentioned earlier in the thread about the ThreadInfo.from() bug that I found this because I was looking at fixing JDK-8154176, which proposes introducing native thread ids to Thread and ThreadInfo. https://bugs.openjdk.java.net/browse/JDK-8154176 I have a prototype for it. I have a

Re: GcInfo: longest pause duration?

Yes, this information is useful. We've done a couple of things to get at it, which folks might find interesting. 1) We extended the hsperfdata to include a large number of stats for CMS. Parsing hsperfdata is ridiculously easy, and hasn't changed in years, so we just parse it directly and report

Re: Low-Overhead Heap Profiling

; > On 4 Aug 2015, at 23:22, Jeremy Manson wrote: > > > > Thanks, Staffan. I've been tinkering with a draft JEP, but it has been > going slowly because of other craziness in my life. Some responses: > > > > 1) It was a fair bit of work to do it, mostly because it

Re: RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs

t; Thanks, > David > > > Looks good. >> >> Thanks, >> Vladimir >> >> On 7/29/15 3:31 PM, David Holmes wrote: >> >>> Hi Jeremy, >>> >>> On 30/07/2015 6:34 AM, Jeremy Manson wrote: >>> >>>> David, can you

RFR (XS): 6661889: thread id on Linux is inconsistent in error and log outputs

David, can you review/sponsor this, per our conversation of last week? It fixes an issue where, on Linux, some of the Hotspot logging output identifies threads by pthread_id, and some of it identifies threads by kernel-level TID. This happened because Hotspot calls into two different APIs that pr

Re: os::current_thread_id on Linux

? Jeremy On Wed, Jul 22, 2015 at 7:08 PM, David Holmes wrote: > On 23/07/2015 8:01 AM, Jeremy Manson wrote: > >> Based on the feedback, this seems to be a good idea, approximately. >> Coleen would have sponsored, but she's going on vacation. Anyone else >> feel

Re: os::current_thread_id on Linux

Based on the feedback, this seems to be a good idea, approximately. Coleen would have sponsored, but she's going on vacation. Anyone else feel like sponsoring? Jeremy On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson wrote: > Hey folks, > > os::current_thread_id on Lin

Re: os::current_thread_id on Linux

hs_c11835_pid11818.log hsperfdata_root/ Where 1183x maps neatly back to 0x2e3x in the SIGQUIT dump. Jeremy On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson wrote: > Hey folks, > > os::current_thread_id on Linux now maps to pthread_self. The problem with > pthread_self is that it only

os::current_thread_id on Linux

Hey folks, os::current_thread_id on Linux now maps to pthread_self. The problem with pthread_self is that it only makes sense in the context of the running process. When it is written out to the log (as it is in several places), there really isn't a way (AFAICT) for the user to map it back to an

Re: Low-Overhead Heap Profiling

> > > > On Thu, Jun 25, 2015 at 2:23 PM, Tony Printezis > wrote: > >> BTW, Could we get a reaction from the Oracle folks on this? >> > I contacted Staffan (who is probably the right person) offline, and he is, apparently, on vacation until the beginning of August. Unless there is someone else at

Re: Low-Overhead Heap Profiling

, 2015 at 10:27 PM, Jeremy Manson wrote: > > > On Thu, Jun 25, 2015 at 1:28 PM, Tony Printezis > wrote: > >> Hi Jeremy, >> >> Inline. >> >> On June 24, 2015 at 7:26:55 PM, Jeremy Manson (jeremyman...@google.com) >> wrote: >> >> &g

Re: Low-Overhead Heap Profiling

On Thu, Jun 25, 2015 at 1:55 PM, Tony Printezis wrote: > Bernd, > > I like the idea of buffering up the sampled objects in, some data > structure. But I assume it’d have to be a per-thread data structure to > avoid conention issues. So, we’ll also need a periodic task that collects > all such dat

Re: Low-Overhead Heap Profiling

profiling in common allocation code. > > thanks, > Karen > > On Jun 25, 2015, at 4:28 PM, Tony Printezis wrote: > > Hi Jeremy, > > Inline. > > On June 24, 2015 at 7:26:55 PM, Jeremy Manson (jeremyman...@google.com) > wrote: > > > > On Wed, Jun 24, 2015 at

Re: Low-Overhead Heap Profiling

On Thu, Jun 25, 2015 at 1:28 PM, Tony Printezis wrote: > Hi Jeremy, > > Inline. > > On June 24, 2015 at 7:26:55 PM, Jeremy Manson (jeremyman...@google.com) > wrote: > > > > On Wed, Jun 24, 2015 at 10:57 AM, Tony Printezis > wrote: > >> Hi Jeremy, >&

Re: Low-Overhead Heap Profiling

On Wed, Jun 24, 2015 at 10:57 AM, Tony Printezis wrote: > Hi Jeremy, > > Please see inline. > > On June 23, 2015 at 7:22:13 PM, Jeremy Manson (jeremyman...@google.com) > wrote: > > I don't want the size of the TLAB, which is ergonomically adjusted, to be > tied to

Re: Low-Overhead Heap Profiling

I don't want the size of the TLAB, which is ergonomically adjusted, to be tied to the sampling rate. There is no reason to do that. I want reasonable statistical sampling of the allocations. All this requires is a separate counter that is set to the next sampling interval, and decremented when a

Re: Low-Overhead Heap Profiling

If it is a blocker for this work, we can find a way to test on OS X and Windows. Jeremy On Tue, Jun 23, 2015 at 9:14 AM, Jeremy Manson wrote: > I haven't tried! Another problem with our submitting things is that we > can't really test on anything other than Linux. > > T

Re: Low-Overhead Heap Profiling

5 at 6:14 AM, Daniel D. Daugherty < daniel.daughe...@oracle.com> wrote: > > ASGCT_CallTrace *trace; > > So it looks like this uses the AsyncGetTrace() infrastructure. > Does your tool work on Windows and MacOS X? > > Dan > > > > On 6/22/15 10:58 PM, Jeremy Ma

Re: Low-Overhead Heap Profiling

t 11:46 PM, Mario Torre < neugens.limasoftw...@gmail.com> wrote: > 2015-06-23 6:58 GMT+02:00 Jeremy Manson : > > While I'm glad to hear that our colleagues at RedHat would love it, it > will > > still need a sponsor from Oracle. Any volunteers? > > > > It wi

Re: Low-Overhead Heap Profiling

While I'm glad to hear that our colleagues at RedHat would love it, it will still need a sponsor from Oracle. Any volunteers? It will also need a little polish to be available to the world. Open design questions for upstreaming are things like: - Should the interval between samples be configura

Low-Overhead Heap Profiling

Hey folks, (cc'ing Aleksey and John, because I mentioned this to them at the JVMLS last year, but I never followed up.) We have a patch at Google I've always wanted to contribute to OpenJDK, but I always figured it would be unwanted. I've recently been thinking that might not be as true, though.

Re: RFR: 6588467: Add isDaemon() and getPriority() to ThreadInfo

Thanks, Mandy. I guess it is time to submit. I don't have a committer bit. Any volunteers? Thanks to all for the review! Jeremy On Mon, Feb 23, 2015 at 5:29 PM, Mandy Chung wrote: > On 2/23/15 11:49 AM, Jeremy Manson wrote: > >> Okey-doke: >> >> http://cr.open

Re: gdb and OpenJDK

Hey folks, I just want to make sure we are on the same page here: 1) Andrew is talking about using the gdbjit interface and generated DWARF information. I believe this wouldn't work for interpreted code, because there is no JIT information emitted for it. It would also require extra work to mak

gdb and OpenJDK

Hey folks, I think I've mentioned to some of the people on this list that we (and by we, I mean Sasha Smundak) have been working on interoperability between gdb and Java. Basically, what we have now allows us to get a backtrace in gdb that includes Java frames with parameter values (no local vari

Re: RFR 8062116: JVMTI GetClassMethods is Slow

gt; >>> On 6/11/2014 1:00 PM, Coleen Phillimore wrote: >>> >>>> >>>> On 11/5/14, 8:11 PM, serguei.spit...@oracle.com wrote: >>>> >>>>> >>>>> On 11/5/14 4:35 PM, Jeremy Manson wrote: >>>>> >>>>

Re: RFR 8062116: JVMTI GetClassMethods is Slow

Thanks for taking a look, Coleen! On Mon, Nov 3, 2014 at 12:19 PM, Coleen Phillimore < coleen.phillim...@oracle.com> wrote: > > Hi Jeremy, > > I reviewed your new code and it looks fine. I had one comment in > > http://cr.openjdk.java.net/~jmanson/8062116/webrev.00/src/ > share/vm/prims/jvmtiEnv

Re: Second Code Review for WeakReference leak in the Logging API (6942989)

e hi value occurred >> in sample #269 of 647 and the last sample was below the average. >> This data indicates that the values are both rising and falling >> over time which does not indicate any more memory leaks. >> >> >> >> I also ran the LoggerWeakRefLea

Re: Second Code Review for WeakReference leak in the Logging API (6942989)

Greetings, > > I have a new version of my fix for the WeakReference leak in the > Logging API done. This version uses ReferenceQueues; thanks to Eamonn > McManus, Jeremy Manson and Tony Printezis for their insights on using > ReferenceQueues. Here's a pointer to Tony's

Re: Code Review for WeakReference leak in the Logging API (6942989)

Okay. It sounds as if the changes were helpful, anyway. I'll be interested to see what you do. Jeremy On Mon, Jun 14, 2010 at 4:20 PM, Daniel D. Daugherty wrote: > On 6/14/2010 12:36 PM, Jeremy Manson wrote: >> >> Daniel, >> >> We're happy to contribute.  

Re: Code Review for WeakReference leak in the Logging API (6942989)

On 6/14/2010 11:30 AM, Jeremy Manson wrote: >> >> Daniel, >> >> The fix hasn't made it to OpenJDK6.  We were planning on pushing it to >> OpenJDK6/7, but we haven't had time for it yet.  If your fix is better >> (I haven't had a chance to look at

Re: Code Review for WeakReference leak in the Logging API (6942989)

Daniel, The fix hasn't made it to OpenJDK6. We were planning on pushing it to OpenJDK6/7, but we haven't had time for it yet. If your fix is better (I haven't had a chance to look at it), then we'll happily drop ours in favor of yours. For testing: I hand tested it with the "create lots of anon

Re: Code Review for WeakReference leak in the Logging API (6942989)

We also fixed this bug internally at Google (sending the patch out was a TODO, but we never got around to it). If you have any interest in comparing / contrasting approaches, let us know. Jeremy On Thu, Jun 10, 2010 at 10:13 AM, Daniel D. Daugherty wrote: > Greetings, > > I need a couple of cod

Re: code review request for JVM/TI CompiledMethodLoad event extension (6580131)

Okay, thanks. Jeremy On Mon, May 3, 2010 at 4:22 PM, Tom Rodriguez wrote: > They are resource allocated so they don't need to be free'd.  The destructor > of ResourceMark will release any storage that was allocated. > > tom

Re: code review request for JVM/TI CompiledMethodLoad event extension (6580131)

Resurrecting an old thread... Is there any reason that no one ever frees the arrays that are created by this changeset in create_inline_record() in jvmtiExport.cpp? Or am I just missing where they are freed? I don't think they are freed elsewhere... I added a method that performed some obvious

Re: DTraceAllocProbes in x86-64 templateTable?

Seems to be fixed now. Thanks! Jeremy On Thu, Feb 4, 2010 at 8:13 PM, David Holmes - Sun Microsystems wrote: > I've "touched" the CR to raise it to the attention of the RE. > > David > > Jeremy Manson said the following on 02/05/10 13:03: >> >> Thi

Re: DTraceAllocProbes in x86-64 templateTable?

This has seriously gone unfixed for two years? Jeremy On Thu, Feb 4, 2010 at 6:24 PM, David Holmes - Sun Microsystems wrote: > Known bug: 6587322 > > Cheers, > David > > Keith McGuigan said the following on 02/05/10 12:13: >> >> Jeremy Manson wrote: >>> &

DTraceAllocProbes in x86-64 templateTable?

Hi folks, I noticed that the call to DTraceAllocProbes in the 64-bit x86 templateTable is directly after a jump instruction that jumps over it. I don't have dtrace to check, but that can't be right, can it? It's line 3245 of: http://hg.openjdk.java.net/jdk7/hotspot-comp-gate/hotspot/file/c02850

Deadlocked Thread State is RUNNABLE?

Hi folks, I notice that when you send a sigquit to a VM, and threads are deadlocked in class initialization, then the thread state is reported as RUNNABLE. Is this deliberate? With the attached program (which mostly deadlocks on clinit - I don't have the time to remember how to write the 100-per

Re: JVMTI OOM handling when arrays / objects are too large

So, it should have the JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR but not the JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP? I can change that. Jeremy On Tue, Jun 23, 2009 at 12:45 PM, Alan Bateman wrote: > Jeremy Manson wrote: >> >> On Wed, Jun 17, 2009 at 3:13 AM, Alan Bateman wrote: >>

Re: JVMTI OOM handling when arrays / objects are too large

On Wed, Jun 17, 2009 at 3:13 AM, Alan Bateman wrote: > Hopefully this helps. I can review the patch but as I'm not working in this > area on a daily basis, so it would be best to have a reviewer from the > hotspot team (and I assume you'll need someone to push this through JPRT). So, does anyone

Re: JVMTI OOM handling when arrays / objects are too large

Not that I actually have a vote, but if Alan feels it is not worth making, I would go back to arguing for something like a VirtualMachineError to be thrown, because the behavior is out of spec. The current behavior - a sort-of-but-not-really OOME - is a little odd. Jeremy On Tue, Jun 16, 2009 at

Re: JVMTI OOM handling when arrays / objects are too large

I'm not sure if the heap dump is as interesting as the fact that you are going to take some action when you do OnOutOfMemoryError. It is rather surprising to have specified that a particular action is taken when a OOME occurs, and have it not happen when an OOME occurs. I guess that because it is

Re: JVMTI OOM handling when arrays / objects are too large

FWIW, I also think that having a call to new throw anything that isn't an OOME is opening up a much larger compatibility can of worms than anything else I intended with this patch. Jeremy On Mon, Jun 15, 2009 at 12:39 AM, Jeremy Manson wrote: > Hi Tomas (and David, presumably), > >

Re: JVMTI OOM handling when arrays / objects are too large

Hi Tomas (and David, presumably), Why is this a programming error? I thought it was just a VM limitation. Surely the JVMS allows arrays of any nonnegative integral size, no? Jeremy On Mon, Jun 15, 2009 at 12:20 AM, Tomas Hurka wrote: > Hi Martin and David, > > On 14 Jun 2009, at 21:37, Martin

Re: JVMTI OOM handling when arrays / objects are too large

This one happens to be pretty easy to trigger. I'm not sure how to put together a jtreg test, but the following code works: public class OOM { public static void main(String[] args) throws Exception { int size = Integer.MAX_VALUE; Integer[] props = new Integer[size]; } } And then inv

Re: JVMTI OOM handling when arrays / objects are too large

Thanks Tim! Martin Buchholz tells me that three things have to happen to get a patch in: 1) Someone inside Sun has to file a bug. Usually, this seems to be in the other bug database, but I guess it doesn't matter? 2) Two OpenJDK members have to review it (in practice). Is my understanding corr

JVMTI OOM handling when arrays / objects are too large

Hi folks, I was talking to some of the HS team at JavaOne, and they encouraged me to send some of the patches that we are working on at Google back to Sun. (Everyone at Google is covered under a blanket SCA, so we can contribute back anything done by any Googler). To get started and test the wat