Hi Daniil,
LGTM++
Thanks,
Serguei
On 1/15/20 14:28, David Holmes wrote:
+1
David
On 16/01/2020 4:41 am, Daniel Fuchs wrote:
Hi Daniil,
That looks fine to me.
best regards,
-- daniel
On 15/01/2020 18:15, Daniil Titov wrote:
Please review a change [1] that fixes a deadlock issue [2] in
Thanks for your review and updates, David. I've updated the CSR as you
requested in its comments.
Paul
On 1/14/20, 5:12 PM, "David Holmes" wrote:
Hi Paul,
I made some minor updates to the CSR request and added myself as a reviewer.
Thanks,
David
On
Didn't think of that. It should work because it's a static array, not a
static struct with an embedded array. I'll give it a try. I should also
be able to use sizeof() rather than hard code the size.
thanks,
Chris
On 1/15/20 2:05 PM, Alex Menkov wrote:
Hi Chris,
I'd prefer to not separate
+1
David
On 16/01/2020 4:41 am, Daniel Fuchs wrote:
Hi Daniil,
That looks fine to me.
best regards,
-- daniel
On 15/01/2020 18:15, Daniil Titov wrote:
Please review a change [1] that fixes a deadlock issue [2] in
sun.tools.jconsole.Worker class.
There is no need in guarding "stopped"
Forgot to mention
you need to change CommandSet declaration:
typedef struct CommandSet {
int num_cmds;
const char *cmd_set_name;
-const Command cmds[];
+const Command *cmds;
} CommandSet;
--alex
On 01/15/2020 14:05, Alex Menkov wrote:
Hi Chris,
I'd prefer to not separate
Hi Chris,
I'd prefer to not separate command handlers and names.
maybe something like
static Command ArrayReference_Commands[] = {
{length, "Length"},
{getValues, "GetValues"},
{setValues, "SetValues"}
};
CommandSet ArrayReference_CommandSet = {
3, "ArrayReference", _Commands
Hi,
Unfortunately I'm going to have to redo this fix. I ran into compilation
problems on Solaris:
error: too many struct/union initializers (E_TOO_MANY_STRUCT_UNION_INIT)
This turns up on the first initializer of the cmds[] array:
CommandSet ArrayReference_Cmds = {
3, "ArrayReference",
Hi all,
Could I have some reviews for changing mark value of ObjectSampleMarker
(part of JFR Leak Profiler)?
The assertion is fired because the leak
profiler(ObjectSampleMarker::mark()) puts an invalid mark word (0,
INFLATING) into the oop and a concurrent user of oopDesc::is_oop() is
Hi Daniil,
That looks fine to me.
best regards,
-- daniel
On 15/01/2020 18:15, Daniil Titov wrote:
Please review a change [1] that fixes a deadlock issue [2] in
sun.tools.jconsole.Worker class.
There is no need in guarding "stopped" flag by a lock. The fix removes this
excessive locking
Please review a change [1] that fixes a deadlock issue [2] in
sun.tools.jconsole.Worker class.
There is no need in guarding "stopped" flag by a lock. The fix removes this
excessive locking and
instead makes the flag volatile.
Mach5 tier1-tier3 tests passed.
[1] Webrev :
Hello,here is another comparison for the larger JDK shared libs, this
time with the sizes of build with linktime-gc (--gc-sections) added .
( just for the larger libs )
( I had not enabled linktime-gc for libjvm in our test build , just for
the JDK libs . )
Linuxx86_64 /
Hello, I used the "normal" linker so I think what
https://stackoverflow.com/questions/31688069/requirements-to-use-flto
says is true , one can use also the "normal" linker .
Haven't checked for any performance (or other) improvements when using gold
instead .
Best regards,
On 2020-01-15 07:29, Volker Simonis wrote:
Do you know if newer versions of GCC use the gold linker by default? I
remember from some experiments which I did many years ago that gold was
considerably faster compared to the default ld linker.
The default linker is system configured so it depends
Aleksei, Matthias,
thanks for the numbers. The size reduction on libjvm.so looks not bad,
indeed.
Do you know if newer versions of GCC use the gold linker by default? I
remember from some experiments which I did many years ago that gold was
considerably faster compared to the default ld linker.
Hello , I can comment on the code size . This is what I get when comparing
a build without and with -flto .
gcc7 linux x86_64 product build, normal / with -flto
--
du -sh on the *.so files gives :
16K /
Volker,
not a full answer, but here is some static size stats:
Server x86_64 AArch64
regular 23M 20M
lto 17M 14M
Minimal x86_64 AArch64
regular 4.9M 3.9M
lto 4.7M 3.6M
-Aleksei
On 15/01/2020 16:40, Volker Simonis wrote:
> While we
While we are speaking about all the drawbacks of LTO, it's still not clear
what the benefits are? In the very first mail Matthias mentioned that there
might be performance improvements but that performance is not the main
driving factor behind this initiative. So is it the reduced code size
Thanks David and thanks for the discussion.
Coleen
On 1/14/20 6:11 PM, David Holmes wrote:
Hi Coleen,
I concur with the discussion in the bug report. This change looks good.
Thanks,
David
On 15/01/2020 6:37 am, coleen.phillim...@oracle.com wrote:
Summary: Make jmap -clstats call jcmd
18 matches
Mail list logo
