Oh right, then it could get truncated, but should not overflow.
On Sat, Feb 27, 2021 at 7:15 PM Ioi Lam wrote:
> On Sat, 27 Feb 2021 05:19:01 GMT, Thomas Stuefe
> wrote:
>
> >> src/hotspot/share/memory/metaspaceShared.cpp line 799:
> >>
> >>> 797: if (strstr(file_name, ".jsa") ==
Hi Thomas,
I think this makes sense. Just a question, how are your thoughts about
JEP316? Do you consider AllocateHeapAt similarly unused?
Cheers, Thomas
On Wed, Nov 11, 2020 at 2:17 PM Thomas Schatzl
wrote:
> Hi all,
>
> can I get reviews for this change that removes the "Allocation of old
On Fri, Nov 6, 2020 at 2:01 PM David Holmes wrote:
> On 6/11/2020 10:08 pm, Thomas Stuefe wrote:
> > On Fri, 6 Nov 2020 12:02:28 GMT, Coleen Phillimore
> wrote:
> >
> >>> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 84:
> >>>
> 82: // Truncate milliseconds in buffer
On Fri, Sep 4, 2020 at 11:23 AM Volker Simonis
wrote:
> On Thu, Sep 3, 2020 at 8:26 PM Thomas Stüfe
> wrote:
> >
> > Hi Volker,
> >
> > On Thu, Sep 3, 2020 at 7:41 PM Volker Simonis
> wrote:
> >>
> >> Hi Thomas,
> >>
> >&
On Thu, Sep 3, 2020, 21:27 Laurence Cable wrote:
>
>
> On 9/3/20 12:25 PM, Thomas Stüfe wrote:
>
>
>
> On Thu, Sep 3, 2020, 21:07 Laurence Cable wrote:
>
>>
>>
>> On 9/3/20 9:03 AM, Volker Simonis wrote:
>> > Hi,
>> >
>> >
On Thu, Sep 3, 2020, 21:07 Laurence Cable wrote:
>
>
> On 9/3/20 9:03 AM, Volker Simonis wrote:
> > Hi,
> >
> > I'd like to get your opinion on a POC I've done in order to speed up
> > heap dumps on Linux:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8252768
> >
Hi Volker,
On Thu, Sep 3, 2020 at 7:41 PM Volker Simonis
wrote:
> Hi Thomas,
>
> Thanks for sharing your concerns. Please find my anserwers inline:
>
> On Thu, Sep 3, 2020 at 6:58 PM Thomas Stüfe
> wrote:
> >
> > Hi Volker,
> >
> > hah, that is a c
Hi Volker,
hah, that is a cool idea :)
Lets see what could go wrong:
So, child process is forked, but in the child only the forking thread
survives, right? The forking thread then proceeds to dump. What happens
when, during dumping, it needs a lock owned by one of the non-running
threads? Could
Hi Ralf,
belated, but looks good to me.
Thanks, Thomas
On Mon, Dec 16, 2019 at 1:28 PM Schmelter, Ralf
wrote:
> I forgot to post the updated webrev:
> http://cr.openjdk.java.net/~rschmelter/webrevs/8234510/webrev.2/
>
> In addition to the changes requested by Thomas, I also renamed the
not see an abort.
>
>
>
>
>
>
>
> I think we should add an exit(2) or abort(2) to the assertion.
>
>
>
> But I also think this is a different issue from what Matthias tries to
> fix, so I am fine with Matthias change.
>
>
>
> Cheers, Thomas
>
>
>
>
e should add an exit(2) or abort(2) to the assertion.
But I also think this is a different issue from what Matthias tries to fix,
so I am fine with Matthias change.
Cheers, Thomas
On Fri, Nov 29, 2019 at 8:20 AM Alan Bateman
wrote:
> On 29/11/2019 06:29, Thomas Stüfe wrote:
> &
Hi Matthias,
I am not certain the callers are prepared to handle NULL.
This is used in a chain of TRANSFORM macro calls which AFAICS do not handle
NULL; e.g. , at 872, we pass the returned pointer to
convertUft8ToPlatformString which passes it on (on Windows) to
MultiByteToWideChar, which does
Hi David,
On Mon, Nov 18, 2019 at 2:26 PM David Holmes
wrote:
> Hi Thomas,
>
> Thanks for taking a look.
>
> On 18/11/2019 9:58 pm, Thomas Stüfe wrote:
> > This is evil :)
> >
> > There might be more cases like this, e.g.
> >
> > fra
This is evil :)
There might be more cases like this, e.g.
frame_x86.cpp frame::is_interpreted_frame_valid():
if (locals > thread->stack_base() || locals < (address) fp()) return false;
Also, I would have thought the little alloca() dance we do at the start
of thread_native_entry() would push
Hi Ralf,
On Fri, Nov 8, 2019 at 4:45 PM Schmelter, Ralf
wrote:
> Hi Thomas,
>
> thanks for the review.
>
>
> > Can you please add a comment about the new parameter? E.g. "optional
> outputStream to which progress- and error messages will be written".
>
> Will do.
>
>
> > - in
Hi Ralf,
this makes sense. Some small remarks:
---
heapDumper.hpp
// dumps the heap to the specified file, returns 0 if success.
- int dump(const char* path);
+ int dump(const char* path, outputStream* out = NULL);
Can you please add a comment about the new parameter? E.g. "optional
Looks good.
There is also a possible buffer overrun some lines above:
357 char* posbin = strstr(execname, "/bin/java");
358 if (posbin != NULL) {
359 memcpy(filepath, execname, posbin - execname);// not include
trailing '/'
360 filepath[posbin - execname] = '\0';
depending
Hi Matthias,
your changes look good.
an additional bug:
http://cr.openjdk.java.net/~mbaesken/webrevs/8230901.0/src/jdk.hotspot.agent/solaris/native/libsaproc/saproc.cpp.frames.html
698 #ifndef _LP64
699 atoi(cmdLine_cstr);
700 if (errno) {
Behaviour of atoi() in error case is
t;
>
>
> Would you agree?
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* Chris Plummer
> *Sent:* Mittwoch, 11. September 2019 19:21
> *To:* Thomas Stüfe ; Langer, Christoph <
> christoph.lan...@sap.com>
> *Cc:* OpenJDK Serviceability
> *Su
Hi Christoph,
in general I think this is fine. The increase-by-pow2 sleep time is odd but
okay :)
The whole things seems rather fragile and has a lot of question marks but I
think your fix does not make it worse. One fun error now is that with a
follow up java test reusing the PID we could get a
Thank you Chris.
On Wed, Jun 5, 2019, 19:22 Chris Plummer wrote:
> Looks good. Thanks for fixing quickly.
>
> Chris
>
> On 6/5/19 9:50 AM, Thomas Stüfe wrote:
>
> Hi all,
>
> may I have a small review please for this patch:
>
> cr:
> http://cr.openjdk.java.ne
ses redefined (0 events):").
>
> but you only check for Classes unloaded for example. Perhaps you could
> update the example to one of the regex you actually do check for ?
>
> Evidently no need of another webrev for that!
> Jc
>
> On Wed, Jun 5, 2019 at 9:52 AM Thomas S
Hi all,
may I have a small review please for this patch:
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8225348-eventstest-failed/webrev.00/webrev/
bug: https://bugs.openjdk.java.net/browse/JDK-8225348
JDK-8224600 introduced a new jcmd, VM.events, and an associated test.
In
On Tue, May 28, 2019 at 12:19 AM David Holmes
wrote:
> On 28/05/2019 12:33 am, Langer, Christoph wrote:
> > Hi Alan,
> >
> >> On 27/05/2019 14:23, Schmelter, Ralf wrote:
> >>
> >> I need reviews for the following CSR:
> >> https://bugs.openjdk.java.net/browse/JDK-8223456
> >> Note that this CSR
Hi all,
could I please have opinions and a reviewer for the following CSR:
https://bugs.openjdk.java.net/browse/JDK-8224601
which aims to add a dedicated "VM.events" command to jcmd to print out
event logs.
Thanks, Thomas
Looks fine and trivial.
Cheers, Thomas
On Tue, May 21, 2019 at 6:53 PM Jean Christophe Beyler
wrote:
> Hi all,
>
> Could I get a review for pushing HeapMonitorStatArrayCorrectnessTest into
> the problem list? It is a test that is tricky to get always right and I'll
> work offline on getting it
On Tue, May 21, 2019 at 3:22 PM Stefan Karlsson
wrote:
> Hi Thomas,
>
> On 2019-05-21 12:37, Thomas Stüfe wrote:
> > I think this is useful.
>
> Thanks.
>
> I have a vague preference for reusing VM.flags
> > though - giving it the option to only print one f
I think this is useful. I have a vague preference for reusing VM.flags
though - giving it the option to only print one flag - instead of adding a
new command.
Just my 5c
.. Thomas
On Tue, May 21, 2019, 12:14 Stefan Karlsson
wrote:
> Hi all,
>
> Please review this patch to introduce a new
On Sun, Apr 21, 2019 at 3:01 AM Jean Christophe Beyler
wrote:
> Ahh there lies the problem of understanding then :)
>
> We can provide that for our users that can use a non-vanilla OpenJDK.
> Vanilla OpenJDK cannot use that kind of thing since there is no "C" style
> symbol you could dlsym to. I
Hi JC,
not sure if that helps, but we set - originally for debugging purposes -
the thread name for platforms where that is possible. This is what you see
in gdb when listing threads.
On POSIX platforms this means we call some form of pthread_setname_np(),
which can be queried from the outside
Hi Gary,
I am not sure this makes sense. jcmd can be used to access wildly different
VMs with different command sets, including Vendor-specific commands (we
have additional commands in the SapMachine, for instance). Also, jcmd is
up- and downward compatible, and you can run older jcmd versions
On Thu, Mar 28, 2019 at 11:10 AM David Holmes
wrote:
> On 28/03/2019 4:55 pm, Thomas Stüfe wrote:
> > On Thu, Mar 28, 2019 at 8:40 AM David Holmes > <mailto:david.hol...@oracle.com>> wrote:
> >
> > Hi Thomas,
> >
> > On 28/03/2019 5:02
On Thu, Mar 28, 2019 at 8:40 AM David Holmes
wrote:
> Hi Thomas,
>
> On 28/03/2019 5:02 pm, Thomas Stüfe wrote:
> > Hi Serguei,
> >
> > This is planned to be introduced in jdk 13?
> >
> > The only concern I have is that both paths (old and new behavior
Hi Serguei,
This is planned to be introduced in jdk 13?
The only concern I have is that both paths (old and new behavior) should be
well tested, and hiding the old behavior behind an optional switch may
reduce its test coverage considerably.
Cheers, Thomas
(p.s. html format does not work well
Neat! Both directions are fixed now: I can connect with new jcmd to old VMs
and vice versa. Thanks a lot!
..Thomas
On Mon, Mar 4, 2019 at 10:14 AM 臧琳 wrote:
> Dear All,
>May I ask your help to review the fix of compatibility issue introduced
> by JDK-8215622
>webrev:
On Tue, Feb 26, 2019 at 8:54 PM Chris Plummer
wrote:
> On 2/26/19 9:34 AM, Erik Gahlin wrote:
>
> On 2019-02-26 07:47, Thomas Stüfe wrote:
>
> Hi David, Yasumasa,
>
>
>>
>> > Do we support connection to later VMs from earlier JDK tools?
>>
>> I c
Hi David, Yasumasa,
>
> > Do we support connection to later VMs from earlier JDK tools?
>
> I could not find the spec about this.
> So I asked to serviceability folks before filing this to JBS :-)
>
>
Just to chime in on that, I do not know if it is specified but it is
certainly very handy in
d. Is that addressed since the
> container-PID changes? In both cases a force option would help.
>
> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> --
> *Von:* serviceability-dev
> im Auftrag von
> gar
On Fri, Feb 15, 2019 at 3:19 PM Thomas Stüfe
wrote:
> Could we not just use another signal? One less... quitty? I think SIGUSR2
> may still be unused, but I may be mistaken. Or, one of the real time
> signals (SIGRTMIN + x).
>
>
wait, that one would break downward compatibil
On Fri, Feb 15, 2019 at 3:26 AM David Holmes
wrote:
> Gary,
>
> What is the overhead of doing the validation? How do we list VMs? Do we
> need to examine every running process to get the list of VMs? Wouldn't
> it be better to check the given process is a VM rather than checking all
> potential
Hi Gary,
thanks for taking this on. I have occasionally killed a foreign process
with jcmd and it is a bit embarrassing :)
I think your patch is okay, but I wonder whether a check directly in
libattach would be simpler and cover all uses of the attach framework.
Such a test could be e.g. simply
On Wed, Nov 28, 2018 at 8:53 PM Kim Barrett wrote:
>
> > On Nov 28, 2018, at 2:26 AM, David Holmes wrote:
> > On 28/11/2018 4:30 pm, Thomas Stüfe wrote:
> >> P.s.
> >> ConcurrentGCThread::ConcurrentGCThread() :
> >> _should_terminate(false
guides/jni/spec/design.html#wp16696
>
> On Wed, Nov 28, 2018 at 7:38 AM Thomas Stüfe wrote:
>>
>> On Wed, Nov 28, 2018 at 4:19 PM wrote:
>> >
>> >
>> >
>> > On 11/28/18 10:08 AM, Thomas Stüfe wrote:
>> > > On Wed, Nov 28, 2018 at 4:
On Wed, Nov 28, 2018 at 4:19 PM wrote:
>
>
>
> On 11/28/18 10:08 AM, Thomas Stüfe wrote:
> > On Wed, Nov 28, 2018 at 4:03 PM wrote:
> >>
> >>
> >> On 11/28/18 10:00 AM, Thomas Stüfe wrote:
> >>> On Wed, Nov 28, 2018 at 3:59 PM Thomas St
On Wed, Nov 28, 2018 at 4:03 PM wrote:
>
>
>
> On 11/28/18 10:00 AM, Thomas Stüfe wrote:
> > On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe
> > wrote:
> >> Hi Coleen,
> >>
> >> (moved to svc-dev since David did shoo us off discus
On Wed, Nov 28, 2018 at 3:59 PM Thomas Stüfe wrote:
>
> Hi Coleen,
>
> (moved to svc-dev since David did shoo us off discuss before :-)
>
> Just to be sure I understand:
>
> > If the class is unloaded, the jmethodID is cleared. Native code should
> > first
Hi Coleen,
(moved to svc-dev since David did shoo us off discuss before :-)
Just to be sure I understand:
> If the class is unloaded, the jmethodID is cleared. Native code should
> first test whether it's NULL. I think that is the predictable behavior
> that the spec requires.
Wait, really?
On Wed, Nov 28, 2018 at 8:59 AM David Holmes wrote:
>
> On 28/11/2018 5:46 pm, Thomas Stüfe wrote:
> > Are you sure?
>
> No. I'm completely confusing myself - too many different "thread id's" :(
A cheerful multitude :)
What throws me off usually is
call_run() not
> native_thread_entry().
>
> New bug being filed.
>
> Thanks,
> David
>
> On 28/11/2018 5:26 pm, David Holmes wrote:
> > Hi Thomas,
> >
> > On 28/11/2018 4:30 pm, Thomas Stüfe wrote:
> >> Hi David,
> >>
> >> I admit I
Hi David,
On Wed, Nov 28, 2018 at 8:26 AM David Holmes wrote:
>
> Hi Thomas,
>
> On 28/11/2018 4:30 pm, Thomas Stüfe wrote:
> > Hi David,
> >
> > I admit I still do not really get it..
> >
> > E.g. for GC threads:
> >
>
Hi David,
I admit I still do not really get it..
E.g. for GC threads:
We have
static ConcurrentMarkSweepThread*
ConcurrentMarkSweepThread::start(CMSCollector* collector);
which creates a ConcurrentMarkSweepThread and then calls
os::create_thread() to hook it up with an OSThread and start it.
Hi Matthias,
looks fine.
How did you find this, via Coverity?
... Thomas
On Tue, Nov 27, 2018 at 4:09 PM Baesken, Matthias
wrote:
>
> Hello, please review this small fix .
>
>
>
> In MacosxDebuggerLocal.m , at a few places the functions
> GetLongArrayElements and
an error or not) is actually wrong. For JVMTI, this
> seems to hold in terms of spec and implementation from what I see.
>
> Thanks,
> Jc
>
Thanks, Thomas
> [1]
> https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp16696
>
> On Mon, Nov 26, 2018 at
lid methodid.
>
> dl
>
Yes, I took the fact that JVMTI functions can return
JVMTI_ERROR_INVALID_METHODID to be a requirement that the VM must be
able to detect this, and therefore the jmethodid slot must not move or
be reused.
Thanks, Thomas
> On 11/26/18 11:33 AM, Thomas Stüfe wrote:
>
> H
Hey JC,
On Mon, Nov 26, 2018 at 8:15 PM JC Beyler wrote:
>
> Hi all,
>
> Just added my two cents on one comment:
>
> On Mon, Nov 26, 2018 at 5:00 AM Thomas Stüfe wrote:
>>
>> Hi Peter,
>>
>> On Mon, Nov 26, 2018 at 1:02 PM Peter Hull wrote:
>
Thanks Dan!
On Mon, Nov 26, 2018 at 3:54 PM Daniel D. Daugherty
wrote:
>
> On 11/26/18 8:07 AM, Thomas Stüfe wrote:
> > Hi guys,
> >
> > latest webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-th
, Nov 19, 2018 at 1:00 PM Thomas Stüfe wrote:
>
> Hi all,
>
> David and JC already outlined the options we have nicely.
>
> I'd like to add that I do not favor the ServiceThread delayed
> deliverance since a common reaction to ResourceExhausted would to
> print call sta
Hi Peter,
On Mon, Nov 26, 2018 at 1:02 PM Peter Hull wrote:
>
> Hi Thomas,
> Thank you very much for the detailed explanation. For your
> information, the relevant NetBeans bug is
> https://issues.apache.org/jira/browse/NETBEANS-1428
>
> On Sat, Nov 24, 2018 at 3:41 P
Okay, I created an RFE for this:
https://bugs.openjdk.java.net/browse/JDK-8214294
And for now I will prepare a new minimal patch based on our
discussions and post it shortly.
..Thomas
On Mon, Nov 26, 2018 at 12:28 PM David Holmes wrote:
>
> On 26/11/2018 6:58 pm, Thomas Stüfe wrote:
AM Thomas Stüfe wrote:
>
> On Mon, Nov 26, 2018 at 4:58 AM serguei.spit...@oracle.com
> wrote:
> >
> > Hi guys,
> >
> > On 11/25/18 06:17, Daniel D. Daugherty wrote:
> > > On 11/25/18 6:57 AM, David Holmes wrote:
> > >>
> > >>
>
t;> On 11/22/18 5:24 PM, David Holmes wrote:
> >>>> Hi Thomas,
> >>>>
> >>>> On 23/11/2018 2:16 am, Thomas Stüfe wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> would such a patch be acc
Hi Peter,
(adding serviceability)
A jmethodid is a pointer to malloc'ed memory.
In more detail, jmethodid points to a table slot containing pointers
to Method* objects, and that table itself lives in C heap. See class
JNIMethodBlock, JNIMethodBlockNode:
, I
would need to add a jvmti agent to jtreg, or adapt
jtreg/vmTestbase/nsk/jvmti?
Thanks, Thomas
On Thu, Nov 22, 2018 at 4:22 PM Daniel D. Daugherty
wrote:
>
> On 11/22/18 2:42 AM, David Holmes wrote:
> >
> >
> > On 22/11/2018 5:36 pm, Thomas Stüfe wrote:
> >> H
Hi JC,
On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote:
>
> Hi Thomas,
>
>
> I actually agree with not using the service thread to be honest, resource
> exhaustion seems to be something you'd want to know sooner than later.
>
> How about we do both?
> - Fix it now so that the compiler thread
t need to know
> the events in advance.
>
> I do believe that JFR already has events for some of the stuff you are
> logging, btw.
>
> Cheers,
> Mario
> On Wed, Nov 21, 2018 at 9:07 AM Thomas Stüfe wrote:
> >
> > Hi all,
> >
> > (I combine my rep
one would
> feel hard done by if your view prevailed and only the paying clients got
> access to a valuable feature.
>
>
> On Thu, Nov 15, 2018 at 9:40 AM Roger Riggs wrote:
>>
>> Hi,
>>
>> This looks like it has significant overlap with JFR.
>> I do
On Tue, Nov 20, 2018 at 11:38 AM David Holmes wrote:
>
> Hi Thomas,
>
> Thanks for taking a look at this.
>
> On 20/11/2018 8:20 pm, Thomas Stüfe wrote:
> > Hi David,
> >
> > out of interest, would pthread_getcpuclockid also crash when fed an
> > pthr
Hi David,
out of interest, would pthread_getcpuclockid also crash when fed an
pthread_t of an existing thread which has been suspended and not yet
started (on Solaris, AIX)? Not that it would have much to report :)
--
1643 // exclude externally visible JavaThreads
1644 if
Hi all,
David and JC already outlined the options we have nicely.
I'd like to add that I do not favor the ServiceThread delayed
deliverance since a common reaction to ResourceExhausted would to
print call stack of the thread running into it or to print a heap
histogram, as jvmkill does. For the
t rarely enough that I'd have to look up how
> to get this info on that host every time.
> $0.02
>
>
> On Wed, Nov 14, 2018 at 7:57 AM Thomas Stüfe wrote:
>>
>> Hi all,
>>
>> We have that feature in our port which we would like to contribute,
>> and I would
ages swapped in etc), they just refer then to a larger time
span.
Best Regards, Thomas
>
>
>
> --
> http://bernd.eckenfels.net
>
>
>
> Von: Thomas Stüfe
> Gesendet: Mittwoch, 14. November 2018 16:29
> An: serviceability-dev@openjdk.java.net serviceability-dev
ter proposal?
..Thomas
>
>
> On 11/14/18 10:06 AM, Daniel D. Daugherty wrote:
> > Adding serviceability-dev@...
> >
> > Since the proposed solution to the bug is to not post an event, I think
> > the Serviceability Team (which owns JVM/TI) needs to be involved dire
Thomas
>
> On Tue, Nov 13, 2018 at 11:03 PM Thomas Stüfe wrote:
>>
>> I did open a bug to track this:
>> https://bugs.openjdk.java.net/browse/JDK-8213834
>> On Wed, Nov 14, 2018 at 7:38 AM Thomas Stüfe wrote:
>> >
>> > On Wed, Nov 14, 2018 a
Hi all,
We have that feature in our port which we would like to contribute,
and I would like to gauge opinions.
First off, I am not sure which list is correct. This is more of a
serviceability issue, but implementation wise it fit hs-runtime
better. I'll start with serviceability, but feel free
I did open a bug to track this: https://bugs.openjdk.java.net/browse/JDK-8213834
On Wed, Nov 14, 2018 at 7:38 AM Thomas Stüfe wrote:
>
> On Wed, Nov 14, 2018 at 6:58 AM David Holmes wrote:
> >
> > On 14/11/2018 3:37 pm, Thomas Stüfe wrote:
> > > On Wed, Nov 1
On Wed, Nov 14, 2018 at 6:58 AM David Holmes wrote:
>
> On 14/11/2018 3:37 pm, Thomas Stüfe wrote:
> > On Wed, Nov 14, 2018, 06:32 David Holmes > <mailto:david.hol...@oracle.com> wrote:
> >
> > Hi Thomas,
> >
> > On 14/11/2018 6
(the fact that we post ResourceExhausted from
Compiler Thread) is older and also predates JVMCI. We see this also
with older VMs.
Thanks Thomas
On Wed, Nov 14, 2018 at 6:37 AM Chris Plummer wrote:
>
> On 11/13/18 9:32 PM, David Holmes wrote:
> > Hi Thomas,
> >
> > On 14
Hi all,
We have a client using CloudFoundry and its "jvmkill" agent. That is a
tiny JVMTI agent (see https://github.com/cloudfoundry/jvmkill) which
subscribes to the JVMTI ResourceExhausted Event. In the handler it
then does call JVMTI FollowReferences() to produce a heap histogram.
The thing
> new to add. We'd need a much more sophisticated scheme to allow the old
> "id's" to remain usable but invalid, whilst still allowing the tables to
> be reclaimed.
>
> Cheers,
> David
>
> On 9/11/2018 5:44 AM, Thomas Stüfe wrote:
> > Hi JC,
> >
> &g
dBlockNodes, which would amount to roughly 3 million jmethodid
handles...
> Thanks,
> Jc
>
Thanks for looking!
Best Regards, Thomas
>
>
> On Thu, Nov 8, 2018 at 12:02 AM Thomas Stüfe wrote:
>>
>> .. moving to serviceability - maybe you can help me.
>>
>>
.. moving to serviceability - maybe you can help me.
Thanks! Thomas
-- Forwarded message -
From: Thomas Stüfe
Date: Wed, Nov 7, 2018, 11:38
Subject: JNIMethodBlockNode leak question
To: Hotspot dev runtime
Hi all,
I wonder whether I understand this correctly:
When a caller
n the file just
> checks for <= 0; which also is weird since 0 just means end of file).
>
> Thanks,
> Jc
>
> On Tue, Sep 18, 2018 at 6:06 AM Thomas Stüfe
> wrote:
>>
>> Looks good. Thanks for fixing.
>>
>> ..Thomas
>>
>> On Tue, Sep 18, 20
Looks good. Thanks for fixing.
..Thomas
On Tue, Sep 18, 2018 at 1:52 PM, Jini George wrote:
> Hi all,
>
> Please review the small change for fixing the build failure in
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c with
> -Werror=unused-result.
>
>
Hi Ralf,
On Wed, Jul 4, 2018 at 3:47 PM, Schmelter, Ralf wrote:
> Hi Thomas,
>
> thank you for reviewing the change.
>
>
>> +/* Should not usually happen. */
>> +if (length != count) {
>> +error = JVMTI_ERROR_INTERNAL;
>> +}
>>
>> Cosmetics: I would also probably explicitly
--Original Message-
>> From: Alan Bateman [mailto:alan.bate...@oracle.com]
>> Sent: Mittwoch, 4. Juli 2018 13:43
>> To: Baesken, Matthias ; David Holmes
>> ; Thomas Stüfe
>> Cc: serviceability-dev (serviceability-dev@openjdk.java.net) > d...@openjdk.java.net>
t;
>
>
> Best regards, Matthias
>
>
>> -Original Message-
>> From: David Holmes [mailto:david.hol...@oracle.com]
>> Sent: Dienstag, 3. Juli 2018 23:26
>> To: Alan Bateman ; Thomas Stüfe
>>
>> Cc: Baesken, Matthias ; serviceability-dev
>>
> > From: Bob Vandette [mailto:bob.vande...@oracle.com]
> > Sent: Dienstag, 3. Juli 2018 16:03
> > To: Thomas Stüfe
> > Cc: serviceability-dev@openjdk.java.net serviceability-
> > d...@openjdk.java.net ; Baesken,
> > Matthias
> > Su
Hi Ralf,
patch looks good and makes sense.
Some remarks:
+/* Should not usually happen. */
+if (length != count) {
+error = JVMTI_ERROR_INTERNAL;
+}
Cosmetics: I would also probably explicitly return:
/* Should not usually happen. */
if (length != count) {
On Tue, Jul 3, 2018 at 6:49 PM, Alan Bateman wrote:
>
>
> On 03/07/2018 14:57, Baesken, Matthias wrote:
>
> I created a bug and a webrev , please review .
>
>
> https://bugs.openjdk.java.net/browse/JDK-8206145
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8206145/
Hi Bob,
It does look fine from the outside. I did not test it though, since I
have no suitable kernel.
Best Regards, Thomas
On Tue, Jul 3, 2018 at 3:13 PM, Bob Vandette wrote:
> Please review this small fix to correct a test failure when the Linux system
> kernel is
> not configured with the
Thank you Bob!
On Tue, Jul 3, 2018 at 2:59 PM, Bob Vandette wrote:
> Looks ok.
>
> Bob.
>
>> On Jul 3, 2018, at 5:15 AM, Thomas Stüfe wrote:
>>
>> Thank you David!
>>
>> I changed the webrev in place.
>>
>> Thanks, Thomas
>>
>>
Thank you David!
I changed the webrev in place.
Thanks, Thomas
On Tue, Jul 3, 2018 at 10:37 AM, David Holmes wrote:
> Hi Thomas,
>
> This seems okay.
>
> Minor nit:
>
> if(bigInt
>
> Please add a space after 'if'
>
> Thanks,
> David
>
>
> On 3/07/2
Hi all,
may I please have reviews for this small fix.
https://bugs.openjdk.java.net/browse/JDK-8206243
http://cr.openjdk.java.net/~stuefe/webrevs/8206243-java-xshowsettings-fails-for-large-values-of-memory-limit_in_bytes/webrev.00/webrev/
On some Linux kernels, the unlimited value of
Hi Alan,
Whether to repeat close() in case of EINTR seems to differ between
platforms. POSIX leaves it open:
"If close() is interrupted by a signal that is to be caught, it shall
return -1 with errno set to [EINTR] and the state of fildes is
unspecified."
Linux recommends *not* repeating the
+1. Please fix this for Linux! Thanks.
On Mon, Jul 2, 2018 at 11:03 AM, Langer, Christoph
wrote:
> Hi Matthias,
>
> forwarding to serviceability-dev, because debugging is usually discussed
> there.
>
> Yes, I would think this coding should be fixed, too. Can you open a bug and
> prepare a
On Wed, Jun 27, 2018 at 2:21 PM, David Holmes wrote:
> Hi Thomas,
>
>
> On 27/06/2018 10:13 PM, Thomas Stüfe wrote:
>>
>> Hi David,
>>
>> On Mon, Jun 25, 2018 at 7:48 AM, David Holmes
>> wrote:
>>>
>>> Hi Thomas,
>>>
>
Hi David,
On Mon, Jun 25, 2018 at 7:48 AM, David Holmes wrote:
> Hi Thomas,
>
>
> On 23/06/2018 5:10 AM, Thomas Stüfe wrote:
>>
>> Resent with the correct subject, sorry.
>>
>> ..Thomas
>>
>> On Fri, Jun 22, 2018 at 9:08 PM, Thomas Stüfe
>
On Tue, Jun 26, 2018 at 7:06 PM, Thomas Stüfe wrote:
> Hi Daniel,
>
> test if I understand this correctly:
>
> The original bug: we execute
> NestedThreadsListHandleInErrorHandlingTest, which is supposed to
> controlled-crash the VM and find SMR related info in hs-err fil
eview Serguei!
>
> One more review would be nice... David H. or Thomas Stüfe?
>
>
> On 6/26/18 12:12 PM, serguei.spit...@oracle.com wrote:
>>
>> Hi Dan,
>>
>> The fix looks reasonable to me.
>
>
> Thanks. I like simple one liners... :-)
>
>
&
We have a cheerful multitude of syntaxes for sub options:
some use words without leading dashes:
Compiler.CodeHeap_Analytics
VM.metaspace
VM.classloaders
ManagementAgent.start
VM.native_memory
e.g. VM.metaspace show-classes, VM.classloaders verbose
some use words with dashes (-all, -verbose)
1 - 100 of 224 matches
Mail list logo
