On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote:
> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
>
> Currently, some of the files in the OpenJDK repo have Amazon copyright
> notices which are all slightly different and do not conform to Amazons
> preferred cop
On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich
wrote:
> The change completes the fix of
> [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has
> added normalisation in a constructor but not removed it from the get method.
Lgtm.
-
Marked as reviewed by p
t the refactoring
in diagnosticCommandFramework.cpp (too few lines can be really
factored out without passing many arguments).
New webrev is here:
http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.03/
Regards,
Fred
On 12/ 8/11 07:26 PM, Paul Hohensee wrote:
For the hotspot part at
For the hotspot part at
http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/
Most of my comments are style-related. Nice job on the implementation
architecture.
In attachListener.cpp:
You might want to delete the first "return JNI_OK;" line, since the code
under
HAS_PENDING_EXCEP
This is just the start of a review: fumble-fingers sent it well before
it's time.
Paul
On 12/7/11 4:15 PM, Paul Hohensee wrote:
For the hotspot part:
In attachListener.cpp, you might want to delete the first "return
JNI_OK;"
line, since the code under HAS_PENDING_EXCEP
For the hotspot part:
In attachListener.cpp, you might want to delete the first "return JNI_OK;"
line, since the code under HAS_PENDING_EXCEPTION just falls through.
In jmm.h, minor formatting nit: be nice to indent "(JNIEnv" on lines 318,
319 and 325 the same as the existing declarations. Add
Changeset: c73c178159d8
Author:phh
Date: 2011-01-20 19:34 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c73c178159d8
6173675: M&M: approximate memory allocation rate/amount per thread
Summary: Subclass com.sun.management.ThreadMXBean from
java.lang.management.ThreadMXBean,
A reply from the same Hotspot engineer.
Paul
| Is there a reason why signal chaining is not enabled by default on
linux/solaris?
Just wanted to clarify - signal chaining is enabled by default for the JVM.
The way signal chaining works is cooperatively. i.e. when the JVM
starts, it "c
A partial answer: one of the Hotspot engineers says
"I think the short answer is that chaining requires LD_PRELOAD to
override the signal entry points. Otherwise we [Hotspot] wouldn't see
the calls that change the signal handlers. If the Java command itself
linked against jsig that would work
More info from Hotspot engineers.
>Does webstart allow running your own native code in an applet? (Does
plugin while
>So I am guessing that they have java interfaces using the jvm/JIT
>- then gluegen -- how does gluegen work here? Is it precompiled
or does it do a translation at run
"in a way" plus "somewhat", as in "it's kinda bad" == "in a way, it's
somewhat bad".
On 3/22/10 7:02 PM, Ulf Zibis wrote:
Can somebody betray the sense of "Kinda" to me?
-Ulf
Then just ignore what I said. :)
Paul
Karen Kinnear wrote:
JVM_FindClassFromBootLoader is new with JDK7. Kumar added it.
thanks,
Karen
On Jul 24, 2009, at 11:07 AM, Paul Hohensee wrote:
Can't remove it unless it's fixed in jdk6 as well as 7. Also, one of
these days we'l
Can't remove it unless it's fixed in jdk6 as well as 7. Also, one of
these days we'll
get around to shipping current hotspot in jdk5 and maybe 1.4.2. How
would these
be affected?
paul
Keith McGuigan wrote:
I would prefer that we avoid requiring synchronous pushes (so I guess
I think we sh
wrt ts-6434, the abstract just talked about performance case studies.
We didn't
know what the cases would be when we filed the abstract.
Paul
Martin Buchholz wrote:
JavaOne 2008 technical session PDFs are now available
http://developers.sun.com/learning/javaoneonline/j1online.jsp?track=javas
14 matches
Mail list logo
