se/nsk/jvmti/)
>
> A regression test may be possible if we call GetThreadGroupChildren in a
> loop, whilst threads add and remove themselves from the group
> concurrently. But it is awkward to write.
>
> Thanks,
> David
>
> Thanks,
> David
--
Dmitry Samersoff
http://devnull.samersoff.net
* There will come soft rains ...
signature.asc
Description: OpenPGP digital signature
other tests I think that know they aren't going to work, just print
>> a message and return from main, they don't count this as a failure.
>> I'll leave that for you to decide!...
>>
>> Thanks Kevin
>>
>>
>> On 11/02/2015 10:41, Dmitry Sam
t/~poonam/8046282/webrev.00/
>
> Thanks,
> Poonam
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
ong term. I've been discussing this with Red Hat's GDB
> group and I'm hoping to come up with a proposal and hopefully some
> working code.
>
> Andrew.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
perations manage to get enqueued, but not processed until
> another thread eventually signals the semaphore by posting another op.
>
> We must allow the semaphore to stay signaled when multiple ops are enqueued -
> and since we only allow preallocate_count number of operations to b
reate that
> symlink, but the tools need to protect themselves from this kind of
> problem.
>
> Testing was manual.
>
> bug
> https://bugs.openjdk.java.net/browse/JDK-8073688
>
> webrev
> http://cr.openjdk.java.net/~kevinw/8073688/webrev.00/
>
> Thanks
> Kevi
074842
> webrev: http://cr.openjdk.java.net/~sla/8074841/webrev.00/
>
> Thanks,
> /Staffan
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Hi Everyone,
Please review small, test only fix.
http://cr.openjdk.java.net/~dsamersoff/JDK-8075569/webrev.01/
Lock deleted while we are setting last modified time.
Ignore error and lets the app exits
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I
Alan,
Thank you for the review.
I agree that File.exists is no longer required, but I would prefer to
keep it for better readability.
-Dmitry
On 2015-03-21 13:57, Alan Bateman wrote:
> On 21/03/2015 10:50, Dmitry Samersoff wrote:
>> Hi Everyone,
>>
>> Please review
Everybody,
Please review a small fix.
The fix goes to 9 and 8u at the same time.
http://cr.openjdk.java.net/~dsamersoff/JDK-8068007/webrev.01/
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give m
David,
On 2015-04-02 14:45, David Holmes wrote:
> Hi Dmitry,
>
> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review a small fix.
>>
>> The fix goes to 9 and 8u at the same time.
>>
>> http://cr.openjdk.java.net
Fix updated.
On 2015-04-02 15:05, Dmitry Samersoff wrote:
> David,
>
>
> On 2015-04-02 14:45, David Holmes wrote:
>> Hi Dmitry,
>>
>> On 2/04/2015 9:27 PM, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please review a small fix.
>&g
Jaroslav,
Thank you!
-Dmitry
On 2015-04-02 15:45, Jaroslav Bachorik wrote:
> On 2.4.2015 14:35, Dmitry Samersoff wrote:
>> Fix updated.
>
> I like this better. Still rather convoluted but it seems to be as good
> as we can get without a bigger rewrite.
>
> I'm ok
Everybody,
Please review a small fix:
The fix goes to 9 and 8u at the same time.
http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.01/
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give m
Everybody,
Please, review updated webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8067991/webrev.02/
Fixed a compilation error that wasn't caught during incremental build.
-Dmitry
On 2015-04-02 15:54, Dmitry Samersoff wrote:
> Everybody,
>
> Please review a small fix:
>
n the
> agent/src/share/classes/com/sun/java/swing/ui/CommonUI.java
>
> +public static Dimension getButtonPrefSize()
> +{
> +return buttonPrefSize;
> +}
>
> =>
>
> +public static Dimension getButtconPrefSize()
> +{
> +return buttconPr
Serguei,
Thanks!
-Dmitry
On 2015-04-04 11:58, serguei.spit...@oracle.com wrote:
> Dmitry,
>
> I think, no re-review is necessary after fixing this typo.
> You had addressed the review comments.
>
> Thanks,
> Serguei
>
> On 4/4/15 12:06 AM, Dmitry Samersoff wrote:
cle Solaris 10 8/11 s10s_u10wos_17b SPARC
> Oracle Solaris 11.1 X86
> Oracle Solaris 11.2 X86
>
> I found a similar issue in the JDK bug system (JDK-8044416), but the
> last update there stated that JDK-8044416 "is about the -F
> functionality" and to "pl
mitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Jaroslav,
Thank you!
Nits fixed in-place (press shift-reload)
-Dmitry
On 2015-04-09 19:12, Jaroslav Bachorik wrote:
> Hi Dmitry,
>
> Indentation should be 4 spaces.
> Copyright year will need update.
>
> Otherwise looks good!
>
> -JB-
>
> On 9.4.2015
Roland,
Looks good to me.
-Dmitry
On 2015-04-15 12:48, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8077832/webrev.00/
>
> I found 3 locations where the SA code is out of sync with the hotspot code.
>
> Roland.
>
--
Dmitry Samersoff
Oracle Java devel
verify the read fails"
So I decide to go with the surgery rather than a therapy and cut out
this test case entirely.
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
("sa.properties");
>> + if (VM.class.getClassLoader() == null) {
>> + url = ClassLoader.getSystemResource("sa.properties");
>> + }
>> + else {
>> + url = VM.class.getClassLoader().getResource("sa.properties");
._symbol_mask));
>}
>
> I'm not at all sure this is the right place to fix it, but it works.
>
> I'm just really surprised no-one noticed this before.
>
> Andrew.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Everyone,
Please review the fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.01/
heap dcmd outputs the same information as SIGBREAK
finalizerinfo dcmd outputs a list of all classes in finalization queue
with count
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint
uldn't be controversial at this point.
>
> Thanks,
> Andrew.
>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
t; exception if something like this happens again.
>
> webrev: http://cr.openjdk.java.net/~sla/8079360/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8079360
>
> Thanks,
> /Staffan
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I woul
; The fix makes sure the HprofParser is available for all types of test
> frameworks, not only JTreg. It will be a part of test-lib.jar.
>
> Thanks,
> Katja
>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
public
-Dmitry
On 2015-05-06 17:36, Andrew Haley wrote:
> On 04/29/2015 08:42 AM, Andrew Haley wrote:
>>
>> http://cr.openjdk.java.net/~aph/8078521-2/
>
> Any news on this? It shouldn't be controversial at this point.
>
> Thanks,
> Andrew.
>
>
bug is actually already solved. But I'll use it as an opportunity
> to re-write the test using test library. There is no need to retrieve a
> free port since the error occurs before binding to the address.
>
> Thanks,
> Katja
--
Dmitry Samersoff
Oracle Java development team
list may be interesting if one wants to know how many live +
>> finalization pending instances are there on the heap that override
>> finalize() method.
>>
>> Regards, Peter
>>
>>>
>>> For the output, it would be a nice touch to sort it on the numb
njdk.java.net/browse/JDK-8075773. I have built and
> tested JDK9 with fix successfully. As I do not have an account for OpenJDK,
> David Buck will push the fix into jdk9/hs-rt/.
>
> Web review link: http://cr.openjdk.java.net/~dbuck/8075773/webrev.01/
>
> Regards,
> Cheleswe
thological scenarios where this gets severe. This is
>> unfortunate but not uncommon. There is enough complication here that
>> you should be sure that the fix for diagnostics performance doesn't
>> introduce subtle bugs to the system in general. A change in this area
>&g
aken might
> return 0 or just a few elements when there are millions there in the
> queue. When scanner finally gets a head start, it will usually lead the
> race to the end.
>
> Peter
>
>>
>> Does this make more sense now?
>>
>> Regards, Peter
>&g
we know threads are "jumpy" so it will happen quite frequently that a
> poller jumps before scanner. So just giving-up when overtaken might
> return 0 or just a few elements when there are millions there in the
> queue. When scanner finally gets a head start, it will usually lead t
nQueue)... You could just expose
>>>>> a package-private forEach static method from Finalizer and code the
>>>>> rest in DiagnosticCommands.
>>>> That's good for encapsulation. But I'm concerned that if "forEach"
>>>> got ex
SS_SIZE
69,73 - please, remove space after bracket.
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
):
>>>
>>> - to process directory entries in a directory that is writable
>>> which makes this use subject to a symlink or hard link attack.
>>> - to process directory entries in a directory that the calling
>>> user does not own; the intent of the
PM, Peter Levart wrote:
>>
>>
>> On 05/16/2015 09:35 AM, Dmitry Samersoff wrote:
>>> Derek,
>>>
>>> Personally, I'm for volatile over explicit fence too.
>>>
>>> So I'll change the code if Peter don't have objections.
>&
Andrew,
Looks good for me. (not a Reviewer)
> This will now enable the code for PPC; I guess that's OK.
I think so too.
-Dmitry
On 2015-05-19 18:20, Andrew Haley wrote:
> On 05/16/2015 06:03 PM, Dmitry Samersoff wrote:
>> Andrew,
>>
>> On 2015-05-12 20:05,
implementation. Just to
> give you a quick comment. I’m okay to add ReferenceQueue.forEach method
> at the first glance. However I have trouble for
> Finalizer.printFinalizationQueue method that doesn’t belong there. What
> are the other alternatives you have explored?
>
> Mand
On 2015-05-20 11:22, Peter Levart wrote:
>
>
> On 05/20/2015 08:51 AM, Dmitry Samersoff wrote:
>> Mandy,
>>
>>> However I have trouble for
>>> Finalizer.printFinalizationQueue method that doesn’t belong there.
>>> What are the other alternatives you ha
>
> On 05/20/2015 10:42 AM, Dmitry Samersoff wrote:
>> Peter,
>>
>>> What about creating a special package-private
>>> java.lang.ref.DiagnosticCommands class
>> I'm not quite happy with current printFinalizationQueue method - love to
>> have a way to
tput of this command
should be covered by GC tests, more complicated than this one, because
actual output depends to GC and heap parameters.
I can just check for presence of "Metaspace" world in the DCMD output.
-Dmitry
>
>
> /Staffan
>
>
>> On 18 maj 2015,
On 2015-05-21 02:07, Mandy Chung wrote:
>
>> On May 19, 2015, at 11:51 PM, Dmitry Samersoff
>> mailto:dmitry.samers...@oracle.com>> wrote:
>>
>> Other alternatives could be to do all hashing/sorting/printing on native
>> layer i.e. implement printFinaliza
Hi Everybody,
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.09/
Please review updated webrev -
printFinalizationQueue now returns and array of Map.Entry
>> On May 19, 2015, at 11:51 PM, Dmitry Samersoff
>> mailto:dmitry.samers...@oracle.com>> wrote:
>>
>
dlock."
>
> The solutions is to start a separate target process. Dmitry Samersoff
> has already created a test application for such cases so I've decided to
> move it on the top level library instead of duplicating it. The test
> application will reside under test/lib/sha
ram?). Can you move
> this method to the end of this class and add the comment saying that
> this is invoked by VM for jcmd -finalizerinfo support and @return to
> describe the returned content. I also think you can remove
> @SuppressWarnings for this method.
>
> Mandy
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Klass::find_field and fieldDescriptor::offset to find the offset at
> runtime.
>
> Thanks,
> /Staffan
>
>> On 31 maj 2015, at 13:43, Dmitry Samersoff
>> wrote:
>>
>> Everyone,
>>
>> Please take a look at new version of the fix.
>>
>
> Hi Dmitry,
>
> On 2015-06-02 13:12, Dmitry Samersoff wrote:
>> Staffan,
>>
>>> Instead of hardcoding the field offsets, you can use
>>> InstanceKlass::find_field and fieldDescriptor::offset to find the
>>> offset at runtime.
>>
>> D
09:06, Peter Levart wrote:
> Hi Dmitry,
>
> On 06/02/2015 01:12 PM, Dmitry Samersoff wrote:
>> Staffan,
>>
>>> Instead of hardcoding the field offsets, you can use
>>> InstanceKlass::find_field and fieldDescriptor::offset to find the
>>&g
Everyone,
Updated webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.13
Changes to oop.inline.hpp is reverted and find_field used directly is
diagnostic command.
-Dmitry
On 2015-06-03 11:48, Dmitry Samersoff wrote:
> Everyone,
>
> Updated webrev:
vmSymbols looks like:
template(
get_finalizer_histogram_name, "getFinalizerHistogram")
I would prefer to keep method name specific enough to be able to
find it by grep in jdk code.
(other comments are addressed)
-Dmitry
On 2015-06-03 21:36, Mandy Chung wrote:
>
>
> On 06/0
>> e.g. "dump"?
>>
>> The line in vmSymbols looks like:
>>
>> template(
>> get_finalizer_histogram_name, "getFinalizerHistogram")
>>
>> I would prefer to keep method name specific enough to be able to
>> find it by grep in
10d %s", count, name);
>}
> }
>
>
> A couple of nits:
>
> diagnosticCommand.cpp:359 - extra space after =
> diagnosticCommand.cpp:361 - spelling: finlalization -> finalization
> FinalizerInfoTest.java:69: - spelling: intialized -> initialized
> Finali
Staffan,
Could you review a CCC request.
http://ccc.us.oracle.com/8059036
-Dmitry
On 2015-06-05 15:24, Staffan Larsen wrote:
> Thanks - this version looks good to me.
>
> /Staffan
>
>> On 5 jun 2015, at 13:00, Dmitry Samersoff
>> wrote:
>>
>> Staffan,
&g
original exception get lost.
Fixing it by adding static stopApp(app) method with null pointer check
inside.
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
);
+ImmutableOopMapSet.updateRegisterMap(this, cb, map, true);
}
// Since the prolog does the save and restore of FP there is no
oopmap
-Dmitry
On 2015-05-19 18:20, Andrew Haley wrote:
> On 05/16/2015 06:03 PM, Dmitry Samersoff wrote:
>> Andrew,
>>
>> On 2015-05-12 20:0
eeds a correction:
> that signal app => that signals app
> waits until => wait until
>
> It is a little bit strange that an IOException is thrown
> when the exit code does not match the expectation.
>
>
> Thanks,
> Serguei
>
>
> On 6/9/15 5:48 A
mmand line debugger clhsdb
jhsdb jstack file core
jhsdb jmap file core
jhsdb jinfo file core
will launch corresponding SA based utility.
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Andrew,
I'm ready to push your changes.
Do you have an official jdk9 reviewer sign off?
-Dmitry
On 2015-06-12 17:58, Andrew Haley wrote:
> On 06/12/2015 02:12 PM, Dmitry Samersoff wrote:
>> Andrew,
>>
>> Found minor nit in the fix, please update the webrev:
>
David,
Could you take a look?
-Dmitry
On 2015-06-24 12:24, Andrew Haley wrote:
> On 24/06/15 10:17, Dmitry Samersoff wrote:
>> Do you have an official jdk9 reviewer sign off?
>
> Not that I've seen. I will send this to JDK9-dev.
>
> JDK9-dev people: we&#
continue;
> 73 }
> 74
> 75 if (s.equals("b")) {
> 76 b_opt = true;
> 77 continue;
> 78 }
> 79
> 80 if (s.equals("c")) {
> 81 c_opt = true;
> 82 contin
Andrew,
The fix is pushed.
Please take a look at the changeset for sanity.
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0032abb6e693
-Dmitry
On 2015-06-24 12:36, David Holmes wrote:
> On 24/06/2015 7:26 PM, Dmitry Samersoff wrote:
>> David,
>>
>> Could you take a lo
Everybody,
Please, review the fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8129971/webrev.01/
Added one more register counted in frame context.
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give m
Katja,
done.
Webrev updated in-place (press shift-reload)
-Dmitry
On 2015-07-15 15:16, Yekaterina Kantserova wrote:
> Dmitry,
>
> could you please remove @ignore tag in TestStackTrace.java as well?
>
> // Katja
>
> On 07/15/2015 01:52 PM, Dmitry Samersoff wrote:
>&
carg = carg.substring(2);
>
> 136 ch = carg.charAt(_optopt);
> 139 ch = carg.charAt(_optopt);
>
>
> Otherwise, the fix looks good.
>
>
> Thanks,
> Serguei
>
>
> On 6/24/15 5:37 AM, Dmitry Samersoff wrote:
>>
Hi Dmitry,
>
> I do not see any changes.
> Could you please, generate .06 version ?
> In such a case, it will be much easier to compare the code.
>
> Thanks,
> Serguei
>
> On 7/16/15 8:23 AM, Dmitry Samersoff wrote:
>> Serguei,
>>
>> http://cr.op
it JDK-wide instead of a separate parser for each tool.
> Other files look good to me.
> Do you have another reviewer?
Stefan Larsen reviewed one of the previous versions.
-Dmitry
>
>
>
> On 7/17/15 2:46 AM, Dmitry Samersoff wrote:
>> Serguei,
>>
>>
Serguei,
Sorry for typeo
new webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8059038/webrev.06
-Dmitry
On 2015-07-17 16:28, serguei.spit...@oracle.com wrote:
> On 7/17/15 6:21 AM, Dmitry Samersoff wrote:
>> Serguei,
>>
>> new webrev:
>>
>> http://cr.openjdk
al to a new method optReset().
>
> But I leave it up to you.
> Thumbs up from me.
>
>
> Thanks,
> Serguei
>
>
> On 7/17/15 7:13 AM, Dmitry Samersoff wrote:
>> Serguei,
>>
>> Sorry for typeo
>>
>> new webrev:
>> http://cr.openjdk
http://cr.openjdk.java.net/~akulyakh/8114828/index.html
>>>
>>> Before the change the @library tags in the tests pointed to the directory
>>> above the tests repository.
>>> With the jtreg b12 and above this is not allowed. Instead, the
>>> external.lib.roots p
t; to os::Linux::gettid()? That way, it can be mapped back to the output of a
> SIGQUIT dump.
>
> The downside of gettid() is that it is only available on Linux>2.4.11, but
> that dates from 2001. If we really still want to support it, we could
> check for that.
>
> Thou
Everybody,
Please review the fix:
http://cr.openjdk.java.net/~dsamersoff/JDK-8132648/webrev.01/
Changes:
Check for standard conditions that cause attach to fail
Remove word "Server" to match both Server and Client compiler
configurations.
-Dmitry
--
Dmitry Samersoff
Oracle Java d
ols/jhsdb/BasicLauncherTest.java macosx-all
> +
> ########
>
>
> Thanks,
>
> -Joe
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
<http://cr.openjdk.java.net/%7Esla/8076470/jdk/webrev.00/>
>> hotspot changes:
>> http://cr.openjdk.java.net/~sla/8076470/hotspot/webrev.00/
>> <http://cr.openjdk.java.net/%7Esla/8076470/hotspot/webrev.00/>
>>
>> Thanks,
>> /Staffan
>>
>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
/webrevs/2015/hotspot/8033577-dtrace-parfait1.1/
>
>
>
> Summary:
> The fix includes:
>- the parfait fixes listed in the bug report and
>- a couple of adjustments for the bsd version to match the solaris
> version
>
>
> Testing:
> The JPRT build
>
>
;
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8080401-dtrace-parfait2.1/
>
>
>
> Summary:
>
> The fix includes the parfait issues listed in the bug report.
>
>
> Testing:
> The JPRT build
>
>
> Thanks,
> Serguei
--
D
runs
jstack but hotspot version runs jhsdb (sa launcher).
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
On 2015-08-21 12:35, Jaroslav Bachorik wrote:
> Hi Dmitry,
>
> On 19.8.2015 19:10, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review test-only fix.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8086134/webrev.01/
>>
>> The test is re
* operating system' -> 'depends *on* operating system'
fixed. (in-place, press shift-reload).
-Dmitry
On 2015-08-21 14:44, Jaroslav Bachorik wrote:
> On 21.8.2015 12:05, Dmitry Samersoff wrote:
>> On 2015-08-21 12:35, Jaroslav Bachorik wrote:
>>> Hi Dmitry,
>
" strings respectively to keep the output format being 'one line per
> one JVM'.
>
> Thanks,
>
> -JB-
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Everybody,
Please, review updated webrev:
http://cr.openjdk.java.net/~dsamersoff/JDK-8086134/webrev.02/
LingeredApp changed to better work on slow embedded platforms,
fixed bug in hotspot version of test.
On 2015-08-19 20:10, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review
gt;
> Overall it looks good. However, you can use Phaser in the
> LingeredAppWithDeadlock to hit the deadlock for sure. Sorry for not
> noticing this earlier :(
>
> -JB-
>
>>
>>
>> On 2015-08-19 20:10, Dmitry Samersoff wrote:
>>> Everybody,
>>>
&
generic-all
-# 8132648
-sun/tools/jhsdb/BasicLauncherTest.java generic-all
-
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they
kind of
>> initialization and report the status appropriately.
>>
>> The change has passed the local testing and a full JPRT run.
>>
>> Thanks!
>>
>> -JB-
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
by the current user and the attempt to set the executable
> flag will succeed.
>
> The patch has been tested on all supported platforms successfully.
>
> Thanks,
>
> -JB-
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Everybody.
Please review the fix.
http://cr.openjdk.java.net/~dsamersoff/JDK-8139762/webrev.01/
printf format characters %d and %ld misused in couple of places in
generateJvmOffsets.cpp and libjvm_db.c
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I
;
> 283 GEN_VALUE(SIZE_HeapBlockHeader, (int) sizeof(HeapBlock::Header));
>
>
> If there is a type mismatch anywhere then it is better to use the type
> cast to int as above.
>
>
> Thanks,
> Serguei
>
> On 10/16/15 07:56, Dmitry Samersoff wrote:
>>
lies inline.
>
> Modified webrev: http://cr.openjdk.java.net/~rprotacio/8138916.01/
> (Retested and works fine.)
>
> On 10/27/2015 7:52 AM, Dmitry Samersoff wrote:
>> Rachel,
>>
>> In worst case (windows, overflow) the code would parse format string
>> four times.
uf_len doesn't account prefix_len
115 you may consider to use pre-calculated at ll. 108 prefix rather than
calculate it again.
116 int ret redefined it causes a warning.
-Dmitry
> (Retested and works fine.)
>
> On 10/27/2015 7:52 AM, Dmitry Samersoff wrote:
>> Rachel,
>
Everybody,
(* On behalf of Jini George *)
Please review the fix
http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-7041183/webrev.01/
-Dmitry
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't gi
gt; Currently, the 'jdk.management' module is not a part of the JRE image
> even though it should be. This patch adds 'jdk.management' to
> PROVIDER_MODULES where it belongs.
>
> Thanks,
>
> -JB-
--
Dmitry Samersoff
Oracle Java development team, Saint Petersb
ode, I would like to
>>>>> leave the
>>>>> check in there, still.
>>>>>
>>>>>>> task.cpp:
>>>>>>> Fatal can return if -XX:SuppressErrorAt is used. Just don't access the
>>>>>>> array in this case.
>>>>>>
>>>>>> Okay. I would not be surprised if we have a lot of potential errors if a
>>>>>> fatal/guarantee failure is suppressed.
>>>>>>
>>>>>>> attachListener.hpp:
>>>>>>> Do strncpy to not overflow buffer. Don't write more chars than
>> before.
>>>>>>
>>>>>> Again we have the assert to catch an error in the caller using an
>>>>>> invalid name.
>>>>> Hmm, the command comes from outside of the VM. It's not checked
>>>>> very thoroughly, see, e.g., attachListener_windows.cpp:194. Arg0 is
>>>>> checked twice, arg1 and arg2 are not checked at all.
>>>>
>>>> The libattach code is still part of our codebase so should be doing the
>>>> right things. The linux and solaris code seems to be doing the expected
>>>> name length check. On Windows the name is set using cmd, which is also
>>>> subject to a length check:
>>>>
>>>>if (strlen(cmd) > AttachOperation::name_length_max) return
>>>> ATTACH_ERROR_ILLEGALARG;
>>>>
>>>>> I add fixes for attachListener_windows.cpp to this change.
>>>>>
>>>>>>> heapDumper.cpp:
>>>>>>> strncpy does not null terminate.
>>>>>>
>>>>>> 1973 if (total_length >= sizeof(base_path)) {
>>>>>>
>>>>>> total_length already adds +1 for the nul character so the == case is
>>>>>> fine AFAICS.
>>>>>>
>>>>>> strncpy wont nul-terminate if the string exceeds the buffer size. But
>> we
>>>>>> have already established that total_length <= sizeof(base_path), and
>>>>>> total_path includes space for a bunch of stuff other than
>> HeapDumpPath,
>>>>>> so the strncpy of HeapDumpPath has to copy the nul character.
>>>>> Ok, removed.
>>>>>
>>>>>>> src/share/vm/services/memoryService.cpp
>>>>>>
>>>>>> Ok.
>>>>>>
>>>>>>> src/share/vm/utilities/xmlstream.cpp
>>>>>>
>>>>>> Ok - I'm more concerned about the "magic" 10 in that piece of code.
>>>>> I assume the 10 is the space needed for the "_done" plus some waste ...
>>>>>
>>>>> I'll do another run of the scan. That takes a day. I'll post a new
>>>>> webrev
>>>> after
>>>>> that.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thank again for this thorough review,
>>>>> Goetz
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> Some of these, as the issue in codeBuffer.cpp, are actually handled
>>>> correctly.
>>>>>>> Nevertheless this is not that obvious so that somebody changing the
>>>> code
>>>>>>> Could oversee he has to add the initialization.
>>>>>>
>>>>>> Not an argument I buy en-masse as it leads to a lot of redundancy
>>>>>> through the code paths. Plus these tools that are being run should
>> show
>>>>>> if a code changes requires initialization that is not present.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> Some of these fixes are part of SAP JVM for a long time. This change
>> has
>>>>>>> been tested with our nightly build of openJDK.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz,.
>>>>>>>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
142336
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8142336/webrev.01/
>>>
>>> A few remarks:
>>>
>>> * Could you please document the new DISABLED_WARNINGS_CXX and
>>> DISABLED_WARNINGS_C in the function header?
>>>
>>> * I believe the use of {} here was to signify a set. When only jsig
>>> remains, it just looks strange:
>>> -# SYMFLAG is used by {jsig,saproc}.make
>>> +# SYMFLAG is used by {jsig}.make
>>>
>>> * The logic of setting up "--hash-style=both" is already done in
>>> configure for LDFLAGS_JDKLIB, so you do not need to repeat it, if you
>>> include the LDFLAGS_JDKLIB variable.
>>
>> Also, SA_WINDOWS_LDFLAGS is read but never defined.
>>
>> /Magnus
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
m also wondering about documenting where we are determining the
> maximum from? Is it simply _NSIG on some/all distributions? And I see
> _NSIG is supposed to be the biggest signal number + one. Also linux
> defines NSIG = _NSIG so which should we be using?
>
> Thanks,
> David
>
>> Best regards,
>>Goetz.
>>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
os_linux, too.
> So it's really more consistent.
>
> Best regards,
> Goetz
>
>> -----Original Message-
>> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
>> Sent: Donnerstag, 12. November 2015 09:22
>> To: David Holmes; Lindenmaier, Goetz;
aris too, so that we have NSIG
>>> defined on all Posix platforms.
>>
>> Solaris doesn't have any of this SR_signum related code. A more general
>> cleanup of signal related code would potentially involve a lot of
>> cleanup.
>>
>> D
>
>
>
> Here is the new webrev:
>
> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/
>
>
>
> Best regards,
>
> Goetz.
>
>
>
>
>
> *From:*Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> *Sent:* Freitag, 13. Novemb
I you don't object I'll leave the comment as is.
I'm OK with it. Leave it as is.
-Dmitry
>
> Best regards,
> Goetz.
>
> -----Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Montag, 16. November 2015 09:23
>
1 - 100 of 882 matches
Mail list logo
