gmane.comp.java.openjdk.hotspot.devel

Always enforce ACC_SUPER

Florian Weimer — 2012-05-18T07:49:14

It has been observed that the easy way of creating non-cloneable classes 
does not work because classes can opt out of the ACC_SUPER handling:

<http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-August/004742.html>

I don't think this is desirable, so I propose a patch to treat all 
classes as if they have ACC_SUPER set.  A new product flag is 
introduced, ForceAccSuper, which defaults to true.  Disabling it 
preserves the old behavior.  I think that assuming the presence of 
ACC_SUPER rather than rejecting classes without it completely is safer 
because non-javac bytecode generators might forget to set ACC_SUPER.

The patch is against the Hotspot in OpenJDK 7u4, but it should apply to 
other versions as well.  It has been tested only lightly (on 7u4 and 8).

I have got a test case, but it uses ASM because to my knowledge, no 
released javac version has produced classes without ACC_SUPER (and I 
need to replace a type name, too).  Should I include the class file 
contents as a string constant?  Then

hg: hsx/hotspot-main/langtools: Added tag jdk8-b39 for changeseta9f547c218d9

2012-05-18T03:34:46

Changeset: 8b869afd2eb4
Author:    katleman
Date:      2012-05-17 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8b869afd2eb4

Added tag jdk8-b39 for changeset a9f547c218d9

! .hgtags

hg: hsx/hotspot-main/jdk: 4 new changesets

2012-05-18T03:32:07

Changeset: c2d9166f3284
Author:    ihse
Date:      2012-05-11 08:21 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c2d9166f3284

7168208: Change use of < at > in one sed command involving paths to different character
Reviewed-by: ohair

! make/common/Release.gmk

Changeset: 8d665b69ebf1
Author:    mfang
Date:      2012-05-15 11:46 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8d665b69ebf1

7157855: jvisualvm.1 not included in binaries
Reviewed-by: katleman, thurka

! make/common/Release.gmk

Changeset: b6f529117521
Author:    katleman
Date:      2012-05-16 22:07 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b6f529117521

Merge


Changeset: 47cd90bf0f66
Author:    katleman
Date:      2012-05-17 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/47cd90bf0f66

Added tag jdk8-b39 for changeset b6f529117521

! .hgtags

hg: hsx/hotspot-main/jaxp: Added tag jdk8-b39 for changesetf95fdbe525c8

2012-05-18T03:31:39

Changeset: 9ecfdbd6aed4
Author:    katleman
Date:      2012-05-17 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/9ecfdbd6aed4

Added tag jdk8-b39 for changeset f95fdbe525c8

! .hgtags

hg: hsx/hotspot-main/jaxws: Added tag jdk8-b39 for changeset7f6b44fd3034

2012-05-18T03:31:53

Changeset: 09a0ddda03cb
Author:    katleman
Date:      2012-05-17 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/09a0ddda03cb

Added tag jdk8-b39 for changeset 7f6b44fd3034

! .hgtags

hg: hsx/hotspot-main: 4 new changesets

2012-05-18T03:31:26

Changeset: 955a3e8ed4f0
Author:    ohair
Date:      2012-05-10 08:26 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/955a3e8ed4f0

7167593: Changed get_source.sh to allow for getting full oracle jdk repo forest
Reviewed-by: erikj, asaha, chegar, sla, dholmes, mbykov, coleenp

! get_source.sh
! make/scripts/hgforest.sh

Changeset: 8a4e92c10a9a
Author:    ohair
Date:      2012-05-11 17:52 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/8a4e92c10a9a

7167976: Fix broken get_source.sh script
Reviewed-by: tbell

! make/scripts/hgforest.sh

Changeset: 8927dd68aee3
Author:    katleman
Date:      2012-05-16 22:06 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/8927dd68aee3

Merge


Changeset: a2b2d435f1d2
Author:    katleman
Date:      2012-05-17 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/rev/a2b2d435f1d2

Added tag jdk8-b39 for changeset 8927dd68aee3

! .hgtags

hg: hsx/hotspot-main/corba: Added tag jdk8-b39 for changeset785af00e2827

2012-05-18T03:31:31

Changeset: 56d030e5035f
Author:    katleman
Date:      2012-05-17 06:20 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/56d030e5035f

