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

Langer, Christoph christoph.langer at sap.com
Fri Mar 23 08:37:57 UTC 2018

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 >

More information about the serviceability-dev mailing list