RFR(S) 8199924: Solaris: Correctly enqueue null arguments of attach operations

[Langer, Christoph]

Hi,

I pushed it after running the "com/sun/tools/attach" jtreg tests on Solaris: http://hg.openjdk.java.net/jdk/jdk/rev/6e2d71029781

Thanks
Christoph

> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 22. März 2018 22:24
> To: Langer, Christoph <christoph.langer at sap.com>;
> daniel.daugherty at oracle.com; serviceability-dev at openjdk.java.net
> Subject: Re: RFR(S) 8199924: Solaris: Correctly enqueue null arguments of
> attach operations
> 
> On 23/03/2018 5:15 AM, Langer, Christoph wrote:
> > Hi David,
> >
> >>> I think you should keep your original fix since it now properly
> >>> handles null arguments at the same attach-on-demand layer as the
> >>> Linux code that you quoted.
> >>>
> >>> Handling this in args array processing would also be possible
> >>> as David suggests, but it would bother me that Linux and Solaris
> >>> lower attach-on-demand layers would have different behaviors.
> >>
> >> They already do have completely different behaviours. Linux handles
> NULL
> >> at the Java layer by inserting empty strings!
> >
> > I had another look at the implementations on the various platforms.
> >
> > You are right, linux, aix and mac would write empty strings on java layer -
> but the enque mechanisms of these platforms looks quite different to
> Solaris. However, for Windows, where the implementation is different again,
> the handling of null params happens in the c-native code. For Solaris I would
> see the best place in the native code as well.
> 
> The native layer does differ across platforms - Solaris uses "doors",
> which other platforms don't have.
> 
> It would make most sense to me if the Java level for each platform
> basically worked the same, particularly in the handling of nulls. But
> that should have been the case from day one.
> 
> > So if you don't mind I would keep my change and annotate you and Dan as
> reviewers, ok?
> 
> Fine. The code seemed okay - but harder to judge versus the trivial
> changes to java code.
> 
> David
> -----
> 
> > Thanks
> > Christoph
> >