RFR (S): JEP-142: Reduce Cache Contention on Specified Fields

Doug Lea dl at cs.oswego.edu
Tue Dec 4 16:08:43 PST 2012


On 12/04/12 18:46, John Rose wrote:

> I don't mean to add insult to injury, but I think there is yet another
> restriction that we should place this annotation under, in its current residence
> of sun.misc.
>
> The annotation must be documented as being a no-op when it occurs inside class
> files that are loaded outside the boot class path.
>
> This is consistent with comments made by several other people, that these tools
> are intended, at least at first, for developers of core classes.  This is also
> consistent with Unsafe, which (however popular it is) is designed to be used
> core classes only, on the BCP (boot class path).[1]

I'm basically OK with this.
(Which in juxtaposition with Kirk's post says: Yes, some of
us need these things so desperately that we are willing to
live with ridiculous restrictions.)

I do worry about the tiny community of "external" low-level
Java hackers that I should stick up for though. (Examples:
The Disrupter and Akka folks, those doing in-house financials and
analytics.) Experience shows that they are also willing to go
through ridiculous hurdles so they can write high-performance
software on JVMs. But a *guarantee* of no effect might be crossing
that line. Any ideas?


> [1] Yes I know Unsafe is sometimes broken into by a Field.setAccessible hack.
>   Which is an implementation artifact that could easily break by accident.  If
> you use that hack, you should move your code to BCP.
>

Which is the trick we use to put out our pre-openjdk-integration
preview packages. So we'd have to find another trick...

-Doug




More information about the hotspot-dev mailing list