Re: RFR: JDK-8184770: JDWP support for IPv6

[Alex Menkov]

Updated webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.02/

- added support for addresses enclosed in square brackets;
- updated SocketTransportService.java to handle empty hostname the same 
way as JDWP agent (listen/attach to loopback address);

Has to update nsk/jdi/ListeningConnector/startListening/startlis001.java
(all other com/sun/jdi, nsk/jdi, nsk/jdwp, nsk/jdb test are passed).

--alex

On 04/01/2019 11:21, Alex Menkov wrote:

Hi Chris,

On 04/01/2019 04:50, Chris Hegarty wrote:

Alex,

On 29/03/2019 22:07, Alex Menkov wrote:

(added net-dev as suggested by Alan)

Net gurus, please assist in reviewing socket-related code.

New webrev:
http://cr.openjdk.java.net/~amenkov/IPv6/webrev.01/


Specifically on SocketTransportService.java. What Arthur has
proposed is better ( changing to lastIndexOf alone is not
sufficient ). Or is your assumption that the IPv6 literal is
not enclosed in square brackets?


I didn't know about enclosing IPv6 in square brackets, but looks like 
that's standard way to alleviate conflict between IPv6 address and colon 
as port separator.
Will update the fix to handle them in both JDI connectors 
(SocketTransportService.java) and debugger agent (socketTransport.c)




If keeping Arthur's `static class HostPort` please make the
fields final.

 >> Would it make sense to support the preference properties?
 >>    java.net.preferIPv4Stack
 >>    java.net.preferIPv6Addresses

I'm not sure about this, especially given the property name
prefixes. I need to think a little more on it.


In the initial version of the fix I didn't check the properties.
The rationale here is backward compatibility - is address is empty, old 
debuggers tries to connect to IPv4 address only.
But handling this properties we will better handle clients with 
properties set (as jdb or any other debugger which uses JDI connectors 
are affected by the properties).


BTW fix provided by Arthur implements listening on localhost differently 
- it creates several sockets and binds them to both IPv4 and IPv6 
addresses. But the problem here (and that's the reason I decide to not 
implement it this way) - how to handle the case when we successfully 
bind on one address (for example IPv4), but fail to bind on other (for 
example the port is busy for IPv6 stack). Arthur's version just fail in 
the case (i.e. the whole Java process terminates) and I don't think this 
is good behavior.





There is quite a bit of new native code, is it possible to
rewrite any of this in Java, e.g. reading of the system
properties ( if that is to remain )?


socketTransport.c is a debugger agent which is completely native.

--alex



-Chris.

Re: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk

[Zhengyu Gu]

Thanks, Chris.

