Re: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes JDK under test

[Joseph D. Darcy]

Hello,

I strongly recommend this test *not* write to java.home in any way, 
including undoing the changes afterward.


If that is not possible, I think the test should be updated as suggested 
and also turned into a manual test.


Cheers,

-Joe

On 2/23/2017 4:00 PM, Mark Sheppard wrote:

Hi,
   please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8175177/webrev/

for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8175177

the test now explicitly removes the orb.properties file created by the 
test.


regards
Mark

Re: RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes JDK under test

[Lance Andersen]

Looks OK Mark.

Best
Lance
> On Feb 23, 2017, at 7:00 PM, Mark Sheppard  wrote:
> 
> Hi,
>   please oblige and review the following change
> http://cr.openjdk.java.net/~msheppar/8175177/webrev/
> 
> for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8175177
> 
> the test now explicitly removes the orb.properties file created by the test.
> 
> regards
> Mark

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: Soften interface for javax.management.ObjectName.getInstance and friends

[Mandy Chung]

You should send this topic to serviceability-dev which is the mailing list for 
JMX and other serviceability related issues.

Mandy

> On Feb 23, 2017, at 4:17 PM, Dave Brosius  wrote:
> 
> Greetings. the method
> 
> public static ObjectName getInstance(String domain,
> Hashtable table)
>throws MalformedObjectNameException {
>return new ObjectName(domain, table);
>}
> 
> in javax.management.ObjectName allows for a provided Hashtable to specify 
> properties for the objectname.
> 
> The semantics of an ObjectName don't consider the order of these properties, 
> however certain tools like jconsole (when used as a name for a jmx property) 
> does consider the order.
> 
> If you wish to create a folder structure to report metrics in jmx, you need 
> to use this properties map to specify the folder names. JConsole, then, uses 
> order of iteration to determine the order of the folder hierarchy.
> 
> Suppose you want a folder hierarchy similar to a package name, you may 
> specify properties like
> 
> table.put("a0", "com");
> table.put("a1", "acme");
> table.put("name", "MyMetric");
> 
> in hopes of producing a metric in JConsole in the folder structure, 
> com/acme/MyMetric.
> 
> The problem is of course, that the argument is a Hashtable, not a Map, and so 
> the items are not ordered at all, yet JConsole uses iteration order to build 
> the path, so you may get
> 
> acme/ao/MyMetric or MyMetric/acme/ao or .
> 
> This means if you really want to have ordered packages, you have to derive 
> from Hashtable, and override the entrySet() method, including that set's 
> iterator() to return the values in the order you wish to have them shown.
> 
> That is really janky.
> 
> I'm proposing that the interface for getInstance be softened to
> 
> public static ObjectName getInstance(String domain,
> Map table)
> 
> as well as
> 
> public ObjectName(String domain, Map table)
> 
> thoughts?
> 
> 

Soften interface for javax.management.ObjectName.getInstance and friends

[Dave Brosius]

Greetings. the method

public static ObjectName getInstance(String domain,
Hashtable table)
throws MalformedObjectNameException {
return new ObjectName(domain, table);
}

in javax.management.ObjectName allows for a provided Hashtable to 
specify properties for the objectname.


The semantics of an ObjectName don't consider the order of these 
properties, however certain tools like jconsole (when used as a name for 
a jmx property) does consider the order.


If you wish to create a folder structure to report metrics in jmx, you 
need to use this properties map to specify the folder names. JConsole, 
then, uses order of iteration to determine the order of the folder 
hierarchy.


Suppose you want a folder hierarchy similar to a package name, you may 
specify properties like


table.put("a0", "com");
table.put("a1", "acme");
table.put("name", "MyMetric");

in hopes of producing a metric in JConsole in the folder structure, 
com/acme/MyMetric.


The problem is of course, that the argument is a Hashtable, not a Map, 
and so the items are not ordered at all, yet JConsole uses iteration 
order to build the path, so you may get


acme/ao/MyMetric or MyMetric/acme/ao or .

This means if you really want to have ordered packages, you have to 
derive from Hashtable, and override the entrySet() method, including 
that set's iterator() to return the values in the order you wish to have 
them shown.


That is really janky.