Added tag jdk8-b39 for changeset 785af00e2827

! .hgtags

hg: hsx/hotspot-main/hotspot: 2 new changesets

2012-05-17T21:58:31

Changeset: 8f972594effc
Author:    kvn
Date:      2012-05-14 09:36 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8f972594effc

6924259: Remove String.count/String.offset
Summary: Allow a version of String class that doesn't have count and offset fields.
Reviewed-by: never, coleenp

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/memory/dump.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/stringopts.hpp

Changeset: de0cc3dd9f10
Author:    kvn
Date:      2012-05-17 09:50 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/de0cc3dd9f10

Merge

hg: hsx/hotspot-main/hotspot: 2 new changesets

2012-05-17T04:30:29

Changeset: 35e504cb49a6
Author:    collins
Date:      2012-05-11 11:30 -0700
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/35e504cb49a6

7167625: Adjustments for SE-Embedded build process
Summary: Simple change to the SE-Embedded build rules that should not affect any other OpenJDK users.
Reviewed-by: kvn, dholmes

! make/linux/makefiles/vm.make
! src/share/vm/runtime/arguments.cpp

Changeset: fada85d11d92
Author:    jprovino
Date:      2012-05-16 13:33 -0400
URL:       http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fada85d11d92

Merge

Re: Obtaining methods executed at least once?

Ben Evans — 2012-05-16T12:04:51

Hi Andreas,

OK, I'll bite with a couple of questions:

1) Why do you want this information? Is it purely informative, or are
you planning to make use of it in some way? If you're planning to use
it - what uses do you have in mind?

2) What do you mean by "inlined at compilation". When dealing with
HotSpot, always remember that there are two separate things which
could be thought of as 'compilation' - there's the process which
creates classfiles (e.g. javac) and there's the process which creates
machine code from hot methods - JIT compilation. It isn't clear to me
which of these two processes you mean.

Thanks,

Ben

On Wed, May 16, 2012 at 7:11 AM, David Holmes <david.holmes-QHcLZuEGTsvQT0dZR+AlfA< at >public.gmane.org> wrote:

Re: Request for review (XS): 7169056: Add gigabyte unit toproper_unit_for_byte_size() and byte_size_in_proper_unit()

Bengt Rutisson — 2012-05-16T14:35:42

Ulf,

You are correct. The LOG_G constant is wrong. If it should be based on 
the previous log constants it should be 3*LOG_K as you point out (it is 
not clear to me that this is more readable than just "30").

However, the LOG_G constant is not being used anywhere in the Hotspot 
code. I would prefer to remove it rather than fix it.

The LOG_K constant is never used directly. Just implicitly through 
LOG_M. And LOG_M is only used in one place: 
HeapRegionRemSet::setup_remset_size().

It seems strange to me to have this stuff in globalDefinitions.hpp. 
Unless anybody objects I'll file a CR to remove LOG_K and LOG_G and move 
LOG_M to heapRegionRemSet.cpp.

Thanks for catching this!
Bengt

On 2012-05-16 12:04, Ulf Zibis wrote:

Re: Obtaining methods executed at least once?

Krystal Mok — 2012-05-16T14:48:30

On Wed, May 16, 2012 at 10:39 PM, Andreas Sewe <
sewe-ragVMc8tzzHbA/2l3k8Gwdu65OH5Cw0ybI1oV63ZYDM< at >public.gmane.org> wrote:


I don't think you have to anything to "force" a Java method to be
interpreted first, because that's the default behavior already. Since you
only care about "non-zero" invocation counts, running a method in the
interpreter for even just once is enough, and it doesn't matter if the
method got compiled later.

So long as you don't do -Xcomp sort of stuff, you should get the correct
list of invoked methods this way. And with the -XX:-UseFastEmptyMethods
-XX:-UseFastAccessorMethods caveat.

Hopefully I'm not missing anything... :-)

- Kris

Re: Obtaining methods executed at least once?

Andreas Sewe — 2012-05-16T14:39:10

Hi,


Yes, I only care about that.

The question is whether I can force interpretation for all methods (so
that the counts are incremented) by doing -XX:-UseCompiler?


Neat. :-)


Yes, that's fine. Thanks.

