[
https://issues.apache.org/jira/browse/LUCENE-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316135#comment-14316135
]
Uwe Schindler edited comment on LUCENE-6239 at 2/11/15 12:25 PM:
-----------------------------------------------------------------
bq. We don't even need to debate this. This is absurdly risky. Just look at the
conversation you are having. We don't need this in a search engine library.
Which conversation? There is a difference in calling stuff like
Unsafe.writeFooBar or retruveing some values. We actually only read some
offsets thats all. No risk. Where is your problem now. Who reported a crush?
What line of code caused issues?
I agree that code using unsafe to allocate off-heap memoy and directly modify
values in memory using pointes is risky => see the funny test that forces to
crush the JVM. Please see the difference here, its just some call to a
read-only method that might disappear -> and we use reflection here to be
prepared for that. But there is nothing that can crash.
Actually the JVM people now have issues because the name "Unsafe" is just wrong
- and thats what you are about (its called "unsafe" so it could break). Most of
the stuff isn't actually unsafe, so they want to make it public in Java 9:
Stuff like those constants or atomic compareAndGet - of course stuff writing
and reading from actuall off-heap memory will be removed in Java 9 or made
"safe".
I just repeat: We dont *read* or *write* stuff! We just call "information"
methods. Please read the code!
was (Author: thetaphi):
bq. We don't even need to debate this. This is absurdly risky. Just look at the
conversation you are having. We don't need this in a search engine library.
Which conversation? There is a difference in calling stuff like
Unsafe.writeFooBar or retruveing some values. We actually only read some
offsets thats all. No risk. Where is your problem now. Who reported a crush?
What line of code caused issues?
I agree that code using unsafe to allocate off-heap memoy and directly modify
values in memory using pointes is risky => see the funny test that forces to
crush the JVM. Please see the difference here, its just some call to a
read-only method that might disappear -> and we use reflection here to be
prepared for that. But there is nothing that can crash.
Actually the JVM people now have issues because the name "Unsafe" is just wrong
- and thats what you are about (its called "unsafe" so it could break). Most of
the stuff isn't actually unsafe, so they want to make it public in Java 9:
Stuff like those constants or atomic compareAndGet - of course stuff writing
and reading from actuall off-heap memory will be removed in Java 9 or made
"safe".
> Remove RAMUsageEstimator Unsafe calls
> -------------------------------------
>
> Key: LUCENE-6239
> URL: https://issues.apache.org/jira/browse/LUCENE-6239
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> This is unnecessary risk. We should remove this stuff, it is not needed here.
> We are a search engine, not a ram calculator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