I'm proposing that the interface for getInstance be softened to

public static ObjectName getInstance(String domain,
 Map table)

as well as

public ObjectName(String domain, Map table)

thoughts?

RFR: JDK-8175177 - org/omg/CORBA/OrbPropertiesTest.java changes JDK under test

[Mark Sheppard]

Hi,
   please oblige and review the following change
http://cr.openjdk.java.net/~msheppar/8175177/webrev/

for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8175177

the test now explicitly removes the orb.properties file created by the test.

regards
Mark

Re: Future plans for sun.misc.Contended

[Vitaly Davidovich]

Thanks Andrew - I recall reading that, but wasn't sure if that was still
the final thinking.  Unfortunately, I'm seeing this annotation slip into
codebases (with the corresponding -XX:-RestrictContended), and jigsaw is
surfacing these instances.  Looks like we have to wait for panama/valhalla
then to see where layout control lands.

On Thu, Feb 23, 2017 at 12:41 PM, Andrew Haley  wrote:

> On 23/02/17 17:26, Vitaly Davidovich wrote:
> > My understanding was it's in sun.misc as an experimental/"unstable"
> > annotation, but that it was incubating there before being made supported
> > (and moved out of that package) as it's a legitimately useful feature
> (the
> > manual padding one does today with class hierarchy and unused padding
> > fields is atrocious, as some of you may know).
>
> John Rose spoke about this before.
>
> "There's a misunderstanding here.  Sadly, it relates to security
> policy.
>
> "The shadowy figures with the liberal usage of sharp-edged features
> are not dumb users, nor are they smart users like you whom we
> unaccountably view as "dumb and misinformed", but black hat attackers
> (or security researchers of any stripe), who take sharp stuff like
> that and use it backwards and upside down, in ways neither dumb nor
> smart users would ever dream of, to coax the JVM into disallowed
> states.
>
> "The overflow Paul refers to would not be a heap OOM but
> (hypothetically) size indicators in the implementation of the JVM.
> Adding @C to the public mix gives a determined attacker 3 more bits of
> dynamic range to maximum instance sizes.
>
> "I personally don't think there is any specific way to weaponize that,
> but I do know, from bitter experience, that some such expansions
> produce bugs.  (Think 16-bit overflow: It has happened, it hurts when
> it happens.)  Adding @C to the public mix means we have to race the
> black hats to find any bug tail due to the extra degrees of freedom in
> instance layout.  It's not a race I want to run or need to run, so we
> are not making @C public.
>
> "As we do value types we are having to open up object layout to many
> more degrees of freedom.  This will be carefully reviewed and
> stress-tested.  At that point it will be very safe to add other layout
> hacks like @C.  In fact, it is likely that we will be able to factor
> field-semantic hacks like @C (and WeakReference and Optional and
> various other interesting variable types) into value type wrappers of
> the base type."
>
> Andrew.
>
>

Re: Future plans for sun.misc.Contended

[Andrew Haley]

On 23/02/17 17:26, Vitaly Davidovich wrote:
> My understanding was it's in sun.misc as an experimental/"unstable"
> annotation, but that it was incubating there before being made supported
> (and moved out of that package) as it's a legitimately useful feature (the
> manual padding one does today with class hierarchy and unused padding
> fields is atrocious, as some of you may know).

John Rose spoke about this before.

"There's a misunderstanding here.  Sadly, it relates to security
policy.

"The shadowy figures with the liberal usage of sharp-edged features
are not dumb users, nor are they smart users like you whom we
unaccountably view as "dumb and misinformed", but black hat attackers
(or security researchers of any stripe), who take sharp stuff like
that and use it backwards and upside down, in ways neither dumb nor
smart users would ever dream of, to coax the JVM into disallowed
states.

"The overflow Paul refers to would not be a heap OOM but
(hypothetically) size indicators in the implementation of the JVM.
Adding @C to the public mix gives a determined attacker 3 more bits of
dynamic range to maximum instance sizes.

"I personally don't think there is any specific way to weaponize that,
but I do know, from bitter experience, that some such expansions
produce bugs.  (Think 16-bit overflow: It has happened, it hurts when
it happens.)  Adding @C to the public mix means we have to race the
black hats to find any bug tail due to the extra degrees of freedom in
instance layout.  It's not a race I want to run or need to run, so we
are not making @C public.

"As we do value types we are having to open up object layout to many
more degrees of freedom.  This will be carefully reviewed and
stress-tested.  At that point it will be very safe to add other layout
hacks like @C.  In fact, it is likely that we will be able to factor
field-semantic hacks like @C (and WeakReference and Optional and
various other interesting variable types) into value type wrappers of
the base type."

Andrew.

Future plans for sun.misc.Contended

[Vitaly Davidovich]

Hi all,

I'm curious if anyone knows the future plans for this annotation,
specifically if it's slated to become officially supported in Java SE and
if so, what the timeline looks like (if that exists).

My understanding was it's in sun.misc as an experimental/"unstable"
annotation, but that it was incubating there before being made supported
(and moved out of that package) as it's a legitimately useful feature (the
manual padding one does today with class hierarchy and unused padding
fields is atrocious, as some of you may know).

Thanks

RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

[Baesken, Matthias]

Here is  the webrev for jdk9 :

http://cr.openjdk.java.net/~mbaesken/webrevs/8175000/


?  And btw I really wonder  - is  jexec still needed in future jdk's like jdk10 
 ? Seems it is not used much .

?

In case  jexec will stay in  the jdk  I might add a test for the tool as well, 
if there is interest  ( could not really find one that tests execution of a 
simple jar-file with jexec).

Best regards, Matthias


From: Baesken, Matthias
Sent: Donnerstag, 23. Februar 2017 07:39
To: 'core-libs-dev@openjdk.java.net' 
Cc: Langer, Christoph ; Erik Joelsson 
(erik.joels...@oracle.com) 
Subject: RE: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

Hello,  probably I should add the info that the fix is needed  in jdk9 as well 
, not only jdk10 .

Without the fix jdk9/10show this error  when executing a small  example jar 
:

/myjdk9/images/jdk/lib/jexec  /java_test/hellojar/helloworld.jar
invalid file (bad magic number): Exec format error

with the fix :

jdk/lib/jexec/java_test/hellojar/helloworld.jar
Hello world from a jar file


And btw I really wonder  - is  jexec still needed in future jdk's like jdk10  ? 
Seems it is not used much .

Best regards, Matthias


From: Baesken, Matthias
Sent: Mittwoch, 22. Februar 2017 18:16
To: core-libs-dev@openjdk.java.net
Cc: Langer, Christoph 
mailto:christoph.lan...@sap.com>>; Erik Joelsson 
(erik.joels...@oracle.com) 
mailto:erik.joels...@oracle.com>>
Subject: RFR [XS] : 8175000 : jexec fails to execute simple helloworld.jar

Hello , when looking into  the jexec build I noticed   that  execution of a 
simple helloworld.jar   with jexec does not work any more.

I did a little patch for this which adjusted the addition done with  CR  
8156478: 3 Buffer overrun defect groups in 
jexec.c
  .

Could I have a review ( just a diff this time is provided because of 
infrastructure issues) for it ?


Thanks, Matthias

Bug :
https://bugs.openjdk.java.net/browse/JDK-8175000


Diff for jdk10  :

# HG changeset patch
# User mbaesken
# Date 1487782485 -3600
#  Wed Feb 22 17:54:45 2017 +0100
# Node ID 93d55a711f3b1c3f282e6889c24d13f16d4a4548
# Parent  884872263accabd4ab68d005abd4e5393144aa4f
8175000: jexec fails to execute simple helloworld.jar

diff --git a/src/java.base/unix/native/launcher/jexec.c 
b/src/java.base/unix/native/launcher/jexec.c
--- a/src/java.base/unix/native/launcher/jexec.c
+++ b/src/java.base/unix/native/launcher/jexec.c
@@ -331,8 +331,9 @@
 off_t end   = start  + xlen;

 if (end <= count) {
-end -= 4; // make sure there are 4 bytes to read at start
-while (start < end) {
+// make sure there are 4 bytes to read at start
+end -= 3;
+while ((start < end) && (start < count-3)) {
 off_t xhid  = SH(buf, start);
 off_t xdlen = SH(buf, start + 2);