Best wishes,

Andreas

Re: Obtaining methods executed at least once?

Krystal Mok — 2012-05-16T14:25:31

Hi Andreas,

There are a couple of ways off the top of my head. Their viability depends
on the original purpose of getting the list of executed methods.

HotSpot keeps the invocation count (at least in the interpreter) for all
Java methods. It may not be precise, because it'll decay periodically, or
it may be set to certain values for triggering standard compilation, etc.
But if you only care about zero and non-zero, this counter would be
sufficient.

The problem is: how to get the list of invoked methods?
There's no flag within the VM that I'm aware of that would print the list
of invoked methods, unfortunately.

You could try the Serviceability Agent. See this example that I just made:
https://gist.github.com/2710667#file_print_invoked_methods.java

It can attach to your target Java process, and extract all invoked methods.

Caveat:

1. If you're on JDK6, you may need to include these two VM flags in your
target Java application:
-XX:-UseFastEmptyMethods -XX:-UseFastAccessorMethods
Otherwise empty methods

Re: Obtaining methods executed at least once?

Andreas Sewe — 2012-05-16T13:03:30

Hi Keith,


yes, I did consider using JVMTI. Unfortunately, there's no proper event
for this, and handling all JVMTI_EVENT_METHOD_ENTRYs is very expensive,
even if it is "just" looking up jmethodID's in a map most of the time.

Thus I was thinking about forcing compilation (-XX:-UseInterpreter) and
then using the compilation log. I am unsure, however, if this really
gives me all methods, i.e., if -XX:-UseInterpreter is respected all the
time.

Best wishes,

Andreas

Re: Obtaining methods executed at least once?

Andreas Sewe — 2012-05-16T12:15:33

Hi Ben,


Fair enough.


I am gathering some statistics on a few benchmarks. In particular, I am
interested in the *fraction* of methods compiled (at the various levels,
if tiered compilation is used). Thus, I also need to know the overall
number of methods executed (whether they have been compiled or not).


I meant the JIT.

The problem is that you want to count a method as compiled even if is
only compiled in a "nested" context due to inlining. (Of course, you
don't want to count the method multiple times if it is inlined at
multiple places either.) But as far as I can see, the
-XX:+LogCompilation log contains enough information to determine all
methods that have been compiled, be it as a root method or deeper into
the inline tree.

Hope this clarifies things for you.

Best wishes,

Andreas

Re: Request for Review: Make the Queens test ("test in build") anoption that can be disabled

Magnus Ihse Bursie — 2012-05-16T12:11:17

No, I don't want to do that in this change. This change is rather a step 
away from running the test, which I (personally) don't really believe 
should be a step of the build process. If you want to keep the test, 
fine, but you'll have to bug fix it yourself. ;-)

/Magnus

Re: Obtaining methods executed at least once?

Keith McGuigan — 2012-05-16T11:52:01

Have you considered using a JVMTI agent and catching the method 
entry/return events?  You'd have to do some work in the agent to ignore 
duplicates though.

--
- Keith

On 5/16/2012 6:11 AM, David Holmes wrote:

Re: Obtaining methods executed at least once?

David Holmes — 2012-05-16T10:11:18

Andreas,

I've cc'd this to hotspot-dev which is the right place to ask.

Please drop the discuss list from further replies.

David

On 16/05/2012 6:56 PM, Andreas Sewe wrote:

Re: Request for review (XS): 7169056: Add gigabyte unit toproper_unit_for_byte_size() and byte_size_in_proper_unit()

Ulf Zibis — 2012-05-16T10:04:26

See:
  164 const size_t LOG_K              = 10;
  165 const size_t LOG_M              = 2 * LOG_K;
  166 const size_t LOG_G              = 2 * LOG_M;

Shouldn't it be
  166 const size_t LOG_G              = 3 * LOG_K;
?

-Ulf


Am 15.05.2012 22:36, schrieb Bengt Rutisson:

Re: Request for review (XS): 7169056: Add gigabyte unit toproper_unit_for_byte_size() and byte_size_in_proper_unit()

Bengt Rutisson — 2012-05-16T05:36:34


Thanks for the review, David!

I'll go ahead and push this now.

Bengt


On 2012-05-16 05:30, David Holmes wrote: