[RFR]8215623: Add incremental dump for jmap histo
Hi All, May I ask your help to review this patch for enhance jmap �Chisto. It adds the “incremental” arguments that allow jmap �Chisto to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin
[RFR]8215622: Add dump to file support for jmap histo
Hi All, May I ask your help to review this patch for enhance jmap �Chisto. It add the “file=” arguments that allow jmap �Chisto outputs data to file directly. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks. BRs, Lin
Re: RFR 8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
On 21/12/2018 7:30 am, Harold David Seigel wrote:
Hi David,
Thanks for looking at this!
Please review this updated webrev. The fix is the same but the webrev
contains a new test instead of modifying an existing test:
http://cr.openjdk.java.net/~hseigel/bug_8215398.2/webrev/
I think renaming the existing test would be better as the only
difference is the use of quotes. But if you want a new test please add:
@bug 8215398
The logging implementation does not handle single quotes as expected.
For example, if the TestQuotedLogOutputs.java test is changed to use
single quotes instead of double quotes, it will fail, even on Linux,
because the single quotes are included as part of the file name. They
are not stripped off. That is why "java
-Xlog:safepoint=trace:'d:\safepointtrace.txt' -version" fails.
It fails with double-quotes too! AFAICS it always fails in a Windows
command shell. Maybe the test only passes in cygwin shell?
That said I don't understand your comment. I expect the quotes to
delimit the filename in case the filename has spaces in the path
component. If they aren't stripped off it wouldn't be tokenizing at the
internal ":", so ... ???
Thanks,
David
Perhaps a new bug is needed to change logging's handling of single
quotes? It's a bit surprising that this issue hasn't already been reported.
Thanks, Harold
On 12/20/2018 2:07 AM, David Holmes wrote:
Hi Harold,
On 19/12/2018 11:22 pm, Harold David Seigel wrote:
Hi,
Please review this small change to fix JDK-8215398. The fix works by
not treating ':' as a delimiter in a -Xlog... option string if it is
following by a '\' and preceded by either a single character or the
text 'file='. The fix is for Windows only.
Open Webrev:
http://cr.openjdk.java.net/~hseigel/bug_8215398/webrev/index.html
I think I can follow the fix.
But I'm a bit concerned about the test. AFAICS the test thought it was
already testing this case - albeit with the path quoted:
42 // Ensure log files can be specified with full path.
43 // On windows, this means that the file name will contain
44 // a colon ('C:\log.txt' for example), which is used to
45 // separate -Xlog: options (-Xlog:tags:filename:decorators).
46 // Try to log to a file in our current directory, using
its absolute path.
47 String baseName = "test file.log";
48 Path filePath = Paths.get(baseName).toAbsolutePath();
49 String fileName = filePath.toString();
50 File file = filePath.toFile();
...
65 String[] validOutputs = new String[] {
66 quote + fileName + quote,
67 "file=" + quote + fileName + quote,
68 quote + fileName + quote + ":",
69 quote + fileName + quote + "::"
70 };
But even quoted if I specify the drive designator in the path, it
fails! Here's a local attempt at this:
D:\ade> apps\Java\jdk-11\fastdebug\bin\java
-Xlog:safepoint=trace:'d:\safepointtrace.txt' -version
[0.014s][error][logging] Invalid decorator '\safepointtrace.txt''.
Invalid -Xlog option '-Xlog:safepoint=trace:'d:\safepointtrace.txt'',
see error log for details.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
So AFAICS the test can't possibly have been testing what it thought it
was testing! ???
I'm also not sure about just adding some unquoted variants to the
existing TestQuotedLogOutputs without renaming the test and updating
the @summary
Thanks,
David
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215398
The fix was regression tested by running Mach5 tiers 1 and 2 tests
and builds on Linux-x64, Windows, and Mac OS X, running tiers 3-5
tests on Linux-x64, running JCK-12 Lang and VM tests on Linux-x64,
and by hand on Windows.
Thanks, Harol
Re: RFR 8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
Hi Harold,
It looks good to me.
Thanks,
Serguei
On 12/20/18 1:30 PM, Harold David Seigel wrote:
Hi David,
Thanks for looking at this!
Please review this updated webrev. The fix is the same but the webrev
contains a new test instead of modifying an existing test:
http://cr.openjdk.java.net/~hseigel/bug_8215398.2/webrev/
The logging implementation does not handle single quotes as expected.
For example, if the TestQuotedLogOutputs.java test is changed to use
single quotes instead of double quotes, it will fail, even on Linux,
because the single quotes are included as part of the file name. They
are not stripped off. That is why "java
-Xlog:safepoint=trace:'d:\safepointtrace.txt' -version" fails.
Perhaps a new bug is needed to change logging's handling of single
quotes? It's a bit surprising that this issue hasn't already been
reported.
Thanks, Harold
On 12/20/2018 2:07 AM, David Holmes wrote:
Hi Harold,
On 19/12/2018 11:22 pm, Harold David Seigel wrote:
Hi,
Please review this small change to fix JDK-8215398. The fix works
by not treating ':' as a delimiter in a -Xlog... option string if it
is following by a '\' and preceded by either a single character or
the text 'file='. The fix is for Windows only.
Open Webrev:
http://cr.openjdk.java.net/~hseigel/bug_8215398/webrev/index.html
I think I can follow the fix.
But I'm a bit concerned about the test. AFAICS the test thought it
was already testing this case - albeit with the path quoted:
42 // Ensure log files can be specified with full path.
43 // On windows, this means that the file name will contain
44 // a colon ('C:\log.txt' for example), which is used to
45 // separate -Xlog: options
(-Xlog:tags:filename:decorators).
46 // Try to log to a file in our current directory, using
its absolute path.
47 String baseName = "test file.log";
48 Path filePath = Paths.get(baseName).toAbsolutePath();
49 String fileName = filePath.toString();
50 File file = filePath.toFile();
...
65 String[] validOutputs = new String[] {
66 quote + fileName + quote,
67 "file=" + quote + fileName + quote,
68 quote + fileName + quote + ":",
69 quote + fileName + quote + "::"
70 };
But even quoted if I specify the drive designator in the path, it
fails! Here's a local attempt at this:
D:\ade> apps\Java\jdk-11\fastdebug\bin\java
-Xlog:safepoint=trace:'d:\safepointtrace.txt' -version
[0.014s][error][logging] Invalid decorator '\safepointtrace.txt''.
Invalid -Xlog option '-Xlog:safepoint=trace:'d:\safepointtrace.txt'',
see error log for details.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
So AFAICS the test can't possibly have been testing what it thought
it was testing! ???
I'm also not sure about just adding some unquoted variants to the
existing TestQuotedLogOutputs without renaming the test and updating
the @summary
Thanks,
David
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215398
The fix was regression tested by running Mach5 tiers 1 and 2 tests
and builds on Linux-x64, Windows, and Mac OS X, running tiers 3-5
tests on Linux-x64, running JCK-12 Lang and VM tests on Linux-x64,
and by hand on Windows.
Thanks, Harol
Re: RFR JDK-8215716: PopFrame() was unexpectedly done
Hi Alex, LG++ Thanks, Serguei On 12/20/18 5:09 PM, David Holmes wrote: Looks good. Thanks, David On 21/12/2018 11:04 am, Alex Menkov wrote: Hi all, please review a small fix for https://bugs.openjdk.java.net/browse/JDK-8215716 webrev: http://cr.openjdk.java.net/~amenkov/popframe004/webrev.01/ The failure is caused by race condition - main test thread calls PopFrame expecting that test thread is in the activeMethod method. But logging (System.out.println call) is performed after main frame is notified that test thread is ready to be popped. More general --alex
Re: RFR JDK-8215716: PopFrame() was unexpectedly done
Looks good. Thanks, David On 21/12/2018 11:04 am, Alex Menkov wrote: Hi all, please review a small fix for https://bugs.openjdk.java.net/browse/JDK-8215716 webrev: http://cr.openjdk.java.net/~amenkov/popframe004/webrev.01/ The failure is caused by race condition - main test thread calls PopFrame expecting that test thread is in the activeMethod method. But logging (System.out.println call) is performed after main frame is notified that test thread is ready to be popped. More general --alex
RFR JDK-8215716: PopFrame() was unexpectedly done
Hi all, please review a small fix for https://bugs.openjdk.java.net/browse/JDK-8215716 webrev: http://cr.openjdk.java.net/~amenkov/popframe004/webrev.01/ The failure is caused by race condition - main test thread calls PopFrame expecting that test thread is in the activeMethod method. But logging (System.out.println call) is performed after main frame is notified that test thread is ready to be popped. More general --alex
Re: RFR 8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'.
Hi David,
Thanks for looking at this!
Please review this updated webrev. The fix is the same but the webrev
contains a new test instead of modifying an existing test:
http://cr.openjdk.java.net/~hseigel/bug_8215398.2/webrev/
The logging implementation does not handle single quotes as expected.
For example, if the TestQuotedLogOutputs.java test is changed to use
single quotes instead of double quotes, it will fail, even on Linux,
because the single quotes are included as part of the file name. They
are not stripped off. That is why "java
-Xlog:safepoint=trace:'d:\safepointtrace.txt' -version" fails.
Perhaps a new bug is needed to change logging's handling of single
quotes? It's a bit surprising that this issue hasn't already been reported.
Thanks, Harold
On 12/20/2018 2:07 AM, David Holmes wrote:
Hi Harold,
On 19/12/2018 11:22 pm, Harold David Seigel wrote:
Hi,
Please review this small change to fix JDK-8215398. The fix works by
not treating ':' as a delimiter in a -Xlog... option string if it is
following by a '\' and preceded by either a single character or the
text 'file='. The fix is for Windows only.
Open Webrev:
http://cr.openjdk.java.net/~hseigel/bug_8215398/webrev/index.html
I think I can follow the fix.
But I'm a bit concerned about the test. AFAICS the test thought it was
already testing this case - albeit with the path quoted:
42 // Ensure log files can be specified with full path.
43 // On windows, this means that the file name will contain
44 // a colon ('C:\log.txt' for example), which is used to
45 // separate -Xlog: options (-Xlog:tags:filename:decorators).
46 // Try to log to a file in our current directory, using
its absolute path.
47 String baseName = "test file.log";
48 Path filePath = Paths.get(baseName).toAbsolutePath();
49 String fileName = filePath.toString();
50 File file = filePath.toFile();
...
65 String[] validOutputs = new String[] {
66 quote + fileName + quote,
67 "file=" + quote + fileName + quote,
68 quote + fileName + quote + ":",
69 quote + fileName + quote + "::"
70 };
But even quoted if I specify the drive designator in the path, it
fails! Here's a local attempt at this:
D:\ade> apps\Java\jdk-11\fastdebug\bin\java
-Xlog:safepoint=trace:'d:\safepointtrace.txt' -version
[0.014s][error][logging] Invalid decorator '\safepointtrace.txt''.
Invalid -Xlog option '-Xlog:safepoint=trace:'d:\safepointtrace.txt'',
see error log for details.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
So AFAICS the test can't possibly have been testing what it thought it
was testing! ???
I'm also not sure about just adding some unquoted variants to the
existing TestQuotedLogOutputs without renaming the test and updating
the @summary
Thanks,
David
JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215398
The fix was regression tested by running Mach5 tiers 1 and 2 tests
and builds on Linux-x64, Windows, and Mac OS X, running tiers 3-5
tests on Linux-x64, running JCK-12 Lang and VM tests on Linux-x64,
and by hand on Windows.
Thanks, Harol
Re: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions
Wow, the existing comments for this
function take a lot of work to translate. You basically need to
understand the code in order to understand the comment. Kind of
backwards. Below I've included all the existing code and comments,
with my translation of the comments and also additional
annotations.
But before getting into that, I think the proposed fix is just
working around all the bugs elsewhere in the function by making
opt point to a string that just contains the current option we are
working on, rather than attempting (poorly and incorrectly) to
point to the next option within the options string. Although
tokenizing the string in this way is probably the better approach,
it would be nice to at the same time clean up all the other errors
and comments in this code.
/**
*
* The current option will not perform more than one
* single option which given, this is due to places explained
* in this question.
*
**/
# This current implementation will not parse more than one option.
The
# reason is explained in comments below.
/*
* This whole play can be reduced with simple StringTokenizer
(strtok).
*
*/
# This function can be simplified by using strok().
int nsk_jvmti_parseOptions(const char options[]) {
size_t len;
const char* opt;
int success = NSK_TRUE;
context.options.string = NULL;
context.options.count = 0;
context.waittime = 2;
if (options == NULL)
return NSK_TRUE;
len = strlen(options);
context.options.string = (char*)malloc(len + 2);
if (context.options.string == NULL) {
nsk_complain("nsk_jvmti_parseOptions(): out of
memory\n");
return NSK_FALSE;
}
strncpy(context.options.string, options, len);
context.options.string[len] = '\0';
context.options.string[len+1] = '\0';
for (opt = context.options.string; ;) {
const char* opt_end;
const char* val_sep;
int opt_len=0;
int val_len=0;
int exit=1;
while (*opt != '\0' && isOptSep(*opt)) opt++;
if (*opt == '\0') break;
val_sep = NULL;
/*
This should break when the first option it encounters
other wise
*/
# This should break at the end of the first option, before the
option value is specified
# if there is an option value.
for (opt_end = opt, opt_len=0; !(*opt_end == '\0' ||
isOptSep(*opt_end)); opt_end++,opt_len++) {
if (*opt_end == NSK_JVMTI_OPTION_VAL_SEP) {
val_sep = opt_end;
exit=0;
break;
}
}
if (exit == 1) break;
/* now scan for the search for the option value end.
*/
# Now scan for the end of the option value.
[Chris: This is a bug because it assumes that there is a value. If
we stopped in the above
loop due to finding the option separator (which also seems to be
broken), then we start
reading the next option as the option value.]
exit =1;
opt_end++;
val_sep++;
/**
* I was expecting this jvmti_parseOptions(),
* should be for multiple options as well.
* If this break is not there then It will expects
* to have. so a space should be sufficient as well.
*/
# I was expecting that nsk_jvmti_parseOptions() would parse
multiple options.
[Chris: I have no idea what the rest of the comment means. Due to
the bug above
with handling an option with no value, the code below doesn't do
what was expected.
The commented out part of it tried to do the right thing by
searching for the '-' for the
next option, whichis wrong because options don't begin with a '\'.
They are separated
by a comma, although the code elsewhere wants them separated by a
space or a `~`.]
for (val_len=0; !(*opt_end == '\0' || isOptSep(*opt_end));
opt_end++,val_len++) {
//if (*opt_end == NSK_JVMTI_OPTION_START) {
// break;
//}
}
if (!add_option(opt, opt_len, val_sep, val_len)) {
success = NSK_FALSE;
break;
}
opt_end++;
opt = opt_end;
}
On 12/20/18 8:33 AM, Gary Adams wrote:
Re: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions
I prototyped with strsep, because strtok is not safe
and did not want to deal with the strtok_r versus
strtok_s (windows) platform variants.
...
#include
#include
int main(int argc, char **argv){
char *str = strdup("waittime=5,verbose foo bar baz=11");
char *name;
char *value;
while ((name = strsep (&str, " ,")) != NULL) {
value = index(name, '=');
if (value == NULL) {
printf ("%s\n", name);
} else {
*value++ = '\0';
printf ("%s=%s\n", name, value);
}
}
...
./main
waittime=5
verbose
foo
bar
baz=11
On 12/20/18, 10:54 AM, JC Beyler wrote:
Hi Gary,
I had seen that too and forgot to file it! So thanks!
I think the comment you removed is interesting, I'm not sure what it
means exactly and I've tried re-reading a few times but the use of "in
this question" is weird :-)
Anyway, the webrev looks good except perhaps for the use of strsep,
which is BSD, instead of strtok, which is C89/C99/Posix.
Thanks for doing this!
Jc
On Thu, Dec 20, 2018 at 5:17 AM Gary Adams > wrote:
During some earlier jvmti test debugging, I noticed that it was not
possible to
add a quick argument to the current tests and rerun the test. e.g.
expand "waittime=5" to
"waittime=5,verbose". I tracked down the options parsing in
jvmti_tools.cpp and saw some
comments that only a single option could be parsed.
So I filed this bug to revisit the issue for the next release:
Issue: https://bugs.openjdk.java.net/browse/JDK-8211343
I think the option parsing should be ripped out and redone,
but for now I think a simple tweak to use strsep(), might go a
long way
to solving the multiple option support. I just started testing,
but wanted to know if anyone else has been down this rabbit hole
before.
diff --git
a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
--- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
+++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
@@ -196,22 +196,14 @@
}
-/**
- *
- * The current option will not perform more than one
- * single option which given, this is due to places explained
- * in this question.
- *
- **/
-
/*
- * This whole play can be reduced with simple StringTokenizer
(strtok).
- *
+ * Parse a comma or space separated list of options.
*/
int nsk_jvmti_parseOptions(const char options[]) {
size_t len;
const char* opt;
+char *str = strdup(options);
int success = NSK_TRUE;
context.options.string = NULL;
@@ -232,7 +224,7 @@
context.options.string[len] = '\0';
context.options.string[len+1] = '\0';
-for (opt = context.options.string; ;) {
+while ((opt = strsep(&str, " ,")) != NULL) {
const char* opt_end;
const char* val_sep;
int opt_len=0;
--
Thanks,
Jc
Re: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions
Hi Gary,
I had seen that too and forgot to file it! So thanks!
I think the comment you removed is interesting, I'm not sure what it means
exactly and I've tried re-reading a few times but the use of "in this
question" is weird :-)
Anyway, the webrev looks good except perhaps for the use of strsep, which
is BSD, instead of strtok, which is C89/C99/Posix.
Thanks for doing this!
Jc
On Thu, Dec 20, 2018 at 5:17 AM Gary Adams wrote:
> During some earlier jvmti test debugging, I noticed that it was not
> possible to
> add a quick argument to the current tests and rerun the test. e.g.
> expand "waittime=5" to
> "waittime=5,verbose". I tracked down the options parsing in
> jvmti_tools.cpp and saw some
> comments that only a single option could be parsed.
>
> So I filed this bug to revisit the issue for the next release:
>
>Issue: https://bugs.openjdk.java.net/browse/JDK-8211343
>
> I think the option parsing should be ripped out and redone,
> but for now I think a simple tweak to use strsep(), might go a long way
> to solving the multiple option support. I just started testing,
> but wanted to know if anyone else has been down this rabbit hole
> before.
>
>
> diff --git
> a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
> b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
> @@ -196,22 +196,14 @@
> }
>
>
> -/**
> - *
> - * The current option will not perform more than one
> - * single option which given, this is due to places explained
> - * in this question.
> - *
> - **/
> -
>/*
> - * This whole play can be reduced with simple StringTokenizer (strtok).
> - *
> + * Parse a comma or space separated list of options.
> */
>
> int nsk_jvmti_parseOptions(const char options[]) {
> size_t len;
> const char* opt;
> +char *str = strdup(options);
> int success = NSK_TRUE;
>
> context.options.string = NULL;
> @@ -232,7 +224,7 @@
> context.options.string[len] = '\0';
> context.options.string[len+1] = '\0';
>
> -for (opt = context.options.string; ;) {
> +while ((opt = strsep(&str, " ,")) != NULL) {
> const char* opt_end;
> const char* val_sep;
> int opt_len=0;
>
>
--
Thanks,
Jc
Re: RFR: JDK-8215571: jdb does not include jdk.* in the default class filter
Looks good. I've been using it for a while now with no issues.
Chris
On 12/20/18 4:52 AM, Gary Adams wrote:
This should be a trivial update.
The default "excludes" filter for jdb
should have been updated when the jdk.* packages were first introduced.
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -108,7 +108,7 @@
static private List excludes() {
if (excludes == null) {
- setExcludes("java.*, javax.*, sun.*, com.sun.*");
+ setExcludes("java.*, javax.*, sun.*, com.sun.*, jdk.*");
}
return excludes;
}
JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions
During some earlier jvmti test debugging, I noticed that it was not
possible to
add a quick argument to the current tests and rerun the test. e.g.
expand "waittime=5" to
"waittime=5,verbose". I tracked down the options parsing in
jvmti_tools.cpp and saw some
comments that only a single option could be parsed.
So I filed this bug to revisit the issue for the next release:
Issue: https://bugs.openjdk.java.net/browse/JDK-8211343
I think the option parsing should be ripped out and redone,
but for now I think a simple tweak to use strsep(), might go a long way
to solving the multiple option support. I just started testing,
but wanted to know if anyone else has been down this rabbit hole
before.
diff --git
a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
--- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
+++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp
@@ -196,22 +196,14 @@
}
-/**
- *
- * The current option will not perform more than one
- * single option which given, this is due to places explained
- * in this question.
- *
- **/
-
/*
- * This whole play can be reduced with simple StringTokenizer (strtok).
- *
+ * Parse a comma or space separated list of options.
*/
int nsk_jvmti_parseOptions(const char options[]) {
size_t len;
const char* opt;
+char *str = strdup(options);
int success = NSK_TRUE;
context.options.string = NULL;
@@ -232,7 +224,7 @@
context.options.string[len] = '\0';
context.options.string[len+1] = '\0';
-for (opt = context.options.string; ;) {
+while ((opt = strsep(&str, " ,")) != NULL) {
const char* opt_end;
const char* val_sep;
int opt_len=0;
Re: RFR: JDK-8215571: jdb does not include jdk.* in the default class filter
On 20/12/2018 12:52, Gary Adams wrote: This should be a trivial update. The default "excludes" filter for jdb should have been updated when the jdk.* packages were first introduced. This looks okay to me. One thing to mention is that produce a more accurate exclude filter from the packages of the modules in the run-time image. That would allow it work with libraries on the class path with javax.* APIs for example. -Alan
RFR: JDK-8215571: jdb does not include jdk.* in the default class filter
This should be a trivial update.
The default "excludes" filter for jdb
should have been updated when the jdk.* packages were first introduced.
diff --git
a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
--- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
+++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -108,7 +108,7 @@
static private List excludes() {
if (excludes == null) {
-setExcludes("java.*, javax.*, sun.*, com.sun.*");
+setExcludes("java.*, javax.*, sun.*, com.sun.*, jdk.*");
}
return excludes;
}