On 4/2/19 2:16 PM, Chris Plummer wrote:
Changes to CollectedHeap.java and ObjectHeap.java look fine. One minor 
nit. Please fix the indent of line 258 in ObjectHeap.java:


  257 while (handle.lessThan(top)) {
  258 Oop obj = null;
  259   // Raw pointer walk
  260   handle = handle.addOffsetToAsOopHandle(heap.oopOffset());


I will fix it before push.

-Zhengyu



thanks,

Chris

On 4/1/19 6:26 AM, Zhengyu Gu wrote:

Hi,

May I get review from serviceability? as it has minor changes in 
shared code (CollectedHeap.java and ObjectHeap.java)



Thanks,

-Zhengyu


On 3/14/19 11:37 AM, Zhengyu Gu wrote:
Please review this patch that provides best-effort implementation of 
live regions iteration for Shenandoah GC.


There are minor changes in shared code, to adjust oop offset from 
base of allocation cell.


Bug: https://bugs.openjdk.java.net/browse/JDK-8220602
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html


Test:
   hotspot_gc_shenandoah
   hotspot_serviceability
   vmTestbase/nsk/jdb
   manual test: jhsdb hsdb
   on Linux x64

   Passed submit test.


Thanks,

-Zhengyu

Re: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

[Chris Plummer]

On 4/2/19 11:11 AM, Gary Adams wrote:

The test exits with 3 for the general Exception.
I added 4 just to distinguish the return.
I see 7 used earlier when the lockfile is not initialized.

I could add a message, if you think it is useful.

Yes, I think it would be.


The exit code is printed in stopApp(). line 377.
Ok. I was just wondering if specific error codes were being checked for. 
It looks like that's not the case.


thanks,

Chris


On 4/2/19, 1:58 PM, Chris Plummer wrote:

Hi Gary,

I see various System.exit() calls with varying exit status. Is there 
some place that documents them? What is 4?


Any reason not to print the exception before doing the System.exit(4)?

thanks,

Chris

On 4/2/19 4:50 AM, Gary Adams wrote:
This proposed change allows a wider range of IOExceptions to be 
observed
when a LingeredApp is being shutdown. It may not be just a 
NoSuchFileException.
Botton line - if the lock file doesn't exist at the time the 
IOException

is observed then the main application is terminating the test sequence
and LingeredApp should end normally.

  Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203364

Re: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk

[Chris Plummer]

Changes to CollectedHeap.java and ObjectHeap.java look fine. One minor 
nit. Please fix the indent of line 258 in ObjectHeap.java:


 257 while (handle.lessThan(top)) {
 258 Oop obj = null;
 259   // Raw pointer walk
 260   handle = handle.addOffsetToAsOopHandle(heap.oopOffset());

thanks,

Chris

On 4/1/19 6:26 AM, Zhengyu Gu wrote:

Hi,

May I get review from serviceability? as it has minor changes in 
shared code (CollectedHeap.java and ObjectHeap.java)



Thanks,

-Zhengyu


On 3/14/19 11:37 AM, Zhengyu Gu wrote:
Please review this patch that provides best-effort implementation of 
live regions iteration for Shenandoah GC.


There are minor changes in shared code, to adjust oop offset from 
base of allocation cell.


Bug: https://bugs.openjdk.java.net/browse/JDK-8220602
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html


Test:
   hotspot_gc_shenandoah
   hotspot_serviceability
   vmTestbase/nsk/jdb
   manual test: jhsdb hsdb
   on Linux x64

   Passed submit test.


Thanks,

-Zhengyu

Re: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

[Gary Adams]

The test exits with 3 for the general Exception.
I added 4 just to distinguish the return.
I see 7 used earlier when the lockfile is not initialized.

I could add a message, if you think it is useful.

The exit code is printed in stopApp(). line 377.

On 4/2/19, 1:58 PM, Chris Plummer wrote:

Hi Gary,

I see various System.exit() calls with varying exit status. Is there 
some place that documents them? What is 4?


Any reason not to print the exception before doing the System.exit(4)?

thanks,

Chris

On 4/2/19 4:50 AM, Gary Adams wrote:

This proposed change allows a wider range of IOExceptions to be observed
when a LingeredApp is being shutdown. It may not be just a 
NoSuchFileException.

Botton line - if the lock file doesn't exist at the time the IOException
is observed then the main application is terminating the test sequence
and LingeredApp should end normally.

  Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203364

Re: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

[Chris Plummer]

Hi Gary,

I see various System.exit() calls with varying exit status. Is there 
some place that documents them? What is 4?


Any reason not to print the exception before doing the System.exit(4)?

thanks,

Chris

On 4/2/19 4:50 AM, Gary Adams wrote:

This proposed change allows a wider range of IOExceptions to be observed
when a LingeredApp is being shutdown. It may not be just a 
NoSuchFileException.

Botton line - if the lock file doesn't exist at the time the IOException
is observed then the main application is terminating the test sequence
and LingeredApp should end normally.

  Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203364

RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

[Gary Adams]

This proposed change allows a wider range of IOExceptions to be observed
when a LingeredApp is being shutdown. It may not be just a 
NoSuchFileException.

Botton line - if the lock file doesn't exist at the time the IOException
is observed then the main application is terminating the test sequence
and LingeredApp should end normally.

  Webrev: http://cr.openjdk.java.net/~gadams/8203364/webrev/
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203364

Re: [PING] RFR: 8217338: [Containers] Improve systemd slice memory limit support

[Severin Gehwolf]

Could I get a second review, please?

Thanks,
Severin

On Thu, 2019-03-28 at 11:37 -0400, Bob Vandette wrote:
> Sorry for the delay.  The update looks good.
> 
> Bob.
> 
> 
> > On Mar 25, 2019, at 1:30 PM, Severin Gehwolf  wrote:
> > 
> > On Fri, 2019-03-22 at 14:25 -0400, Bob Vandette wrote:
> > > Could you maybe combine subsystem_file_contents with 
> > > subsystem_file_line_contents
> > > by adding an additional argument?
> > 
> > Done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8217338/05/webrev/
> > 
> > Thanks,
> > Severin
> > 

RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]

[Egor Ushakov]

Please review the fix

this test started to fail after the fix of 
https://bugs.openjdk.java.net/browse/JDK-8146986
previously any call to ClassLoaderReference.visibleClasses as a side 
effect cached the results in VirtualMachineImpl.typesBySignature

and made them available to any VirtualMachine.classesByName call.
This is somewhat not consistent for unprepared classes, I reported that, 
check
Bug 26148990 : JDI - VirtualMachine.allClasses does not return loaded 
but uninitialized class,
but it seems that it allowed the ArrayTypeImpl.componentType to work 
even if the type was not prepared,

check how ArrayTypeImpl#findComponentType uses vm.classesByName.
It seems that ArrayTypeImpl#findComponentType should simply call 
findType for component signature.
Just how the unused com.sun.tools.jdi.ArrayTypeImpl#type method works, 
not sure why it was dropped...


bugid https://bugs.openjdk.java.net/browse/JDK-8221503
cr http://cr.openjdk.java.net/~eushakov/8221503/webrev.00/

Thanks!


--
Egor Ushakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop