Hi Mandy,
Thank you. Patch looks good.
Regards,
Jeroen
-Original Message-
From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
boun...@openjdk.java.net] On Behalf Of Mandy Chung
Sent: Friday, November 1, 2013 19:16
To: core-libs-dev@openjdk.java.net
Subject:
Hi Mandy (and Mark),
The getter can be optimized away, the static field can't, so this is probably a
tiny bit more expensive.
Regards,
Jeroen
-Original Message-
From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
boun...@openjdk.java.net] On Behalf Of Mandy Chung
John Rose wrote:
I think the next interesting version of String will mix header and body
together in a hybrid layout, with private char (or byte) elements and a
few instance variables at the beginning of the layout.
It would be good to prepare for this by modifying the JNI spec to explicitly
Hi,
I'd like to propose to change Class.checkInitted() to check if the VM
initialization has completed by using sun.misc.VM.isBooted() instead of
System.out != null.
The current check needlessly triggers System class initialization (thus
complicating bootstrap initialization order on VMs that
System.out can be null, because System.setOut(null) is legal.
Regards,
Jeroen
From: David Holmes [mailto:david.hol...@oracle.com]
Sent: Thursday, December 19, 2013 11:14
To: Alan Bateman
Cc: Jeroen Frijters; core-libs-dev@openjdk.java.net
Subject: Re: Request: Remove System.out check from
David Holmes wrote:
I don't think this is workable. Exposing a monitor as Lock would allow
you to break the guarantees/requirements involving balanced-locking for
monitors.
Where are these guarantees/requirements documented?
Regards,
Jeroen
Brian Goetz wrote:
Embedded in this proposal is the desire to not provide a full-blown
lvalue form for variables; supporting any form of pass-by-reference at
the language level is a super-non-goal here.
Why is this? It solves these problems in an extremely clean way and also
provides lots of
Brian Goetz wrote:
Right now, the semantics of method calls in Java are simple --
everything (primitives, object references) is passed by value. Adding
pass-by-reference would add significant complexity. And method calls
are not a niche feature; that added complexity will be borne by every
-
From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
On Behalf Of Paul Benedict
Sent: Wednesday, March 5, 2014 16:19
To: Christoph Engelbert
Cc: Jeroen Frijters; core-libs-dev@openjdk.java.net
Subject: Re: JEP 193: Enhanced Volatiles
This idea really close very the commonly
Brian Goetz wrote:
I'm all for unintrusive. Though note that the intrusiveness metric on
language features I(f) is not uniform across observers :)
Indeed :-)
Here's my straw man
proposal:
Add an annotation that can be placed on native methods to synthesize
atomic accessor methods.
-Original Message-
From: Peter Levart [mailto:peter.lev...@gmail.com]
Sent: Wednesday, March 5, 2014 18:07
To: Jeroen Frijters; Brian Goetz; core-libs-dev@openjdk.java.net; Doug
Lea
Subject: Re: JEP 193: Enhanced Volatiles
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian
David Holmes wrote:
But if the JVM acts upon annotations to change how it executes those
bytecodes then, as Peter said, the JVM is implementing the language
semantics.
The JVM synthesizes a native method, this has *nothing* to do with language
semantics. From the language point of view,
Hi Sherman,
As a (minor) data point, IKVM.NET has been using a pure Java ZipFile
implementation since day one (based on the GNU Classpath version) and other
than a few compat bugs in the early days people have never complained about it.
For obvious reasons, I'd certainly prefer the pure Java
, 2012 7:08 PM
To: Jeroen Frijters
Cc: David Holmes; core-libs-dev@openjdk.java.net
Subject: Re: CloneNotSupportedException should extends RuntimeException not
Exception
Hi Jeroen,
On 10/15/2012 01:48 PM, Jeroen Frijters wrote:
The solution is actually pretty easy. Just deprecate Object.clone
From: core-libs-dev-boun...@openjdk.java.net
[core-libs-dev-boun...@openjdk.java.net] on behalf of Jeroen Frijters
[jer...@sumatra.nl]
Sent: Monday, October 15, 2012 9:30 PM
To: Remi Forax
Cc: David Holmes; core-libs-dev@openjdk.java.net
Subject: RE: CloneNotSupportedException should
I agree, but at the same time CLASS retention is really the worst of both
worlds in my opinion. It doesn't have any (convenient) runtime benefit, but you
can be sure that someone will depend on it at runtime by parsing the class
files (this happens surprisingly often).
I'd really like to see
Hi John,
This is really great. I've been using an annotation for caller sensitive
methods for many year in IKVM as a performance enhancement and I can say that
my experiences with my simple mechanism are really great.
I've got a class ikvm.internal.CallerID that looks something like this:
Remi Forax wrote:
I've always found that getCallerClass() was done at the wrong side of
the problem, i.e. asked inside the callee instead of being inserted at
callsite.
Yes, I agree and in fact in the IKVM implementation a CallerID parameter is
added to each method that has the HasCallerID
John Rose wrote:
Remi's idea (using invokedynamic) makes a good proof of concept, too.
But because we use getCallerClass to observe a non-forgeable caller
identity, the @CS mechanism has to be something that works underneath
any visible bytecode pattern, at least in the caller.
Yes. In IKVM
Hi Joe,
I notice that Method.isDefault() returns true for static interface methods. I
assume that is not correct.
Regards,
Jeroen
-Original Message-
From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
boun...@openjdk.java.net] On Behalf Of Joe Darcy
Sent: Thursday,
Hi,
Thanks for this. This is a really great change.
I reviewed the changes and my only comment is that there is a typo in
java/lang/reflect/Field.java (scurity).
Somewhat unrelated (but relevant for my implementation of CallerSensitive), but
would it be possible to mark java.lang.Runtime as
IMO Thread.currentThread().stop(new Throwable()) should continue to work. It is
not unsafe and it is probably used in a lot of code to workaround the madness
that is checked exceptions.
-Original Message-
From: core-libs-dev-boun...@openjdk.java.net [mailto:core-libs-dev-
a stop to Thread.stop?
On 05/14/2013 04:45 PM, Jeroen Frijters wrote:
IMO Thread.currentThread().stop(new Throwable()) should continue to
work. It is not unsafe and it is probably used in a lot of code to
workaround the madness that is checked exceptions.
This hack doesn't work well because
Nick Williams wrote:
What if we also added a getStackFrames() method to Throwable? That would
meet my needs but it would also satisfy what I'm observing is a desire
to have a new API for this (StackFrame) instead of adding it to
StackTraceElement. I'm very open to how it's implemented, as long
Xueming Shen wrote:
I'm not a GC guy, so I might be missing something here, but if close()
is being explicitly invoked by some thread, means someone has a strong
reference to it, I don't think the finalize() can kick in until that
close() returns
This is not correct. You can re-publish the
Hi,
I'm not a formal reviewer, but I've implemented this same thing for IKVM.NET
which has to simulate the behavior of CreateProcess when running on Windows
(because it uses the .NET API to start a process and that doesn't have this
hack).
Your algorithm doesn't match CreateProcess, because
Andrew Haley wrote:
Please, someone tell me Windows isn't still using the old 18.2 Hz DOS
timer for its system clock. No
Not that it is true, but why would that be bad?
By default (most) multi core/cpu Windows systems run at a 15 ms timer interrupt
interval (10 ms for single cpu/core
David Holmes wrote:
Fortunately, as Brian stated, compatibility is not an end unto itself
here and we often do have documented incompatibilities across major
releases. In this case there is far more harm, in my opinion, leaving
the possibility of people trying to clone threads than there is in
Sorry to be late with my comment, but as a VM implementer I can't really agree
with this modification. The return type of X[].clone() is clearly Object, not
X{]. That illusion is a javac compiler trick. IMHO it belongs in the JLS not in
the Object.clone() documentation.
Regards,
Jeroen
David Holmes wrote:
The fact that Object.clone() is implemented via a native call into the
VM is simply an implementation detail.
That's not what we're talking about. We're talking about the fact that arrays
(appear to) have a *public* clone method. The argument is about the return
type[1]
Hi Mandy,
I like the API shape and this capability is very much needed. Thanks!
It does bring something related to mind and that is that the current Java
ecosystem is already very dependent on accurate stack frames (i.e. not removing
them when inlining) and with this API this will probably
31 matches
Mail list logo
